Data Analyst interview questions

Data analyst interviews test SQL, how you turn data into decisions, and communication. Expect a SQL/case exercise plus behavioral questions about stakeholder work.

The questions

What data analysts are tested on

What each round is really testing

A data analyst loop is usually built from 6 kinds of question: SQL, Case, Behavioral, Communication, Fundamentals, Rigor. They are scored separately, which matters more than it sounds — being strong on the technical rounds does not offset a vague behavioural one, because a different interviewer writes that feedback against different criteria and never sees your other scores.

The framework under each question above is not a script to recite. It is the shape of a complete answer — the parts an interviewer is listening for and ticking off. Two candidates can give the same facts and score differently because one of them signposted the structure ("there were three constraints; let me take them in order") and the other produced the same content as an unstructured paragraph. Say the structure out loud; it is doing work.

Turning your own experience into answers

The most common preparation mistake is collecting questions and never building material. Your answers should come from your own work, and your resume is the index of it. Take a line like this one from the data analyst resume example:

Built a cohort-retention model identifying high-churn segments; targeting fixes lifted 12-month retention 58% → 71%

A resume bullet is the result with everything else compressed out. An interview answer is the same story decompressed: what the situation was and why it mattered, what you specifically owned, what you tried that did not work, and only then the number. Expect the follow-up to go straight at the part the bullet omits — how you measured it, what you would do differently, who disagreed with you. Prepare the decompressed version of four or five bullets and you have covered most behavioural rounds.

A week of preparation that works

Days one and two: write the decompressed version of five pieces of your own work, each ending in something measured. Day three: rehearse them out loud — this is the step almost everyone skips, and it is where you discover that an answer clear in your head takes ninety seconds and three restarts to say. Days four and five: work the technical questions above, talking through your reasoning rather than solving silently. Day six: prepare your own questions, which are assessed whether or not anyone tells you so. Day seven: rest, and re-read your own notes rather than adding new material.

If you only have an evening, do the spoken rehearsal. It has the highest return per minute of anything on this list, and it is the part that cannot be improvised on the day. AceCoach will ask these questions aloud and score the structure of what you say back, which is the closest thing to the real conditions you can get on your own.

Before the interview

Check the company's format as well as the role's questions — the same data analyst questions are asked very differently at a big-tech loop, an IT services process and a startup. See Big Tech, IT services & consulting or startups & finance. And make sure the resume that got you the interview can survive the questions it invites: everything on it is fair game, and the numbers attract the most scrutiny.

Earlier than the interview? How to become a data analyst covers the routes into this role, what to learn in what order, and what it pays measured from live postings.

Frameworks are guidance, not scripts — the point is to make the answers your own. All roles →

Assumption-making in SQL: how the best answers sound

A good SQL question answer starts with a statement of assumptions. If someone asks you to 'write a SQL query to find top three products by revenue per month', the best answer doesn't jump to code. It says 'I'm assuming the schema has a transactions table with product ID, amount, and transaction date. I'm assuming monthly means calendar month. I'm assuming top three means ranked by total revenue for that month'. Then you write the query. That framework—state assumptions, then execute—tells an interviewer you think critically and don't write code in a vacuum. It also protects you. If your assumption is wrong, she corrects you, and you adjust the query. If you just write code without stating it first, a wrong assumption makes your entire answer wrong.

The code itself should be written for readability, not cleverness. 'Use a window function to rank products by revenue within each month, then filter for rank <= 3' is how you'd describe it. The actual SQL would use RANK() OVER (PARTITION BY month ORDER BY revenue DESC) and a WHERE rank <= 3. That's straightforward and reads clearly. What you don't want is a subquery chain or a self-join that's harder to follow. Interviewers aren't testing your ability to write golf code; they're testing whether you understand the logic and can communicate it.

Performance considerations matter when they're relevant. If the table is millions of rows, you'd add a line: 'We'd want an index on product ID and transaction date to make this efficient'. If you're asked to improve an existing query, that's when performance becomes the main topic. But in a first-pass SQL question, stating the logical approach and writing clear code is more important than optimizing prematurely. The interviewer can always ask 'How would you make this faster?' If you've already thought about it, you get bonus points. If you haven't, you can think through it on the fly, which is also fine.

Ambiguity handling: when the data doesn't match the question

The case question 'Signups dropped twenty percent overnight. How do you investigate?' has ambiguity built in. The straightforward answer is to assume it's real and look for what changed. But a better answer starts by asking: is this real, or is it a data problem? That's the distinction a senior analyst makes. You can't fix what's actually a tracking bug by changing the product. The first move is to verify the data. Check whether the tracking event fired the same way yesterday as today. Check whether there's a data pipeline failure. Check whether the definition of 'signup' changed. Only after you've confirmed the drop is real do you move to the investigation.

Once you've confirmed it's real, the next step is segmentation. Twenty percent overall is different from 'fifty percent on mobile, five percent on desktop' or 'all the drop is in India while US is flat'. Each pattern suggests different root causes. A platform-specific drop points to a technical issue. A geo-specific drop points to operational or external factors. The investigation branches based on what the data shows. This is why the answer starts with 'I'd check the data first', then 'I'd segment by the dimensions that matter for this business', then 'I'd correlate with known changes'. Each step narrows the hypothesis.

The communication part of this is articulating uncertainty. It's easy to tell a story ('We ship a new feature and signups drop, so the feature caused it'). It's harder to say 'The timing correlates with our feature release, but we haven't ruled out that a competitor launched something or that the market got more competitive. I'd need to control for those before I'm confident.' That's the judgment a data analyst develops. It's also what interviewers listen for—not whether you can jump to a conclusion, but whether you're comfortable sitting with ambiguity long enough to test it.

Communication to stakeholders who aren't analysts

The question 'Explain a statistically insignificant result to a non-technical stakeholder' is testing whether you know when to avoid jargon and how to translate data into decision language. The bad answer is 'The p-value is 0.15 so the result is not significant'. Most business people don't know what a p-value is and don't care. The good answer is 'We tested whether the change improved conversion, but the difference we saw could easily have happened by chance. We'd need either a bigger sample or a bigger effect size to be confident it actually worked'. Now the stakeholder understands: the change might be good, but we don't have enough evidence yet.

The one analogy per answer rule matters here. Instead of trying to explain statistical significance, you might say 'Imagine we flipped a coin and got six heads in ten flips. That doesn't prove the coin is biased; that happens by chance fairly often. Our result is similar—the improvement we saw is within the range of normal variation.' That analogy is concrete and doesn't require statistical training to understand. It's also honest. After you've used the analogy, you state the decision implication clearly: 'We should keep testing before we ship this to everyone' or 'We should run a bigger test to be confident'. The stakeholder now knows what to do.

Confidence statements matter more than precision. Rather than saying 'We're 84% confident', say 'This result supports the change, but I'm not highly confident yet. I'd recommend testing more users.' The second phrasing signals humility and professional judgment. It also avoids false precision—a p-value of 0.12 is roughly equivalent to a p-value of 0.08 in practice, but they sound different. Grouping results into 'very confident' (low p-value), 'somewhat confident' (marginal p-value), and 'not confident' (high p-value) communicates uncertainty while avoiding the technical jargon that makes stakeholders tune out.

Frequently asked questions