Data
Updated 2026-10-18
Practice data scientist interviews across screens, manager conversations, modeling, and a final round.
Data science interviews ask whether you can frame a decision, build something that beats a simple baseline, and say where the model should not be trusted. Tool fluency helps. It does not replace a clear question, a label you can defend, and a story about a time the model was wrong in a way that mattered.
Keep two projects you can narrate without slides. For each, know the decision, the unit you predicted, the baseline, the error that worried you, and what a human still had to do. If the dataset was public or assigned in a course, say that before you quote a score. An honest small project is stronger than a borrowed leaderboard story.
Practice saying the limitation in the same breath as the result. Interviewers relax when you volunteer the slice where the model fails.
Try a free spoken mock for this job: 3 questions, feedback that quotes your own answers. No card.
Start the free mockThe screen is about problem type and communication. They want to know if you have worked on ranking, prediction, experimentation, or measurement, and whether you can explain it to someone who will not open a notebook. Skip the tour of every library. Name one problem and the decision it served.
1. What decision has a model or an analysis of yours actually supported?
What they are checking: They want a user or a business action, not a list of algorithms.
Follow-up: What did people do differently after they had the output?
2. Which parts of the work do you do yourself, from the label through the evaluation, and where do you pair with an engineer?
What they are checking: They are sorting research-heavy seats from product seats and listening for the handoff.
Follow-up: Tell me about a time the feature you wanted was not available in production. What did you do?
3. What kind of science work are you trying to move toward, and what are you glad to leave behind?
What they are checking: They want a preference that matches the team's actual mix of experiments, models, and partner requests.
Follow-up: If the quarter was mostly instrumentation and baselines, would that still interest you?
Managers listen for taste. They want someone who will refuse a model that looks clever and fails the simple comparison, and someone who can tell a partner the uncertainty without hiding. Bring a project where you killed an idea or narrowed it.
1. An approach looked strong in offline numbers and weak once people used it. What did you discover?
What they are checking: They want the gap between the offline setup and the live decision, and what you changed.
Follow-up: What would you instrument next time before you called the offline result good news?
2. A partner wanted a model for a problem you thought was a definition problem. How did you handle that?
What they are checking: They are listening for whether you can push back with a simpler measurement and still stay useful.
Follow-up: What did you offer them in the same week so the conversation was not only a no?
3. How do you decide that a model is ready for someone else to rely on?
What they are checking: They want a baseline comparison, a slice you do not trust, and a human fallback.
Follow-up: Who is allowed to override the output, and how do you hear about those overrides?
Expect a case, a metric critique, or a short modeling prompt. Start with the decision and the unit of prediction. Name the baseline before the fancy method. If you mention leakage, say which column would cause it. If you do not remember a formula, explain the idea and the failure mode.
1. How would you predict which accounts are likely to leave, and what baseline would you insist on beating?
What they are checking: They want the label window, a simple rule to beat, and the cost of a false alarm versus a miss.
Follow-up: Which slice of accounts would you refuse to score the same way?
2. Your training rows and your live rows do not look alike. How do you notice, and what do you do?
What they are checking: They are listening for a check on inputs, a monitor, and a decision to stop serving rather than hope.
Follow-up: What would you tell the partner while the model is paused?
3. Walk through an experiment where the headline result and a subgroup told different stories. Which one did you trust?
What they are checking: They want the question the experiment was meant to answer and a reason you did not average the conflict away.
Follow-up: What would you have needed in order to trust the subgroup?
Science work fails in public sometimes. The useful stories are about a wrong conclusion you corrected, a partner you taught without condescension, and a deadline you met with a smaller analysis. Leave out gossip about a research fight that had no decision in it.
1. You presented a result that later turned out to be wrong. How did you correct the people who heard it?
What they are checking: They want the same audience, a plain statement of what changed, and a check you added.
Follow-up: What in the original setup made the error easy to miss?
2. A teammate wanted to ship a model you did not trust. How did the disagreement go?
What they are checking: They are listening for the evidence you brought and for whether you could name what would change your mind.
Follow-up: What did you write down so the debate would not restart from zero the next week?
3. You had to explain uncertainty to a leader who wanted a single number. What did you say?
What they are checking: They want a range or a condition in ordinary language, not a lecture and not a fake precise figure.
Follow-up: What decision were they actually trying to make, and did your wording help them make it?
The last round often includes a product or engineering partner. They are asking whether you will be careful with their users and clear about what you will not promise. Ask how models are monitored, who owns the label, and what problem they wish someone would refuse.
1. How would you choose the first problem to touch if you joined this team next month?
What they are checking: They want you to look for a decision already being made badly, not to hunt for the most impressive dataset.
Follow-up: What would you leave as a simple report instead of a model?
2. What do you still need to hear about labels, monitoring, or the decision process before you would join?
What they are checking: A useful question here shows you know where science work usually breaks.
Follow-up: Which answer would make you ask for a different seat?
Restate the rows and the label, then write the simplest version that could be wrong in an obvious way. Talk through the edge case before you optimize. Asking whether they want a sketch or a running snippet is reasonable. Silence while you hunt for a library trick is not.
Name the course or the public dataset in the first clause. Then explain the decision you pretended to support, the baseline, and the mistake in the setup you would fix with real logs. The maturity is in the critique.
Say so, and show a measurement or an experiment you designed carefully. Many seats need that more than a novel architecture. Do not imply you trained a production model if you shipped a rule or a query.
Describe the slice, how you noticed, what you stopped or changed, and who you told. Do not minimize it and do not turn it into a speech about your values with no action. Interviewers are listening for the intervention.
Explain the assumption and the failure mode in words, and say which reference you would check before you shipped. Pretending to remember a derivation you do not know is worse than a clean "I would look that up and here is why it matters."
Practice questions written by Round Rehearsal. Not any employer's actual questions.
Try a free spoken mock for this job: 3 questions, feedback that quotes your own answers. No card.
Start the free mock