Data analyst interview questions to ask candidates

1. Walk me through the most recent analysis you did that actually changed a decision. What was the question, what did you find, and what did the team do differently afterward?

   Why ask it: Immediately separates analysts who drive decisions from analysts who produce reports that get politely filed.

   Listen for: A named stakeholder and decision, a specific finding with a number attached, and a concrete change afterward — not "they found it really insightful."

2. Describe your current data stack end to end — where the data lands, what you transform and query it with, and where your dashboards live. Which parts do you personally own?

   Why ask it: Confirms hands-on scope in two minutes and tells you which deeper questions their experience can actually support.

   Listen for: A coherent pipeline with named tools (events to warehouse to dbt to a BI tool) and a clear line between what they built versus what they inherited.

3. Looking at your last month of work, roughly how did your hours split across writing SQL, building dashboards, and analyzing experiments? What were you doing in the biggest bucket?

   Why ask it: This role is a three-way mix, and recent reps matter more than resume keywords.

   Listen for: Rough percentages given without hesitation and a concrete current project in their biggest bucket, not an even "bit of everything" split.

4. From what you've seen of our product so far, what's the first user behavior or metric you'd want to dig into here, and what data would you need to do it?

   Why ask it: Tests whether they researched you and whether they generate questions or wait for tickets.

   Listen for: A question tied to how the business actually makes money (activation, retention, conversion) plus the specific events or tables they'd pull to answer it.

1. Tell me about a specific SQL query you wrote in the last few months that you're proud of. What made it hard — the logic, the data, or the performance — and how did you get it right?

   Why ask it: Probes real SQL depth through their own artifact instead of a whiteboard puzzle they may have rehearsed.

   Listen for: Named mechanics — window functions, grain and join fan-out problems, dedup logic, query-plan fixes — plus a verification step that proved the output correct.

2. Walk me through the last time a number you shipped turned out to be wrong. How was it caught, what was the root cause, and what do you do differently now?

   Why ask it: Every practicing analyst has shipped a wrong number, so the answer measures candor plus detection and repair habits.

   Listen for: A specific root cause (join fan-out, timezone boundary, NULLs in a filter), who caught it, and a named new habit like reconciling against a known total before sending.

3. Pick one dashboard you've built that people still use. Who looks at it, what decision does it feed, and what did you remove or redesign after watching how people actually used it?

   Why ask it: Separates builders of decision tools from builders of chart walls nobody opens.

   Listen for: A named audience and cadence ("the growth lead, every Monday"), evidence of real usage, and at least one chart they cut or reworked based on feedback.

4. Tell me about a time two teams disagreed on what a metric meant — something like "active user" or "conversion." How did you resolve it, and where does that definition live today?

   Why ask it: Metric-definition fights are the recurring grind of analytics work, and resolving them durably is a core skill.

   Listen for: The exact ambiguity (time window, dedup rule, attribution), how they got both sides to one definition, and a durable home for it like a dbt model or metrics doc.

5. Walk me through the last experiment you analyzed end to end. How did you set the sample size and runtime up front, and what happened when the results came in?

   Why ask it: Reveals whether they have run real experiments or just memorized the significance-testing vocabulary.

   Listen for: Minimum-detectable-effect or power reasoning, at least one guardrail metric, no mid-test peeking (or a proper sequential method), and a clear ship-or-kill call at the end.

6. Tell me about an experiment that came back flat or ambiguous. What did you recommend, and what did the team end up doing?

   Why ask it: Flat results are the most common real outcome, and the recommendation exposes statistical judgment better than any happy-path story.

   Listen for: They separate "no effect" from "underpowered," cite the confidence interval or MDE, and still made a recommendation instead of proposing endless reruns.

1. Tell me about a time a stakeholder pushed back hard on your analysis because it contradicted what they expected. What exactly did they challenge, and how did it end?

   Why ask it: Analysts routinely deliver unwelcome numbers, and this shows whether they fold, dig in blindly, or re-verify and stand firm.

   Listen for: They re-checked their own work first, traced the disagreement to a definition or data source, and either held the line with evidence or corrected an error out loud.

2. Describe a request where the stakeholder asked for one analysis but actually needed a different one. How did you spot the gap, and what did you deliver instead?

   Why ask it: Strong analysts interrogate the question behind the ticket rather than running whatever SQL was requested.

   Listen for: The clarifying question they asked ("what decision will this feed?"), the ask-versus-need gap they found, and a smaller or different deliverable that answered the real question.

3. Walk me through a week when multiple teams all needed something from you by the same deadline. What did you ship, what did you push, and how did you tell people?

   Why ask it: Competing demands are this role's permanent background noise, and silent heroics are how analysts burn out or drop balls.

   Listen for: An explicit ranking rule (decision deadline, revenue impact, effort), a named conversation where they said "not this week," and no pretending they did it all.

4. Tell me about explaining a statistical caveat — like why a test needed two more weeks, or why a correlation wasn't causal — to someone who just wanted a yes or no. What did you actually say?

   Why ask it: Translating statistics into a stakeholder's language is where analyst influence is won or lost.

   Listen for: A plain-English line they can reproduce on the spot, framed in the stakeholder's own risk ("ship now and it's a coin flip"), with no retreat into jargon.

1. Where do AI tools genuinely fit in your analysis workflow today — what do they save you real time on, and where have they burned you?

   Why ask it: Maps their actual 2026 workflow and whether they have learned the failure modes firsthand rather than by rumor.

   Listen for: Specific uses (drafting SQL, dbt boilerplate, chart code, first-pass summaries), one concrete burn like a hallucinated column or subtly wrong join, and the habit they changed after it.

2. When an AI assistant drafts a query or an analysis for you, what's your verification routine before those numbers reach a stakeholder?

   Why ask it: The biggest analyst failure mode in 2026 is shipping plausible-but-wrong AI output under deadline pressure.

   Listen for: Named checks — reconciling against a known total, row counts per CTE, spot-checking rows against the raw table, re-deriving one figure by hand — not "I read it carefully."

3. Which parts of this job do you deliberately not hand to AI, and why those parts?

   Why ask it: Their boundary line reveals earned judgment about where models fail and where accountability has to stay human.

   Listen for: Reasoned boundaries like final metric definitions, ship-or-kill experiment calls, or any number headed to the board, justified by accountability or missing context rather than vague distrust.

• Every project story ends at "I presented the findings" — they can never name the decision, the stakeholder, or what changed afterward.
• Fluent in A/B-testing vocabulary but can't explain how they sized a real test or what they recommended when one came back flat.
• Claims they've never shipped a wrong number — high-volume analysts all have, so "never" signals low output or low candor.
• Describes dashboards by their contents ("14 KPIs, six filters") and never by a user or a decision — a sign they build chart walls, not tools.
• Their verification of AI-generated SQL amounts to "I look it over," and they can't name a single time an AI tool misled them.

Skip anything about age, family plans, health, religion, nationality or other protected characteristics — those questions create legal risk and tell you nothing about the work. Hiring-interview rules vary by country and state, so check the ones that apply to you.

Asking a sharp question only pays off if you catch the whole answer. incogno transcribes the candidate's answers live on your Mac or Windows PC — no bot joins the call — and lets you ask things like "what did they say about the migration?" mid-interview, with your job description and scorecard loaded as context. See the AI interview assistant for interviewers.