Data Scientist
Data Scientist Interview Roadmap
A complete, end-to-end plan: what gets tested, how to prepare each pillar, and a week-by-week schedule.
1. Know the funnel before you prepare
Almost every DS loop is assembled from these building blocks. Which ones you get depends on the company, so ask your recruiter directly — "what are the rounds and what does each one assess?" is a normal, expected question.
| Round | What they're testing | Typical length |
|---|---|---|
| Recruiter screen | Fit, motivation, comp alignment, resume sanity | 20–30 min |
| Online assessment | SQL, stats MCQs, sometimes Python | 60–90 min |
| Technical screen | SQL + Python/pandas live coding | 45–60 min |
| Statistics & probability | Inference, distributions, reasoning under uncertainty | 45 min |
| ML depth | Model choice, tradeoffs, evaluation, your past projects | 45–60 min |
| Experimentation / A-B testing | Metric design, causal reasoning | 45 min |
| Product / business case | Framing ambiguous problems, metrics, root-cause analysis | 45 min |
| ML system design | End-to-end design of a real ML product | 45–60 min |
| Take-home | Independent analysis or modeling, plus write-up | 4–24 hrs |
| Hiring manager / behavioral | Collaboration, ownership, communication | 45 min |
Company archetypes matter. Big-tech "Data Scientist" roles are often analytics/experimentation-heavy (SQL + product sense + A/B testing dominate). "Applied Scientist" and ML-focused roles lean on modeling and ML system design. Startups compress everything into 2–3 broad rounds plus a take-home. Indian service companies and GCCs weight resume project depth, Python, SQL, and classical ML theory more heavily than product sense. Read the JD carefully and reweight your prep accordingly.
2. The eight pillars
Pillar 1 — SQL (highest ROI per hour)
This is where most candidates get eliminated, and it's the most learnable.
Must be automatic:
- All join types, including self-joins and anti-joins (
NOT EXISTS,LEFT JOIN ... IS NULL) - Aggregations with
GROUP BY/HAVING - Window functions:
ROW_NUMBER,RANK,DENSE_RANK,LAG,LEAD,SUM() OVER,AVG() OVER, moving windows with frame clauses - CTEs and nested subqueries; recursive CTEs at least once
CASE WHENfor conditional aggregation and pivoting- Date/time arithmetic, truncation, and bucketing
NULLsemantics (whyCOUNT(col)≠COUNT(*), whyNOT INbreaks with NULLs)
Classic problem patterns to drill until reflexive: Top-N per group · running and cumulative totals · month-over-month growth · deduplication · gaps and islands (consecutive streaks) · funnel conversion rates · cohort retention · median without a built-in function · first/last event per user · sessionization · year-over-year comparison via self-join
Practice: StrataScratch and DataLemur have the most realistic company-style questions. LeetCode Database and HackerRank SQL are good for volume. Target ~100 problems total, spread across difficulty.
Interview technique: narrate before you type. State your assumptions about the schema, sketch the logical steps out loud, then write. Prefer readable CTEs over one deeply nested query — interviewers score clarity.
Pillar 2 — Python and programming
pandas/numpy fluency: groupby + agg + transform, merge vs join vs concat, pivot_table, melt, reshaping, apply vs vectorization (and why vectorization matters), handling missing data, datetime handling, rolling windows, qcut/cut for binning.
Core programming: you rarely need hard algorithms, but you do need easy-to-medium comfort with arrays, strings, dictionaries/sets, sorting with custom keys, two pointers, basic recursion, and counting patterns. Roughly 60–80 LeetCode easy/medium problems is enough for most DS roles. If the Job description mentions "software engineering rigor" or the company is ML-infra-heavy, double that.
Also expected: writing a function with clean signatures and docstrings, basic complexity reasoning, and implementing something from scratch (k-means, gradient descent for linear regression, train/test split, a confusion matrix, cosine similarity) without libraries.
Pillar 3 — Statistics and probability
Foundations: mean/median/mode, variance, standard error vs standard deviation, skew and kurtosis, correlation vs covariance vs causation.
Distributions: Bernoulli, binomial, Poisson, uniform, normal, exponential, log-normal — and crucially when each one describes a real situation. Know the Central Limit Theorem well enough to explain why it makes inference possible.
Inference: hypothesis testing framework, null vs alternative, p-value (and what it is not), confidence intervals and their correct interpretation, Type I vs Type II error, statistical power, one-tailed vs two-tailed, t-test, z-test, paired t-test, chi-square test of independence, ANOVA, Mann-Whitney and other non-parametric alternatives, bootstrapping and permutation tests.
Probability: conditional probability, Bayes' theorem (expect at least one applied Bayes question — the classic being disease-test false-positive reasoning), law of total probability, expectation and variance algebra, combinatorics, Markov chains at a basic level.
Estimation theory: MLE, method of moments, bias-variance decomposition, consistency and unbiasedness, regularization interpreted as a prior.
Brainteaser-style favorites: expected number of coin flips until a pattern, birthday problem, Monty Hall, drawing without replacement, expected value of a game, simulating a fair coin from a biased one, uniform random from a stream (reservoir sampling).
Technique: for every answer, define your random variables and state your assumptions first. Interviewers care more about clean setup than a fast number.
Pillar 4 — Experimentation and causal inference
For product-facing DS roles this is often the single most differentiating round.
- Turning a vague product question into a testable hypothesis
- Choosing metrics: primary/success metric, secondary metrics, guardrail metrics, and why you need all three
- Randomization unit (user vs session vs cluster) and why the choice matters
- Sample size and duration calculation from baseline rate, MDE, power, and significance level
- Interpreting results: statistical vs practical significance, confidence intervals over bare p-values
- Common pitfalls: peeking / early stopping, multiple comparisons (Bonferroni, FDR), Simpson's paradox, novelty and primacy effects, network interference, sample ratio mismatch, seasonality, contamination
- Variance reduction: CUPED, stratification, covariate adjustment
- Advanced designs: sequential testing, bandits, switchback tests, holdouts, interleaving
- When you can't randomize: difference-in-differences, propensity score matching, instrumental variables, regression discontinuity, synthetic control
Best single resource: Trustworthy Online Controlled Experiments by Kohavi, Tang, and Xu. Read it properly — it maps almost one-to-one onto real interview questions.
Pillar 5 — Machine learning
Supervised models — know the mechanics, assumptions, and tradeoffs of each: linear regression (and its assumptions), logistic regression, regularized regression (L1 vs L2 and what each does to coefficients), decision trees, random forests, gradient boosting (XGBoost/LightGBM/CatBoost), SVMs, k-NN, Naive Bayes.
Unsupervised: k-means (including how to choose k and its failure modes), hierarchical clustering, DBSCAN, PCA, t-SNE/UMAP, anomaly detection approaches.
Evaluation: precision, recall, F1, specificity, ROC-AUC vs PR-AUC (and when AUC misleads on imbalanced data), log loss, RMSE vs MAE vs MAPE, R² and adjusted R², calibration curves, and how to pick a threshold from business costs rather than defaulting to 0.5.
Practical craft — heavily probed: train/validation/test discipline, cross-validation variants (k-fold, stratified, time-series split, group split), the bias-variance tradeoff, overfitting diagnosis and remedies, class imbalance (resampling, SMOTE, class weights, threshold moving), feature engineering and encoding strategies, feature selection, data leakage (a favorite trap — know target leakage and train-test contamination cold), missing-data strategies, outlier handling, hyperparameter search, ensembling and stacking, and interpretability (feature importance, SHAP, partial dependence).
Specialized topics as relevant to the role: time series (stationarity, ACF/PACF, ARIMA, seasonal decomposition, backtesting with rolling origin), NLP (TF-IDF, embeddings, transformers, fine-tuning), recommender systems (collaborative filtering, matrix factorization, cold start), deep learning fundamentals (backpropagation, activations, batch norm, dropout, optimizers, vanishing gradients, CNN/RNN/attention).
GenAI and LLMs now appear in many 2026 loops even for non-NLP roles: prompting vs RAG vs fine-tuning tradeoffs, embeddings and vector search, chunking strategies, hallucination mitigation, and — most importantly — how you'd evaluate an LLM system offline and online. Have an opinion, not just vocabulary.
Pillar 6 — ML system design
You'll be handed something like "design fraud detection for a payments app" or "build a recommendation system for a news feed." Use a consistent skeleton:
- Clarify — scope, scale, users, latency budget, constraints. Ask questions for the first 5 minutes; this is scored.
- Frame as an ML problem — what exactly is predicted, at what granularity, and is ML even the right tool?
- Metrics — offline model metrics, online business metrics, and guardrails.
- Data — sources, volume, labels (and how you obtain them; label delay and label noise are real issues), sampling strategy.
- Features — candidate features, freshness requirements, training/serving skew, feature store.
- Model — start with a strong simple baseline, then justify complexity.
- Evaluation — offline validation split respecting time, then a shadow/A-B rollout plan.
- Serving — batch vs real-time, latency, cost, fallbacks.
- Monitoring — data drift, concept drift, performance decay, retraining cadence, feedback loops.
- Risks — bias and fairness, adversarial behavior, edge cases, failure modes.
Reference: Designing Machine Learning Systems by Chip Huyen; Machine Learning System Design Interview by Aminian and Xu.
Pillar 7 — Product sense and business cases
Frequent formats:
- Metric definition: "How would you measure the success of feature X?" — define a north star, supporting metrics, and guardrails; discuss how each could be gamed.
- Metric drop diagnosis: "DAU fell 8% last Tuesday. What do you do?" — check data integrity first, then slice systematically (time, geo, platform, device, version, cohort, acquisition channel), separate internal from external causes, form and test hypotheses. Structure beats brilliance here.
- Tradeoff and prioritization: "Should we launch this even though retention dropped slightly?"
- Guesstimates and sizing: market or volume estimation with explicit assumptions.
Technique: always restate the goal, ask 2–3 clarifying questions, lay out your structure before diving in, and end with a clear recommendation and what you'd do next. Think out loud — silence reads as being stuck.
Pillar 8 — Behavioral and communication
Prepare 6–8 STAR stories (Situation, Task, Action, Result) that you can flex into many questions: a project you led, a conflict with a stakeholder, a time you were wrong, a time you influenced without authority, a failed model or experiment, a tight deadline, mentoring someone, and pushing back on a bad request.
Quantify every result. "Reduced churn prediction false positives by 22%, saving roughly ₹40L in wasted retention spend annually" lands; "improved the model" does not.
Your own projects are the most likely place you'll be caught out. For each resume project, be able to answer: why that model, what alternatives you rejected and why, how you validated, what the baseline was, what broke, what you'd do differently, and what the business impact was. Interviewers dig two or three layers deeper than most candidates prepare for.
3. Ten-week schedule
Assumes 12–15 hours per week. Compress to 5 weeks by doubling the pace; stretch to 16 if you're working full-time and starting from a weaker base.
Weeks 1–2 — Foundations and honest baseline Take a diagnostic: 10 SQL problems, 15 stats questions, one ML discussion with a friend. Note where you fail. Rebuild statistics fundamentals from the ground up. Begin daily SQL (3 problems/day, non-negotiable). Rewrite your resume around quantified impact.
Weeks 3–4 — SQL and Python to interview standard Push SQL into window functions and the classic patterns. Drill pandas daily. Start easy/medium LeetCode. By the end of week 4, you should solve a medium SQL problem in under 12 minutes while explaining it.
Weeks 5–6 — Statistics, probability, experimentation Work through hypothesis testing and probability problem sets. Read the Kohavi book. Design three A/B tests end to end on paper, including sample size math. Do one full experimentation mock.
Week 7 — Classical ML depth Go model by model: mechanics, assumptions, hyperparameters, when it fails. Practice explaining each in under two minutes to a non-technical listener, then in full technical depth. Drill evaluation metrics and leakage scenarios.
Week 8 — ML system design and product sense Do 8–10 system design problems out loud using the skeleton above. Do 8–10 product cases (metric definition, metric drop, tradeoff). Record yourself once — it's uncomfortable and extremely useful.
Week 9 — Mocks and project deep dives Four to five full mock interviews with real people (peers, Pramp, Interviewing.io, a paid coach, or a senior colleague). Write out and rehearse your project deep dives and STAR stories. Fix the specific gaps mocks reveal rather than adding new topics.
Week 10 — Applications and taper Apply in batches — schedule your lower-priority companies first so you're warmed up by the time your target company interviews. Keep daily light SQL and one problem per pillar. Do not learn new material in the final three days; consolidate notes instead.
Throughout: maintain a single "mistake log" — every question you got wrong, the correct reasoning, and the underlying concept. Review it weekly. This one habit produces more improvement than any other.
4. Core resources
Books
- Ace the Data Science Interview — Singh & Kumar (breadth, closest to actual question style)
- An Introduction to Statistical Learning — free PDF, the ML reference to actually finish
- Trustworthy Online Controlled Experiments — Kohavi et al. (experimentation)
- Designing Machine Learning Systems — Chip Huyen (system design)
- Practical Statistics for Data Scientists — Bruce & Bruce (fast stats refresher)
- Storytelling with Data — Knaflic (for take-homes and presentation rounds)
Practice platforms
- SQL: StrataScratch, DataLemur, LeetCode Database, HackerRank
- Python/DSA: LeetCode, HackerRank
- Stats/ML questions: Glassdoor company pages, Blind, r/datascience, company engineering blogs
- Mocks: Interviewing.io, Pramp, Exponent, or a study group of 2–3 peers
Company sources — engineering blogs from Airbnb, Netflix, Uber, Spotify, Meta, DoorDash, Swiggy, Zomato, and Flipkart describe the exact problems they interview on. Reading these is both prep and great material for showing genuine interest.
5. Common reasons strong candidates fail
- Silence. Thinking quietly is invisible. Narrate your reasoning continuously.
- Jumping to a solution without clarifying the problem or asking about constraints.
- Shallow project answers. If you can't defend a modeling choice on your own resume, that's fatal.
- Memorized definitions without application. Knowing "p-value" as a phrase but fumbling what it means for the decision at hand.
- Over-engineering. Reaching for a neural network when logistic regression is the right baseline. Interviewers reward starting simple and justifying complexity.
- Ignoring the business. Every technical answer should connect back to a decision someone makes.
- No questions for the interviewer. Prepare 3–4 specific ones per company.
- Neglecting SQL because it feels basic. It's the most common elimination point.
6. Interview-day checklist
Before: reread the JD and your own resume, review your mistake log and STAR stories, test your setup and internet, keep water and paper nearby, and have your questions written down.
During: restate the question in your own words, ask clarifying questions, state assumptions explicitly, structure before solving, think out loud, and when stuck say what you'd try and why rather than freezing. If you realize mid-answer that you were wrong, say so and correct course — that's a positive signal, not a negative one.
After: within 24 hours, write down every question you were asked while it's fresh. This becomes your best prep material for the next loop. Send a short thank-you note to the recruiter.
7. Rebalancing by role type
| Role emphasis | Reweight toward |
|---|---|
| Product / analytics DS | SQL, experimentation, product sense, metrics |
| ML engineer / applied scientist | Coding, ML depth, ML system design, deep learning |
| Research scientist | Statistics theory, papers, math derivations, publications |
| Startup generalist | Breadth, take-home quality, end-to-end ownership stories |
| Service company / GCC | Python, SQL, classical ML theory, project depth, domain fit |
Prioritize by expected value: SQL and your own project deep dives give the most improvement per hour for almost everyone. Start there.