The hardest part of an analyst's job is not the query. It's that the question you're handed is almost never the question that needs answering — and interviewers know it, so they hand you badly-formed requests on purpose and watch what you do first.
That's the thread running through this list. Every question below arrives the way work actually arrives: as a request from someone who already has an answer in mind. What separates candidates is whether they find the decision underneath it before opening a query editor.
That last one is deliberate. The SQL round is its own thing with its own preparation, and it's covered separately: SQL Interview Questions for Data Analysts for the questions, and how to talk through a SQL query live for the round where someone watches you write it.
"Can you pull this number?"
The most common request in the job, and the one most likely to be a decision in disguise.
- A stakeholder asks for "the number of active users". What do you ask before you start?
- How do you define a metric two different teams will both accept?
- You're asked for a number you're fairly sure will be misread. What do you do?
- How do you check your own number before you send it?
Saying it out loud: question 1 is the whole interview compressed into one request, and answering it directly is the failure. There is no such thing as "the number of active users" — there are about six of them: "Before anything, I'd ask what it's for, because the answer changes the definition. Active in the last day, week or month; does opening the app count or do they have to do something; do internal accounts count. If it's for a board slide I'd want the same definition we used last quarter more than I'd want the best one. If it's to decide whether a feature is working, 'active' probably means used that feature."
Question 4 is quietly a seniority question and most candidates skip it. Naming an actual check — the total against a known figure, a spot-check of five rows by hand, running it two ways and comparing — is worth more than the analysis that follows it.
"Why did it change?"
The diagnostic request. Almost always the live case round.
- Revenue dropped twelve percent last month. Walk me through your investigation.
- How do you tell a real change from normal variation?
- Two things correlate strongly. How do you decide whether to say anything causal?
- You investigate and can't find the cause. What do you report?
Segmenting immediately
“I'd break it down by region, channel and customer segment to find where the drop is concentrated.”
It's the right second step and the wrong first one. It assumes the drop is real, the tracking didn't change, and last month is comparable to the one before — three things the interviewer deliberately left out, and any of them can end the investigation in two minutes.
Trying to make it not a problem first
“First I'd try to kill it: did a tracking change ship, did a big customer's renewal move into this month, is there one fewer working day, did we change how we count refunds. Then whether twelve percent is even outside our normal monthly range. Then I'd segment — and I'd expect it to be concentrated somewhere rather than spread evenly, because a broad drop usually means a measurement problem.”
Same analysis, but you've earned the right to it. And the prediction at the end is what someone who has done this a dozen times says.
Saying it out loud: question 8 is the one candidates fear and it has a genuinely good answer. Interviewers ask it because inconclusive is the most common real outcome: "I'd report what I ruled out, because that's real work and it stops three other people repeating it. Then what remains as the most likely explanation, with how confident I am. And what it would take to be sure — usually instrumentation we don't have. What I wouldn't do is pick the most plausible-sounding cause and present it as the answer."
"Which one is better?"
The comparison round. Where the subtle statistical traps live.
- Two marketing channels bring different volumes at different quality. How do you compare them?
- How would you decide whether an A/B test result is trustworthy?
- What's Simpson's paradox, and have you run into something like it?
- How do you compare cohorts that aren't the same size or the same age?
Saying it out loud: question 11 is asked because it separates people who took a course from people who have been burned. Do not recite the definition alone — attach the shape it takes at work: "It's when a pattern in each subgroup reverses once you pool them, and it usually bites when the groups have very different sizes. The version I've hit is a channel that looks worse overall purely because it sends mostly mobile traffic, and mobile converts worse everywhere — so the channel wasn't worse, the mix was different. The tell is a surprising aggregate that nobody can explain, and the fix is to check whether the segments agree with the total."
Question 12 is the practical cousin of the same problem. Interviewers want to hear you'd compare cohorts at the same age rather than at the same date, because a cohort from last month has had less time to do anything.
The move that keeps repeating across the first three sections: the strong answer always establishes what's true before deciding what it means. Is the metric the one they need. Is the change real. Is the comparison fair. Analysts who skip that step produce work that's technically correct and quietly wrong, and everyone interviewing you has been on the receiving end of it at least once.
"Can you build a dashboard?"
The request that quietly turns into permanent maintenance.
- What makes a dashboard people actually use?
- Someone asks for a dashboard. When do you say no?
- What do you do with a dashboard nobody has opened in six months?
- Your ad-hoc analysis disagrees with the dashboard. Which is wrong?
Saying it out loud: question 14 is a scope question and a "no" question at once, and the answer that scores is not a refusal: "When the underlying question is a one-off. A dashboard is a promise to keep something accurate forever, and half of what gets requested is really one question someone will ask twice. So I'd ask what decision they'd make differently each week when they look at it — if there isn't one, a one-page answer serves them better and costs me nothing to maintain."
Question 13 rewards a specific opinion. The strongest answers name a constraint — one screen, a small number of metrics, every chart tied to a decision, and a defined owner — rather than listing design principles.
"What do you think we should do?"
The last round, and the one that decides whether you're hired as an analyst or as a query service.
- Your analysis points toward a decision. How far do you go in recommending it?
- How do you present a result that's inconclusive?
- A stakeholder pulls one chart out of your deck and uses it out of context. What do you do?
- How do you know whether your analysis was useful?
Saying it out loud: question 17 is where analysts either grow into the role or don't. Both extremes lose: refusing to recommend anything reads as junior, and recommending confidently past your evidence reads as reckless: "I'd give the recommendation and say what would change it. Something like: based on this I'd stop spending on that channel, and the thing that would change my mind is if the attribution window is hiding delayed conversions — which I couldn't rule out. That way they get a decision from me and they know exactly where it's soft."
Question 20 is worth having a real answer for. "It informed the strategy" is what people say when nothing happened; naming a decision that went a specific way is what people say when something did.
Analyst, scientist, or engineer
The three data titles overlap and companies use them loosely, which means the same answer can read as thorough in one loop and slow in another. It's worth finding out early which job the role actually is.
If the loop leans toward experimentation, modelling and statistics, the neighbouring list is Data Scientist Interview Questions. If it leans toward pipelines, warehouses and things breaking at three in the morning, it's Data Engineer Interview Questions. Asking which of the three this role is closest to is a good question to ask a recruiter, not an awkward one.
Practical target: take question 1 and answer it out loud — but do not give a number, and do not give more than three clarifying questions. Analysts under interview pressure either answer too fast or interrogate too long, and the version that sounds senior is short, specific, and ends by proposing a definition rather than waiting to be given one.




