Data analyst interview questions that test honesty about what the data doesn't say
SQL is testable directly and you should test it directly. What a technical exercise can't show is the part of analysis that actually causes damage: whether someone will tell a stakeholder the data doesn't support the conclusion they wanted, whether they state uncertainty instead of burying it, and whether they can explain a finding to someone who will act on it without understanding the method. Those are conversational, and they're what this page is for.
What the job actually involves
An analyst turns a vague business question into something answerable, gets the data, checks it, analyses it, and communicates the result to someone who will make a decision on it. The analysis is usually the smallest part. Defining the question and the communication at the end take longer and matter more.
The most expensive failures aren't technical. They are a number presented without its caveat, a correlation described in causal language, or a stakeholder who got the answer they wanted because nobody was willing to say otherwise. Every one of those is a communication and character problem, not a SQL problem.
The questions, and what a good answer sounds like
Ask these as written. Each one is paired with what a strong answer sounds like, so two people rating the same candidate reach the same conclusion for the same reason.
1. Your analysis contradicts what a senior stakeholder expected. Walk me through that conversation.
A good answer: Leads with the finding, shows the method, and holds the conclusion while genuinely inviting challenge to the method. Strong answers separate 'my analysis is wrong' from 'you dislike the answer'. This is the single most important question here.
2. You find an error in a dashboard people have been using for months.
A good answer: Tells people immediately, quantifies the impact, and fixes it. Any hesitation is worth probing hard — silent correction is how a team keeps trusting a number that was wrong all quarter.
3. How do you explain a result to someone who won't understand the method?
A good answer: Leads with the answer and the confidence, keeps the method available but not in the way, and is explicit about what the result doesn't tell them. The last part is what separates analysts from report generators.
4. A stakeholder asks a question that can't be answered with the data you have.
A good answer: Says so, offers the nearest answerable question, and names what would need to be collected. Producing something adjacent and letting it be read as the answer is the common and damaging alternative.
5. How do you check whether your own analysis is wrong?
A good answer: Concrete habits. Reconciling against a known total, sanity-checking magnitudes, having someone rerun it, testing the opposite hypothesis. Analysts without a self-check routine ship errors at a predictable rate.
6. Two data sources disagree.
A good answer: Finds out why instead of picking the more convenient one, and documents the discrepancy even after resolving it. Strong answers treat the disagreement itself as a finding.
7. You're asked to pull a number and you suspect it'll be used misleadingly.
A good answer: Provides it with the context attached, and says the concern out loud. The willingness to say it is what matters — an analyst who supplies numbers without caveats is an instrument over a colleague.
8. Tell me about an analysis that turned out to be wrong.
A good answer: A real one, with how it was caught and what changed afterwards. Everyone has one. A candidate who doesn't is either new or not checking.
A scorecard you can rate against
Rate every candidate 1 to 4 on each row, and write the rating down before you watch the next one. Ratings drift badly when they're relative to whoever you just saw.
| Criterion | What a 4 looks like |
|---|---|
| Holding an unwelcome finding | Defends the conclusion while inviting method challenge; a 2 softens the result. |
| Surfacing own errors | Reports a dashboard error immediately with impact. A 2 fixes it quietly. |
| Communicating limits | States what the result doesn't show; a 2 presents the number alone. |
| Refusing an unanswerable question | Says so and offers the nearest real question. A 2 produces something adjacent. |
| Self-checking | Names concrete verification habits. A 2 relies on care. |
How to run the screen
- Test SQL and analysis separately and directly. A short take-home with real messy data is the assessment. This round isn't.
- Use the recorded round for the stakeholder questions. Whether someone will hold an unwelcome finding is a character question and it shows in how they talk about it.
- Ask them to explain one chart from their exercise out loud. It is the closest thing to a work sample for the communication half of the role.
- Weight the dashboard-error question. Silent correction is a cultural signal that predicts a lot.
- Don't test statistics trivia. Look-up-able, and it displaces the questions that actually separate candidates.
Running this on a large applicant pool is where it gets expensive. VoxScreen sends these questions as a single link, transcribes and scores every answer against criteria you set, and hands back a ranked list. Free for 50 candidates a month, no card.
Common hiring mistakes for this role
- Hiring on tooling. Which BI tool someone knows is close to irrelevant and transfers in days.
- Testing only technical ability. The expensive failures in analysis are communication and candour failures, not query failures.
- Rewarding certainty. Analysts who never express uncertainty aren't more accurate, they're less honest about their intervals.
- Skipping the unwelcome-finding question. It is the best predictor of whether your analytics function tells you things you don't want to hear.
- Using a recorded round as the technical screen. It can't be one — pair it with a real exercise on messy data.
Common questions
What should I ask a data analyst in an interview?
Ask what happens when their analysis contradicts what a senior stakeholder expected, what they do on finding an error in a long-used dashboard, how they explain a result to someone who won't understand the method, and how they check their own work. Those cover the failures that actually cost money, none of which are SQL failures.
How do I test SQL skills for an analyst role?
Directly, with a short take-home using realistically messy data. Duplicates, nulls, a join that isn't quite one-to-one. That's the technical assessment. Keep it separate from the interview questions above, which test the communication and candour half of the job that no query exercise reaches.
What is the most overlooked quality in a data analyst?
Willingness to say the data doesn't support the conclusion someone wanted. It is rarely screened for and it determines whether your analytics function is a source of truth or a service that produces supporting evidence. The stakeholder-disagreement question is the fastest way to see it.
Should analysts be asked statistics trivia?
No. Definitions are look-up-able and testing them displaces questions with real signal. If statistical judgement matters for the role, test it in context. Give a result and ask what would have to be true for it to be misleading, which is the actual skill.