Data science interview prep is harder to plan than most interview prep, because the title covers four different jobs and each company tests the slice it needs. One loop is mostly SQL and metrics. Another is statistics and experiment design. A third wants you to code k-means from scratch. Most people respond by reading a list of 100 questions, and then find out in the room that knowing an answer and saying it under follow-up questions are different skills.
This guide is for candidates with a loop coming up in the next few weeks. It covers what each round tests, real question types with examples, one answer worked from start to finish, the mistakes that cost people offers, and a two-week plan. I teach it through a course we built, Data Science Interview Prep: AI Coach Edition, because the course is where you can practise each idea out loud. You can use the guide without it.
What a data science interview tests, round by round
Start with the job posting. Verbs like “define metrics, run experiments, inform leadership” point to a product analytics role, where SQL, product sense and A/B testing carry the loop. Verbs like “productionize, deploy” point to a machine learning role, where modelling and evaluation matter more. “Causal inference” and “statistical methodology” point to a full-stack role that mixes both. Pipelines and processing at scale mean data engineering. Smaller companies blur these lines, so expect to be tested on more of the list.
Once you know the flavour, the loop is fairly predictable. These are the common rounds and lengths, as the course’s first reading lays them out.
| Round | Typical length | What it tests |
|---|---|---|
| Technical screen | 30 to 60 minutes | Two to four questions with definite answers in SQL, statistics, ML or Python |
| Statistics and experimentation | About 60 minutes, often more than one round | Concepts, calculations, and designing and reading an A/B test |
| SQL | About 60 minutes | One or two tables: joins, aggregates, filters, window functions |
| Product sense | 45 to 60 minutes | Metrics, root cause, what to do next |
| ML coding and ML concepts | About 60 minutes each | Training and evaluating a model, and explaining how algorithms trade off |
| Behavioral and past project | 30 to 60 minutes | One project, probed hard on choices and impact |
| Take-home | Varies | A dataset and a loose brief |
Two things about these rounds are easy to miss. Screens reward correctness: the interviewer is trimming the funnel, so a right answer beats an elegant explanation of a wrong one. And experimentation rounds reward end-to-end thinking, which means designing the test, saying what could go wrong, and explaining the result to a product manager.
Data science interview questions by type, with real examples
Every question below comes from a mock interview in the course, so these are the prompts you would actually hear.
Statistics interview questions
“You flip a coin ten times and get ten heads. What is the probability the coin is fair?” The trap is answering with one over two to the tenth. That is the chance of the data given a fair coin. The question asks the reverse, so you need a prior, and the answer changes with it.
“What is a p-value? Explain it the way you would to a product manager.” This one is graded on the second sentence. A p-value is how surprising the data would be if nothing had changed. It is not the chance the null is true, and it is not the size of the effect.
A/B testing interview questions
“Sign-up conversion is 20%. We want to detect an absolute lift of 2 percentage points. Alpha 0.05 two-sided, 80% power. About how many users per group? We get 6,000 eligible users a day. How long should the test run?” The interviewer wants the inputs named, the arithmetic roughly right, and the run rounded up to full weeks so weekdays and weekends are both covered.
“An experiment came back flat, with p equal to 0.4. The PM says the feature doesn’t work and wants to kill it. What do you say?” A flat result is not proof of no effect. A strong answer asks whether the test had the power to see the lift it was looking for. If you want more of this style, our earlier walkthrough of an A/B testing case on Facebook ads revenue covers the product manager’s side of the same question.
SQL interview questions
The medium SQL mock asks for the second-highest distinct booking amount in each city, conversion rate by acquisition channel, and listeners whose listening time grew three calendar months in a row. None of these is exotic. They test ties, NULLs, fan-out after a join, and LAG. SQL interview practice works best when you predict the row count before you run anything, because that habit catches a wrong join before the interviewer does.
Product sense and analytics case questions
“Weekly completed bookings on a large home-rental app fell seven percent compared with the week before. Walk me through how you’d find the root cause.” In the mock, the facts are hidden until you ask for them. If you ask about platform, you learn that mobile web is down twenty-four percent while the apps barely moved. If you never ask, you never find it. That is how real case rounds work, and it is why reading model answers does not prepare you for them.
Machine learning interview questions
“Explain the bias-variance trade-off,” followed by “How would you tell from training and validation error which problem you have?” Then an applied one: “You’re a data scientist at a payments company. Design a model that flags fraudulent transactions. Take me from framing to production.” The first checks the concept. The second checks whether you reach for accuracy on a dataset where almost nothing is fraud.
A worked example: is the new checkout faster?
Here is one problem from the hypothesis testing coach session, worked the way the coach walks it. The old checkout took a mean of 52 seconds across 100 users, with a standard deviation of 20. The new one took 46 seconds across 100 users, with a standard deviation of 18. Is the new checkout faster?
The coach, Maya, first puts a seven-step pattern on the notepad: hypotheses, pick the test, choose alpha with the interviewer, compute the statistic, find the rejection region or p-value, decide, then translate. Her point is that step seven is where strong candidates pull ahead.
- AHypothesesNull: the means are equal. Alternative: they differ. Two-sided, because a slower checkout matters too.
- BTestTwo-sample t-test, Welch’s version since the spreads differ.
- CDifference and standard errorMinus 6 seconds. Standard error: the square root of 4 plus 3.24, about 2.69.
- DStatistict is about minus 2.23, beyond the critical value of 1.97. p is about 0.03.
- EDecision, in one sentence for the PMAbout 6 seconds faster, with a 95% interval from 0.7 to 11.3 seconds.
A weak close is “p is 0.03, so it’s significant.” A strong close sounds like this: the new checkout is about six seconds faster, roughly twelve percent. The 95% interval runs from about 0.7 to 11.3 seconds, so the gain is real but could be small. Before we ship, I would check that it holds across segments and that conversion did not move the wrong way. The second version reports an effect size, an interval and a next step, which is what the mock’s rubric rewards.
Common mistakes in data science interviews
These come straight from the “weak” lines in the course rubrics, which is to say they are what interviewers mark down.
- Saying “there is a 95% chance the true mean is in this interval.” Confidence describes the method across repeated samples. Any one interval either contains the true value or does not.
- Saying “p is 0.2, so there is no effect.” You failed to detect one. That is a different claim.
- Naming a test with no design: no randomization unit, no metric, no reason for the alpha.
- Switching to a one-sided test after seeing the data because it makes the result significant.
- Counting with COUNT(*) after a LEFT JOIN, which gives every unmatched row a count of one, or using NOT IN on a column that contains a NULL, which returns no rows at all.
- Reporting accuracy for a fraud model. A model that always says “not fraud” can be ninety percent accurate and catch nothing.
- Stopping at the number. No headline, no caveat, no recommendation.
Most of these are not knowledge gaps. People know the right definition and still say the wrong sentence under pressure, which is why this needs spoken practice.
How the data science interview prep course is built
The course has 29 modules, and each one follows the same order: read the notes, train with the coach, then take a mock. Across the course that comes to 29 readings, 16 coach sessions with Maya and 18 mock interviews with Daniel. The public course page lists 49 scenarios, because it also includes 15 older standalone practice sessions, such as extra A/B testing questions and SQL tutors, next to the module they fit.
Maya is a voice AI coach. Her sessions run about 15 to 20 minutes, and she asks you something at every step instead of lecturing. Daniel is an AI interviewer, and his mocks run 20 to 25 minutes. He does not teach, hint or praise. He asks from a question bank, probes with follow-ups like “Why that test?” and “What would you tell the PM?”, and saves the feedback for a written report after the call.
| Part of the course | Modules | Coach sessions | Mocks |
|---|---|---|---|
| Roles, the loop and the rubric | 2 | 0 | 0 |
| Statistics and experimentation | 7 | 6 | 7 |
| Past projects and take-homes | 2 | 1 | 1 |
| Python: pandas, probability and simulation | 2 | 2 | 2 |
| SQL: basics, aggregations, joins, window functions, three practice levels | 8 | 4 | 3 |
| Metrics, product design and data case studies | 3 | 2 | 3 |
| Machine learning: coding and concepts | 5 | 1 | 2 |
The statistics rounds are scored on five signals: statistics fundamentals, problem framing and hypotheses, real-world application, communication, and bias and confounding. The mock report scores each criterion out of 10 and maps the weighted result to a hire signal, where 6 to 7.9 reads as strong and 8 or above as very strong. For the hypothesis testing mock, the weights look like this.
The report also quotes your own lines back to you and gives a better version of each, which is the part I find most useful when I read one.
The lab: a live board the coach controls while she talks
Every coach session in this course runs on a Motion App. A Motion App is a live app that sits beside the call. The voice agent controls it while it talks, and the app tells the agent what you tap. We call them Motion Apps because the motion is the lesson: you watch the data move while the coach explains it, instead of hearing a description of a chart.
This course uses three of them. Stats Lab draws statistics and ML visuals for seven of the coach sessions. Query Lab is a SQL and pandas editor for five. Case Board handles the four case-style sessions on experimentation, take-homes, metrics and data cases. They load on their own when you open a coach session.
The loop inside each one is predict, then reveal. Maya asks a question, you tap a guess or say it, the board locks it in, and only then does the chart move to the truth. She will not reveal before you commit.
A few scenes from the labs, so you know what this looks like in practice:
- Power, as two curves. The board shows the world where nothing changed next to the world where the effect is real, two standard errors apart, with power at about 52%. Maya asks what happens if the true effect grows to 2.8 standard errors. You tap, and the curve slides until power reads about 80%.
- Fifty confidence intervals. Fifty samples, fifty intervals around a true mean, and 47 of them contain it. Drop to 80% confidence and the intervals narrow while nine of fifty miss. Maya calls it a ring toss: the peg is fixed, and the rings land around it or they do not.
- A rare condition and a positive test. In the probability session, the board counts the cases: only 9 of the 59 positives actually have the condition. Base rates swamp good tests.
- A join you write yourself. In Query Lab, two small tables of gym members and visits sit above an editor. You rewrite a RIGHT JOIN as a LEFT JOIN and tap Run. If you forget to swap the tables, the result shows three rows right, one missing and two extra, with a question about which table a LEFT JOIN keeps whole.
- A fraud threshold. In the ML session, you move the threshold on a model scoring 1,000 payments, 100 of them fraud, and watch the confusion matrix trade missed fraud for flagged good payments.
We have invested in these across our courses: Arch Lab for system design, Stats Lab and Query Lab here, an Estimation Lab, a Deploy Lab, a Defense Lab, and Merger, DCF and LBO labs for investment banking. The sibling guides cover the system design interview course, estimation interview prep, security engineer interview prep and the forward deployed engineer interview.
What it costs
The course content is free. There is no separate course fee, and nothing is locked behind a higher tier: every reading, coach session and mock is included. Voice sessions use the minutes on your plan, and you can start on the free plan, which includes 25 one-time minutes. At 15 to 25 minutes a session, that covers one coach session or one mock, which is enough to judge whether this way of practising suits you. The readings do not use minutes.
Tough Tongue AI builds voice AI agents, and this course is one of the things we have built with them. All our courses are listed at app.toughtongueai.com/course. If you are still comparing tools, I wrote up the AI mock interview platforms we tested in 2026, and for the coding rounds that some loops add there is a set of mock coding interviews.
A two-week data science interview prep plan
This plan assumes you already use statistics and SQL at work and can give it an hour or two a day. If the fundamentals are new, stretch the first week into two.
- 1Days 1 to 2: map the loopRead the roles and rubric modules. Mark your rounds. Take the statistics rapid-fire mock cold.
- 2Days 3 to 5: statistics and A/B testingProbability, hypothesis tests, power, experimentation. Coach first, then the mock.
- 3Days 6 to 8: SQLJoins and window functions in Query Lab, then the easy and medium SQL mocks.
- 4Days 9 to 10: product senseMetrics and metric drops, then a data case study mock.
- 5Days 11 to 12: ML or PythonWhichever your posting asks for. Model fundamentals, then the ML concepts mock.
- →Days 13 to 14: redo your weakest roundReread that report, retake the mock, and rehearse one past project.
Three habits make the plan work. Take each mock within a day of its coach session, while the idea is fresh. Read the report the same day and write down the one sentence you would say differently. And keep the last two days free: the course’s own advice is to redo the weakest round before moving on, and most people skip that step.
Where this leaves you
Most data science interview prep fails in the same place. The candidate knows the material and has never said it out loud to someone who pushes back. A reading list cannot fix that, and neither can a bank of model answers. What fixes it is saying the answer, getting a follow-up you did not plan for, and finding out which sentence fell apart.
That is what this course is for. If you have a loop coming up, open the Data Science Interview Prep course, run one coach session, and take the mock that follows it. One round will tell you more about where you stand than another afternoon of reading.
