A data scientist recruitment process almost always combines several types of tests: a conversation about your background, statistics questions, machine learning questions, a coding or SQL exercise, a business case and an in-depth discussion of the projects on your resume. Each family of questions assesses a different skill, and candidates rarely fail for lack of raw knowledge. They fail more often because they recite instead of reasoning, or because they cannot link a technique to a real problem. This article reviews the main families of questions, what each answer must show and the mistakes that cost you the offer.
The families of questions in a data interview
Depending on the company, the role and the level, the mix varies, but six families almost always appear.
- Background and motivation: why data science, why this company, which projects taught you the most.
- Statistics and probability: inference, tests, intervals, bias, experimentation.
- Machine learning: choosing models and how they work, evaluation, overfitting, imbalanced data.
- Code and SQL: data manipulation in Python, SQL queries, sometimes a simple algorithm exercise.
- The business case: an open-ended problem linked to the company’s activity, to be solved by reasoning out loud.
- The projects on your resume: an in-depth discussion of one or two projects you led.
The Onisep job profile for the data scientist 🔗 highlights the dual nature of the role: technical skill in statistics and computing, and an ability to understand the company’s stakes. Interviews assess both.
The technical format also varies: oral questions, an online test, a take-home exercise on a dataset, or a live coding session. Our article on the take-home technical test details how to hand in an exercise of this kind, and the one on preparing for a technical interview describes how a process generally unfolds.
Statistics and probability
Statistics questions aim to check that you understand what you are calculating. They come up in almost every process, including for roles heavily focused on machine learning.
Frequent questions:
- What is a p-value, and what does it not tell you? The correct definition is expected (the probability of observing a result at least as extreme if the null hypothesis is true) and above all its limits: it measures neither the size of the effect nor the probability that the hypothesis is true.
- How do you design an A/B test? Choice of the primary metric, randomisation, sample size, duration, the risks of looking at results too early, novelty effects.
- What is the difference between correlation and causation? With an example of a confounding variable and a way to get closer to causation (experimentation, control group, quasi-experimental methods).
- What is a confidence interval? And how would you explain it to a business manager?
- Probability questions: dice rolls, draws, Bayes’ theorem applied to a screening test.
What the answer must show: an intuitive understanding, not just a formal one. A good reflex is to give the definition, then a concrete example, then a limit. If you have run A/B tests, link your answer to your experience: that is exactly what the interviewer hopes to hear.
Machine learning: understanding rather than reciting
Machine learning questions are where recitation shows the most. An experienced interviewer asks a textbook question, then a follow-up question that goes beyond the textbook.
Frequent questions and their follow-ups:
- Explain the bias-variance trade-off. Follow-up: "On your last project, did your model suffer more from one or the other, and how did you see it?"
- How does a random forest work, and gradient boosting? Follow-up: "Why does gradient boosting often win on tabular data, and when would you not use it?"
- How do you evaluate a classification model? Follow-up: "Your positive class is very rare: which metric do you choose, and how do you set the decision threshold?"
- What is data leakage? Follow-up: "Give an example you have encountered or could encounter in our business."
- How do you validate a model on time-series data? A validation that respects time order is expected, not a random split.
- How do you explain a model’s predictions to the business? Variable importance, SHAP values, individual examples, the limits of these methods.
What the answer must show: that you know how to choose a model and a metric according to the problem, not the other way round. Interviewers greatly appreciate candidates who say spontaneously when a simple method (a logistic regression, a business rule) is enough.
For roles closer to production, questions on deploying and monitoring models may be added. They belong more to the machine learning engineer’s job, but a data scientist must be able to say how their model will be used and tracked.
The business case
The business case is often the decisive test. The interviewer poses an open-ended problem linked to their activity: "Our users are cancelling their subscriptions: how would you help us?", "How would you measure the effect of a new recommendation feature?", "A campaign’s click-through rate has dropped: where do you start?"
A method that works:
- Clarify the goal. What does the company really want? To reduce cancellations, or to understand their causes? For which segment? Over what time horizon?
- Define the metric. How will success be measured? What is the primary metric, and what are the guardrail metrics?
- Take stock of the data. What data do you have, what is missing, what biases might it contain?
- Propose a simple approach first. A descriptive analysis, a segmentation, a baseline rule, before a complex model.
- Plan implementation and measurement. How will the business team use the result? How will you know whether it worked, ideally through an experiment?
- Name the risks. Side effects, bias, the cost of an error, regulatory constraints on personal data.
What the answer must show: an ability to structure a vague problem and to keep the end use in mind. A candidate who rushes to choose an algorithm before defining the metric loses points, even if the algorithm is relevant.
Defending the projects on your resume
The last family of questions is the most predictable, yet the most often poorly prepared. The interviewer picks a project from your resume and digs into it until they find the limit of your knowledge.
For each project on your resume, prepare:
- the business problem and the person or team who raised it;
- the data: origin, volume, quality, cleaning required, features built;
- the approach: the starting baseline, the models tried, the validation, the metric chosen and why;
- the result, measured honestly, and what it changed for the company;
- what did not work and what you would do differently.
The figures on your resume will be checked. If you write "AUC of 0.84 in temporal validation", expect to explain what AUC is, why a temporal validation, and what that score means for the business. The data scientist resume template presents projects at this level of detail, which you can use as a basis for preparation.
Also prepare the distinction from neighbouring jobs: you will sometimes be asked where your role ends and the data engineer’s begins. Our article on the data engineer job will help you put that boundary into words.
Even before the interview, it is your resume that steers the questions. It is better if it presents your projects clearly, with their data, method and effect. The TechCV editor lets you rework these bullets without worrying about the layout, and produces a document that recruitment software reads correctly. You can prepare your data scientist resume from the template.
Frequently asked questions
Should I revise mathematical proofs?
Rarely in detail, except for research roles. You do, however, need to understand the intuitions: why regularisation limits overfitting, why gradient boosting corrects successive errors, why multiple testing increases the risk of false positives.
What level of SQL is expected in a data scientist interview?
An operational level: joins, aggregations, subqueries and window functions. Many processes include an SQL exercise, sometimes an eliminatory one. Practise queries that compute indicators by period or by cohort.
How should I answer when I do not know?
Say so, then reason out loud from what you do know. An interviewer far prefers honest reasoning to an invented answer, which they will take apart with a follow-up question.
Are the questions the same at a startup and at a large group?
The families are the same; the mix changes. Startups often focus on autonomy and the business case; large groups and international tech companies more often add structured coding tests and several successive technical interviews.