How to hire a data analyst (job description, interview questions, screening workflow)

The instinct is to hire whoever lists the most tools on their resume: SQL, Python, Tableau, Excel, the works. That's the wrong first filter. Tools are teachable. What isn't quickly teachable is the instinct to question a number before reporting it: to notice that a join might be silently duplicating rows, that a chart's axis is quietly misleading, or that a metric moving 8% week over week deserves investigation before it deserves a headline. At a small company there's no senior analyst reviewing this person's queries before they go to leadership. This guide is built to screen for that judgment, because it's exactly what a resume full of tool names hides.

What a data analyst actually does at a small company

At a company with a full data team, a data analyst works inside a structure with data engineers feeding them clean tables, a data scientist handling anything statistically complex, and an analytics manager reviewing their work before it reaches leadership. At a small SaaS company or an operations-heavy small business, one analyst often owns the whole pipeline: pulling raw data, cleaning it, analyzing it, and presenting a recommendation directly to the founder or a department head.

The core responsibilities, in practice:

• Writing SQL queries to pull and combine data from product, sales, or operations systems, often without a data engineer to hand off clean tables first
• Building and maintaining the recurring reports and dashboards leadership checks weekly, so numbers don't have to be rebuilt from scratch every time
• Investigating why a metric moved: a conversion drop, a churn spike, a revenue miss, and tracing it to an actual cause rather than a guess
• Communicating findings in plain language to people who aren't analysts themselves, with a clear recommendation, not just a chart
• Catching data quality problems before they become a bad decision: a broken tracking event, a join that's inflating a count, a metric definition two teams are using differently
• Running or interpreting basic experiments (an A/B test on pricing, onboarding, or a feature change) without a dedicated data scientist to lean on

The SQL and tooling bar for this role isn't usually the hardest part for someone with real experience. The hard part is judgment with very little oversight: knowing when a result looks wrong before shipping it, being able to explain a recommendation to a non-technical founder in plain language, and having the discipline to sanity-check a query before trusting the output.

Job description you can post today

Copy this, then adjust the specifics (your data stack, your reporting cadence, your team structure) to match your company.

Data analyst
[Company name] is looking for a data analyst to turn our raw data into decisions our team can actually act on. You'll pull and analyze data yourself, build the reports leadership relies on, and communicate findings clearly, often without a data engineering team behind you.

What you'll do
Write SQL queries to pull, clean, and combine data from our [product/sales/operations] systems. Build and maintain recurring reports and dashboards. Investigate metric changes and trace them to real causes. Present findings and recommendations in plain language to non-technical stakeholders. Flag data quality issues before they lead to a bad decision.

What we're looking for
Real SQL proficiency: joins, aggregation, window functions, and the judgment to sanity-check your own output. Comfort with basic statistics (confidence, significance, sample size) well enough to interpret an A/B test correctly. Strong written and verbal communication for a non-technical audience. Excel or spreadsheet proficiency as a baseline. A relevant degree is a plus but not required if you can demonstrate the skill.

Schedule
[Insert hours and any reporting-cadence deadlines]

