A data analyst interview tests four things, almost always in this order: can you write SQL under time pressure, can you reason about a business metric, do you understand A/B testing and basic statistics, and can you communicate a finding to a non-technical stakeholder. The SQL round is the gate — fail it and the rest rarely matters. The case round is where strong candidates separate from competent ones, because it rewards structured thinking over recall. Below are the representative questions you should expect in each round, what the interviewer is actually checking, and how to prepare so you are demonstrating judgment rather than reciting trivia.
The four rounds you should expect
Loops vary by company, but the underlying tests do not. The Indeed guide to data analyst interview questions catalogs the same four buckets you will meet almost everywhere: a technical SQL screen, a business case or metrics round, an experimentation and statistics round, and a behavioral round. Each one checks something different, and preparing for the wrong one is why technically strong candidates still fail.
| Round | Representative questions | What the interviewer is checking | How to prepare |
|---|---|---|---|
| SQL / technical | Second-highest salary per department; dedupe a table with ROW_NUMBER; running 7-day total; month-over-month retention with a self-join. | Can you decompose a question and write correct, readable SQL under time pressure — joins, CTEs, window functions. | Write queries, do not just read them. Drill window functions and dedup patterns until automatic on a real dataset. |
| Case / metrics | "DAU dropped 8% last week — investigate." "How would you measure the health of our checkout flow?" "Define and instrument a north-star metric." | Structured thinking: do you clarify, segment, hypothesize, and name the data to pull — or do you guess an answer? | Practice a framework out loud: clarify the metric, segment (cohort, platform, geo, real vs tracking), hypothesize, test. |
| A/B testing / stats | Design a test for a new signup flow; the result is +2% at p=0.06 — ship it? Explain a p-value to a PM; why is peeking a problem? | Do you understand significance, power, sample size, and the difference between statistical and practical impact. | Be able to explain p-value, type I/II error, power, and the peeking/multiple-comparisons traps in plain language. |
| Behavioral | Tell me about an insight that changed a decision; a time your analysis was wrong; a stakeholder who disagreed with the data. | Communication, ownership, and intellectual honesty — can you chase the why and admit error without spin. | Prepare 3–4 STAR stories with real numbers; rehearse the "I was wrong" story most. |
The SQL round is the gate
Almost every analyst loop opens with live SQL, and a weak performance ends the process regardless of how good your case reasoning is. The questions are not exotic. The recurring patterns are: aggregate with GROUP BY and a HAVING filter; join two or three tables and avoid fan-out; use a CTE to stage a calculation instead of nesting subqueries; and apply a window function — ROW_NUMBER to dedupe or rank, a running SUM for cumulative totals, LAG/LEAD for period-over-period comparisons. The classic traps are deduplication, "find the second-highest value per group," and self-joins to detect sequences or gaps. Prepare by writing these from scratch until they are muscle memory; reading solutions builds false confidence that collapses under a timer.
The case round rewards structure
Metrics and product-sense questions are deliberately open: "checkout conversion fell 8% week over week — what happened?" There is no single right answer, and candidates who blurt one lose. The interviewer wants a structured investigation. Clarify first — what is the exact metric, the timeframe, and is the drop even outside normal variance? Then segment: is it all users or one cohort, all platforms or just mobile, a real behavior change or a tracking or pipeline bug (a broken event, a deploy, a data delay)? Form a few hypotheses, rank them by likelihood and ease of checking, and name the specific query or dashboard you would pull for each. The candidate who says "first I would confirm it is real and not a logging bug" before theorizing about user behavior signals real on-the-job judgment.
A/B testing and statistics
Analysts are increasingly expected to own experimentation, so this round has grown. Expect to design a test ("we want to try a new signup flow — how would you test it?") and to interpret a result ("the variant is +2% with p=0.06 — do we ship?"). Be ready to:
- Explain a p-value correctly — the probability of an effect this large under the null hypothesis, not the probability the variant is better — and why p=0.06 is not a green light on its own.
- Talk about sample size and power before launch, not after, and estimate how long a test must run to detect the effect size that matters.
- Separate statistical significance from practical significance — a 0.2% lift that is "significant" on ten million users may not be worth the engineering cost.
- Name the common traps: peeking at results and stopping early, running many variants and cherry-picking a winner (multiple comparisons), and ignoring novelty effects.
You rarely need to derive a formula. You always need to translate the statistics into a recommendation a product manager can act on.
Behavioral: the why behind the number
The behavioral round checks whether you communicate and whether you are intellectually honest. Prepare STAR stories — situation, task, action, result — with real numbers attached. The three that come up most: an insight that changed a decision (show you connected analysis to action), a time your analysis was wrong (show you caught it or owned it without spin), and a stakeholder who pushed back on the data (show you can hold a finding under pressure without being defensive). Interviewers are listening for someone who chases the why behind a metric rather than just reporting it, and who can be wrong gracefully — because every analyst is, eventually.
The honest summary
Data analyst interviews test SQL fluency, structured business reasoning, experimentation and statistics, and clear communication — usually in that order, with SQL as the gate. Prepare by writing queries rather than reading them, by talking through a dropped metric out loud until a clarify-segment-hypothesize-test framework is second nature, by being able to defend an A/B test in plain language, and by rehearsing a few honest STAR stories with real numbers. Walk in able to demonstrate judgment, not recite trivia, and you will clear loops that reject more technically credentialed candidates who only studied the wrong round.
Common questions
- How hard is the SQL test, really?
- For most analyst roles it covers joins, GROUP BY with aggregation, filtering, subqueries or CTEs, and window functions (ROW_NUMBER, RANK, running totals). The classic stumpers are deduplication, finding the second-highest value per group, and self-joins for sequences. It is rarely about obscure syntax; it is about whether you can decompose a question into the right query under a clock. Practice writing — not reading — queries until window functions are automatic.
- What is a case or product-sense question and how do I approach it?
- You are given an open business situation — "daily active users dropped 8% last week, what do you do?" — and asked to investigate. The interviewer is checking structure, not the right answer. Clarify the metric and timeframe, segment the problem (is it all users or a cohort, all platforms or one, a real drop or a tracking bug?), form hypotheses, and say what data you would pull to test each. Narrate your reasoning out loud.
- How much statistics do analysts need?
- Enough to run and defend an A/B test: what a p-value means and does not mean, type I vs type II error, statistical vs practical significance, sample size and power, and why peeking at results early inflates false positives. You usually do not need to derive distributions. You do need to explain, in plain language, why a 2% lift with a tiny sample is not a result you would ship on.
- Do I need to prepare behavioral answers too?
- Yes. Expect questions about a time you found an insight that changed a decision, a time your analysis was wrong, and how you handled a stakeholder who disagreed with the data. Prepare three or four STAR stories with real numbers. The strongest answers show you chase the why behind a metric and that you can be wrong gracefully.
Sources
Keep reading
How to answer "tell me about yourself"
Answer "tell me about yourself" with a 60-90 second present-past-future pitch tailored to the role. The structure, a before/after example, and what not to do.
What questions should I ask the interviewer?
The best questions to ask an interviewer, organized by who you are talking to. Questions that signal seriousness, surface red flags, and the ones to avoid.
How do I prepare for a behavioral interview?
Prepare for a behavioral interview with the STAR method, a bank of 6-8 stories mapped to common competencies, and practicing out loud. Examples included.
Software engineer interview questions
The real software engineer interview loop — phone screen, coding, system design, behavioral — with representative questions per stage and how to prep.