Data Scientist Interview Questions: 20 Real Examples (+ How to Answer Them)

Data science loops are not scored, they're survived. Four or five rounds, each run by a different person, each able to end the process on its own — and a brilliant modelling round rarely rescues a weak SQL one, because the two people never compare notes until it's already over.

That changes how to prepare. The useful question isn't "what might they ask" but "what is this round trying to eliminate?" Each one has a specific failure it exists to catch, and the questions inside it are all variations on catching that failure.

The round that catches people who can't get their own data

Almost always first, often a screen. Fail here and nothing else gets seen.

1. Write a query that shows retention by signup cohort.
2. You've been given a table you've never seen. How do you check whether it's trustworthy?
3. Your numbers don't match the dashboard everyone uses. What do you do?
4. How do you handle missing data — and when is dropping rows genuinely fine?

Saying it out loud: question 3 looks like a debugging question and is really a temperament question. The wrong instinct is to assume the dashboard is right and quietly change your query to match: "I'd find out where they diverge before deciding who's wrong — usually it's a definition rather than a bug. Different date boundaries, one side filtering out internal accounts, or a different idea of what counts as active. And whichever way it lands, the definition needs writing down somewhere, because if two of us disagreed then two more will next quarter."

The SQL itself is table stakes and worth drilling separately — the question list for that round is here: SQL Interview Questions for Data Analysts.

The round that catches people who'd ship a false positive

The statistics round. Short, and the highest-variance round in the loop.

5. Explain a p-value to a product manager.
6. You ran twelve tests and one came back significant. What do you conclude?
7. How do you size an experiment — and what do you do when you can't reach that size?
8. When is a result statistically significant but not worth shipping?

Saying it out loud: question 5 is not testing whether you know the definition. It's testing whether you can give it away without mangling it, which is much harder: "It's the probability of seeing a difference at least this big if the change actually did nothing. So a small p-value means the result would be surprising in a world where the feature had no effect — it doesn't tell us the size of the effect, and it isn't the probability that we're right." The last clause is where most candidates quietly get it wrong, and every interviewer is listening for it.

Question 6 is the multiple-comparisons trap, and interviewers ask it because it's the most common real-world error in the job. The answer they want includes what you'd do next — hold the finding as a hypothesis and re-test it cleanly rather than reporting it.

The round that catches people who optimise the wrong thing

The modelling round. Longer, and where the most confident wrong answers happen.

9. Walk me through how you'd choose a model for this problem.
10. Your model is 97% accurate and completely useless. What happened?
11. How do you choose the metric you optimise, and who sets the threshold?
12. What is data leakage, and how have you caught it?
13. It works offline and fails in production. Why?

Saying it out loud: question 10 has an answer everyone reaches — class imbalance — and the strong version keeps going into what it costs: "Almost certainly the base rate. If two percent of transactions are fraud, predicting 'never fraud' gets me 98%. So accuracy is the wrong measure and I'd look at precision and recall separately — and which of those matters depends on what a mistake costs. Missing fraud costs money; flagging a good customer costs a relationship, and someone in the business has to tell me which one they'd rather have."

That last handoff is the part that separates levels. Question 11 asks it directly: candidates who set the threshold themselves are answering a technical question; candidates who take it to the person who owns the consequence are doing the job.

Question 13 rewards specifics over theory — training on a feature that isn't available at prediction time, a skew between the training distribution and live traffic, or a pipeline that computes a feature differently in production than in the notebook.

The round that catches people who answer before scoping

The product case. Weighted heaviest at senior level and prepared least.

14. Signups dropped fifteen percent last week. How do you investigate?
15. Should we launch this feature? How would you decide?
16. How would you measure whether our recommendation system is any good?
17. What would you do if the data genuinely can't answer the question?

Saying it out loud: question 17 is the integrity question of the case round, and the answer that scores says so plainly rather than promising a proxy: "I'd say what we can answer, what we can't, and what it would take — sometimes that's instrumentation we don't have yet, sometimes it's a test nobody wants to run. What I wouldn't do is hand over a number that looks like an answer to the original question but isn't, because that's worse than no answer. It gets acted on."

The round that catches people whose work never lands

Sometimes a formal presentation, sometimes just the last thirty minutes. It decides more offers than the modelling round does.

18. Explain your last project to someone non-technical.
19. Your analysis contradicts what leadership already believes. What do you do?
20. How do you know whether your work changed anything?

Saying it out loud: question 18 is graded on what you leave out. The instinct is chronological — the data, the cleaning, the model, the result — and it loses the listener before the result: "Start at the decision. 'We were about to spend three months building X. The analysis said the users asking for it were already churning for a different reason, so we did Y instead.' Then the method, only if they ask."

This is the single most common reason strong data scientists lose loops, and it's worth its own read: why your data science answers sound confusing in interviews. If your loop has a formal technical presentation, there's a full walkthrough of that round: the complete technical interview communication guide for data scientists.

Question 19 is a values question. What fails is either folding or going in with only the chart. What works is separating how confident you are from how much it matters, and bringing the version of the finding that survives their most likely objection.

Which of the five you should actually prepare

The rounds are independent, which means preparation should be too. Rank yourself honestly across the five and put your time into the weakest — not the most interesting one.

That advice sounds obvious and almost nobody follows it, because the modelling round is the enjoyable one to revise and the SQL screen is the one that quietly ends most loops. If you can only fix one thing before an interview, fix the round you'd least like to be asked about.

If the role leans toward pipelines and infrastructure rather than analysis, the neighbouring list is Data Engineer Interview Questions. If it leans toward reporting and business questions, it's SQL Interview Questions for Data Analysts — and it's worth asking which one the role really is before the loop starts.