[Insert pay range, per your company's policy and any applicable state salary transparency requirements]

10 interview questions, and what a good answer sounds like

1. Walk me through how you'd figure out why a metric, like weekly signups, dropped 15% from last week.

You're checking for an investigative process, not a guess. A strong answer describes checking for data quality issues first (a broken tracking event, a missing day of data), then segmenting by source, device, or channel to isolate where the drop is concentrated, before concluding anything about the cause. A weak answer jumps straight to a story ("marketing probably changed something") without describing how they'd verify it.

2. Tell me about a query that gave you a wrong or surprising number, and how you caught it.

This tests whether they actually sanity-check their own work. Listen for a real story: what tipped them off (a total that seemed too high, a row count that didn't match expectations), and what they found (often a join duplicating rows, or a filter excluding the wrong thing). A candidate who's never caught their own error, or who describes trusting output blindly, is a real flag for a role with little oversight.

3. Explain what a 95% confidence interval means to me as if I've never taken a stats class.

This surfaces both statistical understanding and plain-language communication, since both matter at a small company where the analyst reports directly to a non-technical owner. A strong answer avoids jargon and gives a concrete, intuitive explanation rather than reciting a textbook definition.

4. You're asked to combine data from two tables and the resulting numbers look too high. What do you check first?

Good answers describe checking the join logic first, specifically whether the join key is duplicating rows (a one-to-many join exploding row counts is one of the most common silent errors in SQL work). A weak answer has no specific diagnostic step and would just re-run the same query hoping for a different result.

5. Tell me about a time you had to tell someone senior that their instinct about the data was wrong.

This checks for backbone, which matters since a small company's analyst often has to push back on a founder's or manager's pet theory. Listen for how they handled the conversation: leading with the evidence, staying calm, and not backing down just because the other person was more senior. A candidate who's never had to do this may fold under pressure when it matters.

6. A dashboard shows a line chart with the Y-axis starting at 950,000 instead of zero, making a small increase look dramatic. What's wrong with this, and what would you do differently?

Strong answers name the specific problem (a truncated axis exaggerates the visual change) and describe a fix (starting at zero, or clearly labeling the axis) rather than treating the chart as fine because the underlying numbers are technically accurate. This is a real, common way analysts (intentionally or not) mislead stakeholders.

7. Walk me through how you'd interpret an A/B test result that shows a positive lift, but the confidence interval includes zero.

Good candidates recognize that a confidence interval spanning zero means the result isn't statistically distinguishable from no effect, and would recommend more data or a longer test rather than declaring a winner. A weak answer treats any positive number as a win regardless of the uncertainty around it.

8. Tell me about the most complicated analysis you've done from a messy or incomplete dataset.

This surfaces real experience with imperfect, real-world data, which is the norm at a small company without a mature data pipeline. Listen for specifics on what was messy (missing values, inconsistent formats, duplicate records) and how they handled it, not a hypothetical.

9. Yesterday your conversion rate dropped from 3.1% to 2.4%, marketing says nothing changed on their end, and engineering shipped a checkout update. Walk me through your first 30 minutes.

Strong answers describe a triage sequence: check for data quality issues first, segment by the checkout change specifically (device, browser, plan type), and look for a spike in errors or abandonment tied to the release window, before concluding anything. A weak answer jumps to blaming engineering without a plan to verify it.

10. Why are you interested in being the only data analyst at a small company, rather than one of several on a larger data team?

This checks whether they understand what they're signing up for: more ownership and variety, but no data engineer to hand off clean tables and no senior analyst reviewing their work. A candidate who can't name a real reason beyond "it was the job that was open" may be underprepared for how solo this role actually is.

A scorecard you can score candidates against

Ten questions only help if everyone on your side is listening for the same signals. Score every candidate on the same six dimensions, so you're comparing evidence instead of six different impressions of who sounded the most technical. Copy this into a doc and fill in a row per candidate.

How to screen data analyst candidates without losing a week to it

Truffle is a candidate screening platform that combines resume screening, one-way video interviews, and talent assessments, so you can build a screening workflow around what actually matters for a role where the wrong hire can quietly feed you bad numbers for months before anyone notices.

Tech and software roles are pulling especially heavy applicant volume right now, and data analyst postings are no exception. On top of the volume, there's a growing problem of candidates using AI to answer technical screening questions in real time during live interviews, or resumes padded with tool names that don't reflect real query-writing ability. A layered screen that tests actual reasoning, not just self-reported skills, matters more here than in most roles.

A workflow that fits a small company hiring one data analyst:

• Resume screening first. Cut obvious mismatches on SQL experience, relevant industry background, and years of hands-on analysis before you spend time on anyone.
• A short one-way video interview for your first real look. Ask 2-3 of the scenario questions above, like the metric-drop investigation or the confidence interval question, so you hear how someone actually reasons through ambiguity before committing any live interview time.
• A real skills check instead of trusting a resume full of tool names. Our data analysis exam uses real SQL, interpretation, and business-case scenarios scored against a transparent rubric, so you see actual analytical ability instead of a list of tools someone has merely been exposed to.
• A live conversation only for candidates who clear the first three steps. By the time you're on a call, you already know they can write a real query and reason through ambiguity. The live conversation is for fit and communication style, not for discovering for the first time whether they can do the job.

Our resume screening and one-way video interview tools handle the first two steps in one place, with AI that surfaces your strongest matches against the criteria you set. You review the evidence and decide. It doesn't pick for you.

3 questions from the skills check we'd actually run for this role

A skills check only helps if it tests real reasoning, not memorized syntax. These three are pulled straight from Truffle's data analysis exam, the assessment we'd point you to for this role. Try them yourself before you decide what "job-ready" means for your opening.

The point isn't these three questions specifically. It's that a short, scenario-based skills check tells you in under an hour what a resume full of tool names can't: whether someone actually reasons carefully through a real data problem or just recognizes the vocabulary. Truffle's AI scores and surfaces the results against the bar you set. You still make the call on who clears it.

Common hiring mistakes for this role

Filtering on tool names instead of testing reasoning. Listing SQL, Python, and Tableau on a resume proves someone has been exposed to those tools, not that they can write a correct join or catch a misleading chart. Weight the scenario-based judgment above the tool list.

Not testing statistical interpretation. A candidate who can write a query but misreads a confidence interval, or declares any positive A/B test number a win, can quietly steer your company toward bad decisions with technically-correct-looking numbers.

Skipping the plain-language communication check. At a small company, this person often reports directly to a founder or department head who isn't an analyst. A technically strong candidate who can only explain findings in jargon will generate confusion instead of clarity.

Trusting a smooth live interview without verifying it's the real candidate's own reasoning. Technical interviews are an increasingly common target for AI-assisted answers or proxy interviewees on live video calls. A short one-way interview, where a candidate responds to your specific prompts on their own time, paired with a real skills check, is a harder setup to game than a single live conversation.