Data scientist interview questions, with worked answers
Fourteen questions that data scientist interviews ask again and again. For each: what the interviewer is checking, a short answer, the full answer in plain words, a weak answer to avoid, and a likely follow-up.
Contents
How to use these questions
Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add from your own projects. Interviewers want the reasoning and the trade-offs, not formulas.
Things marked depends on the release or depends on the provider depend on a release or a provider. Check the current documentation before you quote a detail.
What a data scientist is expected to know
- PythonAsked in 62% of data scientist ads (as of 5 Nov 2026).Python for data: clean, tested notebooks and scripts, with pandas, scikit-learn and plots others can rerun. or RR for statistics and reports; common in research, pharma and insurance teams.: clean, rerunnable analysis with libraries such as pandasAsked in 5% of data scientist ads (as of 5 Nov 2026).Load, clean, join and reshape tables in Python; know where it gets slow on big data. (tables in Python) and scikit-learn (the standard machine learning toolkit).
- SQLAsked in 42% of data scientist ads (as of 5 Nov 2026).Pull and shape your own data: joins, aggregations and window functions, on large tables.: get your own data, join it correctly and summarise it, on large tables.
- StatisticsAsked in 20% of data scientist ads (as of 5 Nov 2026).Distributions, confidence intervals, hypothesis tests and their traps; enough to tell a real effect from noise.: sampling, confidence intervals, hypothesis tests, and the traps around them.
- Machine learningAsked in 52% of data scientist ads (as of 5 Nov 2026).Train, validate and compare models: splits, cross-validation, metrics, overfitting and leakage.: splitting data, cross-validation, choosing metrics, overfitting, and common models from linear regression to gradient boosting.
- Experiments: A/B tests (showing two versions to random groups and comparing), and what to do when you cannot run one.
- Production: how a model is shipped, monitored and retrained, with tools such as MLflowAsked in 6% of data scientist ads (as of 5 Nov 2026).Track experiments, parameters and model versions so a result can be found and repeated. depends on the release (which records experiments and model versions) and DockerAsked in 7% of data scientist ads (as of 5 Nov 2026).Package a model service with its dependencies so it runs the same everywhere..
- Deep learning, where the role needs it: PyTorchAsked in 15% of data scientist ads (as of 5 Nov 2026).The most common deep learning framework in new work: build, train and fine-tune neural networks. depends on the release for images, text or signals.
- Communication: explaining a result and its uncertainty to people who decide.
Experiments and statistics
How do you design an A/B test for a new checkout page, and how do you read the result?
What they check: that you fix the plan before the data comes in, and avoid the usual traps.
Short answer: "I agree one main metric, such as completed purchases per visitor, and the smallest change worth acting on. From that I work out how many visitors we need, split them at random, run the test for full weeks, and only read the result at the planned end. Then I report the size of the effect with its range, not just whether it is significant."
The full answer: An A/B test shows the old version (A) and the new one (B) to random groups. Before it starts: one primary metric, a few guardrail metrics that must not get worse (such as refunds or page speed), and the sample size, which depends on how small an effect we want to detect. During it: check that the groups are the size we expect, because an uneven split means something is broken. Do not stop early because it looks good; checking again and again ("peeking") makes false wins much more likely. After it: give the effect and its confidence interval, look at important segments only if planned, and turn the result into a decision.
A weak answer: "We run it until the p-value drops below 0.05, then ship." That is peeking, and it produces false wins.
Follow-up: "The test won overall but lost on mobile." Was mobile a planned segment? If not, treat it as a new question and test it on its own, rather than trusting a slice found afterwards.
Explain a p-value and a confidence interval to a product manager.
What they check: that you understand them well enough to say them simply and correctly.
Short answer: "The p-value says how surprising our result would be if the change really did nothing. A small p-value means 'unlikely to be pure luck', not 'the effect is big'. The confidence interval gives the range of effects that fit our data, which is what you need for a decision."
The full answer: A p-value is not the chance that the new version is better; that is the common mistake. It is the chance of seeing a difference at least this big if there were no real difference. A confidence interval, for example "between 1 and 4 more sales per thousand visitors", shows both the likely size and the uncertainty. If the whole range is worth having, ship; if it includes zero or harm, we do not know yet. With many metrics or many tests, some will look significant by chance, so we correct for that or fix one main metric in advance.
A weak answer: "The p-value is the probability that our hypothesis is true."
Follow-up: "The result is significant but tiny." Then it may be real and still not worth the cost of the change; the decision depends on the size, not the p-value.
Sales rose after a marketing campaign. How do you find out whether the campaign caused it?
What they check: that you separate correlation from cause, and know what to do without an experiment.
Short answer: "A rise after the campaign is not proof: the season, a price change or a competitor could explain it. I would compare with a group that did not see the campaign, such as regions where it did not run, and compare the change in both, not just the level."
The full answer: Correlation means two things move together; cause means one makes the other happen. The best evidence is a randomised test, holding back the campaign from a random group. When that was not done, look for a fair comparison: similar regions or customers who did not get it, and compare their change over the same period (this is called difference-in-differences). Check the trends were similar before the campaign. Look for other events at the same time. Then say how confident you are, and recommend a holdout group next time.
A weak answer: "Sales went up by a lot, so it clearly worked."
Follow-up: "There is no comparison group at all." Use the history: forecast what sales would have been from the past trend and season, and compare with what happened, with honest error bars.
Building and validating models
How do you tell whether a model is overfitting, and what do you do about it?
What they check: that you validate honestly and know the fixes.
Short answer: "Overfitting is when a model learns the noise of its training data and does worse on new data. I see it when training scores are much better than validation scores. I fix it with more data, a simpler model, regularisation, fewer features, or stopping training earlier, and I check with cross-validation."
The full answer: I keep three sets apart: training data to fit the model, validation data to choose settings, and a test set I look at once at the end. Cross-validation splits the training data into several parts and trains on all but one each time, so the estimate does not depend on one lucky split. Regularisation means penalising complexity, so the model prefers simple patterns. With trees, I limit their depth or the number of trees; with neural networks, I use dropout and early stopping. The final check is always data the model has never seen.
A weak answer: "Our accuracy on the training data is excellent."
Follow-up: "Cross-validation looks good, but the model fails in production." Suspect leakage or a difference between the training data and live data; check both.
What is data leakage? Tell me about a time you caught it.
What they check: that you know the most common reason a model looks too good.
Short answer: "Leakage is when the model is trained with information it would not have at the moment of a real prediction, so test scores look great and live results do not. I prevent it by asking for each feature: would I know this at prediction time?"
The full answer: Typical cases: a feature recorded after the outcome (a "cancellation reason" in a churn model), statistics such as averages computed on all the data before splitting, the same customer in both training and test sets, or random splits on data where time matters. The signs are a score that is suspiciously high, or one feature that explains almost everything. The fixes: split first and compute everything inside the training part, split by customer or by time where needed, and rebuild features as they looked on the day of the prediction.
A weak answer: "Leakage is when data is stolen." That is a different kind of leak.
Follow-up: "Your best feature turns out to leak. The model is now much worse." Good: the honest number is the one the business will see. Tell people early and work from there.
A fraud model is 99 percent accurate. Is it good?
What they check: that you know accuracy misleads when one class is rare, and can choose a better measure.
Short answer: "Not necessarily. If one transaction in a hundred is fraud, a model that always says 'not fraud' is 99 percent accurate and useless. I would look at precision, how many flagged cases are really fraud, and recall, how many frauds we catch, and pick the threshold with the business cost of each mistake."
The full answer: With rare classes, measure what matters: precision (of the cases we flag, how many are right) and recall (of the real cases, how many we find). They trade off: a lower threshold catches more fraud but flags more honest customers. The precision-recall curve shows that trade-off for every threshold. The right point depends on costs: a missed fraud costs money, a false alarm costs a customer's goodwill and an analyst's time. For training, reweighting or resampling the rare class can help, but the evaluation must be on data with the real mix.
A weak answer: "Yes, 99 percent is excellent."
Follow-up: "The fraud team can only review a few hundred cases a day." Then rank by risk and measure precision among the top cases they can review; that is the number that matters.
Why do you start with a baseline, and what would yours be?
What they check: that you measure a model against something simple before claiming it adds value.
Short answer: "A baseline is the simplest reasonable answer, such as last month's value, the average, or a business rule already in use. If my model does not clearly beat it, the model is not worth its cost."
The full answer: A baseline tells you how hard the problem really is and keeps everyone honest. For a forecast: same week last year, or the recent average. For classification: the most common class, or the rule the team uses today. Then a simple model, such as a linear or logistic regression. Only then a complex one, and only if it beats the simple ones by enough to pay for being harder to explain, run and maintain.
A weak answer: going straight to a deep neural network.
Follow-up: "The simple rule is almost as good as your model." Say so, ship the rule if it is enough, and spend the time on a problem where a model makes a real difference.
How do you validate a model that forecasts weekly sales?
What they check: that you respect time order in the data.
Short answer: "I never shuffle time series data. I train on the past and test on the period after it, and repeat that for several cut-off dates, which is called a rolling or walk-forward validation. I compare with a seasonal baseline, such as the same week last year."
The full answer: A random split lets the model peek at the future, which is leakage. Walk-forward validation mimics real use: train up to a date, forecast the next weeks, move the date, repeat. Use only features known at forecast time: planned promotions yes, actual weather for next week no, unless you use the weather forecast. Measure the error in units the business understands, such as percent of sales or units of stock, and look at the weeks that matter most, such as holidays.
A weak answer: "I use normal cross-validation with random folds."
Follow-up: "A pandemic year is in the data." Mark it, test with and without it, and tell the planners how much it changes the forecast.
Data and features
How do you deal with missing values and outliers?
What they check: that you ask why the data is missing before you fill it in.
Short answer: "First I find out why values are missing or extreme, because the reason decides the fix. Then I fill, flag or drop them on purpose, and check that the choice does not change the conclusion."
The full answer: Missing at random (a sensor failed now and then) can be filled with a simple value or a model, and I add a flag so the model knows it was filled. Missing for a reason (people with high income skip the income question) carries information, so the flag itself is a feature. For outliers: a data error (an age of 200) is fixed or removed; a real but rare value (one very large customer) stays, perhaps with a model that is less sensitive to extremes. Any filling is learned on the training data only, to avoid leakage.
A weak answer: "I drop every row with a missing value." That can throw away most of the data and bias what is left.
Follow-up: "Half the values of an important column are missing." Ask the people who collect it why; often the fix is upstream, not in the model.
How would you get each customer's most recent purchase from a very large table?
What they check: that you can shape data in SQL, the everyday part of the job.
Short answer: "I would number each customer's purchases from newest to oldest with a window function, then keep only number one. That is one pass over the table, and an index on customer and date makes it fast."
The full answer: A window function calculates something across related rows, here all the rows of one customer, without collapsing them into one. Numbering the rows within each customer by date and keeping the first gives the latest purchase, and ties can be broken by a second column. The alternative, grouping by customer to find the latest date and joining back, works too but is easier to get wrong when two purchases share a date. On really big data the same idea runs in SparkAsked in 7% of data scientist ads (as of 5 Nov 2026).Process data too big for one machine, often on Databricks or a cloud platform. depends on the provider. I would also check the result: one row per customer, and the same number of customers as in the source.
A weak answer: "I would load the whole table into pandas and sort it." Fine for a sample, not for billions of rows.
Follow-up: "Some customers have no purchase." Start from the customer table and join the purchases, so those customers stay in with an empty value.
Models in production
Your model worked well at launch. Six months later it is worse. What happened, and how would you have caught it?
What they check: that you think about a model after launch: monitoring, drift and retraining.
Short answer: "Most likely drift: the data or the world changed, so the patterns the model learned no longer hold. I would have caught it by monitoring the inputs, the predictions and, when they arrive, the real outcomes, with alerts, and by retraining on a schedule or when drift appears."
The full answer: Data drift means the inputs look different, for example a new customer group. Concept drift means the link between inputs and outcome changed, for example a competitor changed prices. Monitor the distribution of key inputs against the training data, the share of each prediction, and the real accuracy once outcomes are known. Also watch for plain breakage: a column that suddenly arrives empty. Keep every model version and its training data recorded, with a tool such as MLflowAsked in 6% of data scientist ads (as of 5 Nov 2026).Track experiments, parameters and model versions so a result can be found and repeated. depends on the release, so you can compare and roll back. Retrain on recent data, compare with the current model on the same test period, and only replace it if it is better.
A weak answer: "Models do not change once they are trained, so they should keep working."
Follow-up: "Outcomes only arrive three months later." Watch the inputs and predictions in the meantime; they warn you early.
When would you use gradient boosting and when a neural network?
What they check: that you choose the tool by the data, not by fashion.
Short answer: "For tables of business data, gradient boosted trees are usually the strongest and quickest choice. For images, sound and free text, neural networks win, often starting from a pretrained model."
The full answer: Gradient boosting builds many small decision trees, each correcting the mistakes of the ones before. On tabular data with a mix of numbers and categories it is accurate, fast to train and fairly easy to explain. Neural networks shine where the raw input is complex, such as pixels or words, and where lots of data or a pretrained model is available; PyTorchAsked in 15% of data scientist ads (as of 5 Nov 2026).The most common deep learning framework in new work: build, train and fine-tune neural networks. depends on the release is the common framework. For text tasks, a large language model (LLMAsked in 25% of data scientist ads (as of 5 Nov 2026).Use large language models through an API for text tasks, and measure them like any other model.) through an API is now often the baseline to beat. Whatever the model, the validation and the comparison with a simple baseline stay the same.
A weak answer: "Deep learning is always more accurate."
Follow-up: "The business needs to understand every decision." A simpler model, or boosted trees with clear explanations, may be worth a little accuracy.
Working with the business
How do you explain why the model gave one customer a high risk score?
What they check: that you can make a model understandable and know the limits of the explanation.
Short answer: "I show the few factors that pushed this score up or down the most, in business words, with a tool that measures each feature's contribution, such as SHAP. I add how sure the model is, and what it does not know."
The full answer: For one prediction, contribution methods such as SHAP split the score into the part each feature added, so you can say "late payments raised the risk most; a long customer history lowered it". For the model overall, show which features matter most and how. Make clear that these explain the model, not the real world: a feature can matter to the model without causing the outcome. For decisions about people, such as credit or hiring, check the model for unfair differences between groups, and know the rules that apply.
A weak answer: "It is a black box, but it is accurate."
Follow-up: "The customer asks why they were refused." Give the main reasons in plain words and a way to have a person review it.
A stakeholder asks you to build a model to predict which customers will leave. Where do you start?
What they check: that you start from the decision, not the algorithm.
Short answer: "I start by asking what they will do with the prediction: who acts on it, when, and what an action costs. That decides what 'leaving' means, how far ahead to predict, which measure to optimise, and whether a model is even needed."
The full answer: Agree the definition first: no purchase for ninety days, a cancelled contract? Agree the timing: a prediction is only useful if there is time to act. Agree the action and its capacity: if the team can call two hundred customers a week, the model must rank well at the top. Find the data and check it is available at prediction time. Build a simple baseline, then a model, and measure them against the decision, ideally with a test where some high-risk customers are contacted and some are not. Keep the stakeholder involved at each step, so the result is something they trust and use.
A weak answer: "I would pull all the data and try a few algorithms."
Follow-up: "The model predicts well, but contacting customers does not keep them." Then the prediction is not the problem; test different actions, or predict who can be persuaded rather than who will leave.
Your CV for these questions
Every answer above is easier when your CV already says it, because interviewers ask about what is on it. Put one line under each job for each of these, in the words the ads use:
| Skill | Weak line | Strong line, with proof |
|---|---|---|
| A/B testingAsked in 20% of data scientist ads (as of 5 Nov 2026).Distributions, confidence intervals, hypothesis tests and their traps; enough to tell a real effect from noise. | A/B testing. | Ran 14 checkout experiments with a fixed plan; 3 shipped and lifted conversion by 6%. |
| Machine learningAsked in 52% of data scientist ads (as of 5 Nov 2026).Train, validate and compare models: splits, cross-validation, metrics, overfitting and leakage. | Machine learning models. | Churn model ranked for the call team's capacity; at-risk customers kept rose by a fifth. |
| SQLAsked in 42% of data scientist ads (as of 5 Nov 2026).Pull and shape your own data: joins, aggregations and window functions, on large tables. | SQL. | Rebuilt the forecast data set in SQL from 6 sources; forecast error fell from 18% to 11%. |
| MLflowAsked in 6% of data scientist ads (as of 5 Nov 2026).Track experiments, parameters and model versions so a result can be found and repeated. depends on the release | MLOps tools. | Tracked every model version in MLflow with drift alerts; two silent failures caught before users saw them. |
| PythonAsked in 62% of data scientist ads (as of 5 Nov 2026).Python for data: clean, tested notebooks and scripts, with pandas, scikit-learn and plots others can rerun. | Python. | Python pipeline replaced a manual pricing spreadsheet; a day of work saved each week. |
Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.
Key takeaways
- Fix the plan of an A/B test before the data arrives, and never stop it early because it looks good.
- Validate honestly: separate test data, cross-validation, time order for time series, and no leakage.
- With rare outcomes, use precision and recall, and set the threshold by the cost of each mistake.
- Always compare with a simple baseline; monitor models for drift after launch.
- Start from the business decision, and back every answer with a CV line that has a result in it.
Frequently asked questions
- What do data scientist interviews ask most?
- Statistics and experiments, how you validate a model, how you choose a metric, SQL and data cleaning, how models run in production, and how you explain results. Many include a take-home or live analysis.
- How much maths do I need?
- Enough to explain the methods you use in plain words: probability, distributions, regression and how models learn. Research roles go deeper.
- How should I prepare for the take-home task?
- Answer the business question first, keep the analysis rerunnable, compare with a baseline, state your assumptions, and finish with a short recommendation.
- Do I need deep learning?
- Only for roles with images, text, speech or very large data. Many data scientist jobs use statistics and gradient boosted trees far more.
- Are these answers tied to one tool?
- No. They work in Python or R and on any cloud. Where a detail depends on a version or a provider it is marked.