Data Science Interview Questions — Statistics, SQL, ML, and Case Studies

Most candidates who fail data science interviews don't fail on machine learning — they fail on the statistics question in round two that they assumed would be easy, or on the product case study round they never practiced because it felt too "soft" to drill.

The structure of a typical DS interview loop at a product company runs 4–5 rounds covering statistics and probability, SQL and data manipulation, ML concepts, product case studies, and Python or pandas coding. Candidates systematically over-prepare ML theory — transformers, backprop, regularisation — while walking into the statistics and product rounds underprepared. This guide covers all five areas with the actual data science interview questions that show up, plus a three-week prep structure that prioritizes by filtering rate.

What Data Science Interviews Actually Test in 2026

The gap between what candidates prepare and what interviewers actually weight is wide enough to flip outcomes. Here is how the five skill areas break down across a standard product-company DS loop:

The pattern holds across Flipkart, Swiggy, Razorpay, Coupang, and every other company on the platform. ML architecture questions appear — but a candidate who nails statistics and the product round will outplace a candidate who can explain attention mechanisms but fumbles a p-value definition.

Statistics and Probability: The Questions That Filter 60% of Candidates

Statistics questions in data science interviews are not definition recalls — they are applied reasoning checks dressed as definitions. An interviewer asking "what is the p-value?" is not looking for a textbook line. They are checking whether you will misinterpret an A/B test result in production.

Central Limit Theorem and why it matters for A/B testing

The CLT states that the sampling distribution of the sample mean converges to a normal distribution as n increases, regardless of the shape of the underlying population distribution — provided n ≥ 30 and finite variance. Interviewers do not ask you to prove this. They ask: "Why does the CLT matter when you run an A/B test?"

The answer is direct: it justifies using a z-test (or t-test for small samples) on your metric — say, average order value or session duration — even when that metric is not normally distributed in the raw data. Users' order values are right-skewed, session durations are right-skewed, and many engagement metrics are zero-inflated. None of that matters at n = 10,000 per variant because the distribution of sample means is approximately normal, making standard hypothesis testing valid.

The p-value misconception that eliminates candidates

The most common wrong answer in statistics rounds: "p-value is the probability the null hypothesis is true."

The correct definition: p-value = P(observing data this extreme or more extreme | null hypothesis is true). It is a conditional probability about the data given the null — not a probability about the null given the data. The second interpretation is the Bayesian posterior P(H₀ | data), which requires a prior and is a separate calculation.

Type I and Type II errors in product context

Abstract type-error definitions are useless in interviews without product grounding. Make them concrete:

• Type I error (false positive, α): You declare your A/B test a winner when the treatment actually has no effect. In practice: you ship a UI change that had no real impact on conversion, wasting engineering resources and potentially harming the metric you thought you were improving.
• Type II error (false negative, β): You fail to detect a real effect. In practice: you miss a genuine 3% revenue lift from a pricing experiment because your sample size was too small or your test ran for too few days.

α = 0.05 means you accept a 5% chance of shipping a false winner. Statistical power (1 − β) at 0.80 means you have an 80% chance of detecting a real effect at the minimum detectable effect size you specified. Both need to be set before the experiment runs, not after.

When to use t-test vs z-test vs chi-squared

This is a direct question at DS interviews and the answer has three clean rules:

• Z-test: continuous metric, known population variance or large n (≥ 30). The CLT makes this valid for most A/B tests at scale.
• T-test: continuous metric, small n or unknown population variance. Use it for experiments under 30 per variant or early-stage product tests where you cannot assume the CLT has kicked in.
• Chi-squared test: categorical outcomes — click vs no-click, convert vs no-convert. An A/B test measuring conversion rate (a proportion) uses chi-squared, not t-test. The test checks whether the distribution of categorical outcomes differs between groups.

Bayesian vs frequentist A/B testing

Frequentist testing (the standard) requires a fixed sample size, no peeking at results mid-experiment, and a hard α threshold. The advantage: clean statistical guarantees and industry-standard tooling.

Bayesian testing computes a posterior probability — "there is a 94% probability that variant B is better than control" — which updates continuously as data arrives and allows early stopping without inflating false positive rates the way frequentist early stopping does. Growth-stage companies with high traffic and pressure to ship fast increasingly prefer Bayesian frameworks (Optimizely, Statsig support both). In practice, frequentist remains the default at most analytics teams; Bayesian is the answer to "how would you handle an experiment where we need to stop early?"

SQL Interview Questions Data Scientists Actually Get Asked

Data scientist SQL interviews are not about SELECT basics — they test whether you can answer product questions from raw event tables. The questions that appear in real loops go well beyond what most online prep resources cover. For a deeper dive into SQL fundamentals for data roles, see the SQL interview questions for data engineering guide.

Window functions: the minimum bar

Every DS SQL round at a product company expects fluency with ROW_NUMBER, RANK, LAG, and LEAD. The questions that appear:

• "Compute a 7-day rolling average of daily active users" — AVG(dau) OVER (ORDER BY date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)
• "Rank products by revenue within each category" — RANK() OVER (PARTITION BY category ORDER BY revenue DESC)
• "Find the week-over-week change in sessions for each user segment" — sessions - LAG(sessions) OVER (PARTITION BY segment ORDER BY week)

User retention cohort query

This is the canonical DS interview SQL question. You will be asked to write it at Flipkart, Swiggy, Razorpay, and every growth-analytics-heavy company on the platform.

-- Day-7 retention: users who triggered an event exactly 7 days after signup
SELECT
    DATE(u.created_at)                    AS signup_date,
    DATE(e.event_time)                    AS event_date,
    COUNT(DISTINCT e.user_id)             AS retained_users
FROM users u
JOIN events e
    ON e.user_id = u.user_id
WHERE DATE_PART('day', e.event_time - u.created_at) = 7
GROUP BY signup_date, event_date
ORDER BY signup_date;

Extend it to a full retention matrix by replacing = 7 with IN (1, 3, 7, 14, 30) and adding day_number to the SELECT and GROUP BY. Interviewers check whether you use COUNT(DISTINCT user_id) — not COUNT(*) — to avoid double-counting users with multiple events on day 7.

"Find users who made a purchase within 7 days of signing up"

SELECT DISTINCT u.user_id, u.created_at, MIN(o.order_date) AS first_purchase
FROM users u
JOIN orders o
    ON o.user_id = u.user_id
   AND o.order_date BETWEEN u.created_at AND u.created_at + INTERVAL '7 days'
GROUP BY u.user_id, u.created_at;

The JOIN predicate filters to the 7-day window directly rather than filtering in WHERE after a full join — this is more efficient on large tables and signals query awareness that interviewers notice.

"Which product had the highest week-over-week growth?"

WITH weekly_revenue AS (
    SELECT
        product_id,
        DATE_TRUNC('week', order_date)        AS week_start,
        SUM(amount)                            AS revenue
    FROM orders
    GROUP BY product_id, week_start
),
wow_growth AS (
    SELECT
        product_id,
        week_start,
        revenue,
        LAG(revenue) OVER (PARTITION BY product_id ORDER BY week_start) AS prev_week_revenue,
        ROUND(
            100.0 * (revenue - LAG(revenue) OVER (PARTITION BY product_id ORDER BY week_start))
            / NULLIF(LAG(revenue) OVER (PARTITION BY product_id ORDER BY week_start), 0),
            2
        ) AS wow_growth_pct
    FROM weekly_revenue
)
SELECT product_id, week_start, revenue, prev_week_revenue, wow_growth_pct
FROM wow_growth
WHERE wow_growth_pct IS NOT NULL
ORDER BY wow_growth_pct DESC
LIMIT 1;

NULLIF(..., 0) prevents division-by-zero when the previous week had zero revenue — an edge case interviewers look for. State it explicitly.

Product Case Study Questions: The Round Most Candidates Underestimate

The product case study round is where senior-level DS hires are differentiated from mid-level hires at every company above 200 engineers. Most candidates underestimate it because it feels less technical — it is not. It requires structured analytical reasoning under time pressure, and the structure can be learned.

The four-step framework

Every product case study answer, whether it is a metric drop investigation or a metric design question, maps to the same four moves:

1. Clarify the metric you are optimizing. Do not assume the interviewer means CTR when they say "engagement dropped." Ask: "Are we looking at click-through rate, time-on-surface, shares, or something else?" This step signals product maturity and prevents five minutes of work on the wrong metric.

2. Identify potential causes systematically. Split into four buckets: user behavior change (did a cohort of users shift), product change (was a feature shipped or rolled back), external factor (iOS update, competitor launch, seasonal effect), data quality issue (tracking bug, instrumentation failure). Do not jump to explanations — exhausting the buckets first shows rigour.

3. Design the investigation. Name the specific data you would pull and what signal you are looking for. "I would segment the drop by platform first — if it's iOS only, that points to either an iOS-specific product change or the recent iOS privacy update. Then I'd check the event log for any feature flags toggled in the 48 hours before the drop." Concrete data steps, not vague "I'd look at the data."

4. Propose a measurement framework. End with how you would confirm your hypothesis and what you would recommend next. "If the drop is isolated to iOS and correlates with the iOS 18.1 rollout, I'd run a holdout on the old tracking implementation to quantify the attribution loss before making any product decision."

Real examples used in loops

"Instagram Reels engagement dropped 15% on iOS. What do you do?"

Step 1: Clarify — "By engagement, do we mean watch-through rate, likes, shares, or a composite score?" Step 2: Buckets — iOS tracking change (ATT prompt, iOS privacy update), Reels algorithm change, content quality change in the iOS cohort, or a broader iOS app performance regression. Step 3: Segment by platform and app version. If the drop is iOS-only and aligns with an iOS release date, that is the prime suspect. Step 4: Isolate the iOS cohort in a controlled rollout and compare metric trends before and after the OS release date.

"Design a metric to measure the health of a marketplace."

A marketplace has two sides — supply and seller health, demand and buyer health — and the relationship between them: match rate. A strong single metric is Gross Merchandise Value per session, because it combines supply availability (are the right products listed), demand signal (are buyers landing and browsing), and conversion (are they transacting). Secondary guardrails: cancellation rate (supply reliability), time-to-first-purchase for new buyers (demand activation), and seller churn rate (supply retention). Interviewers want to see you define a north-star metric and name guardrails that prevent gaming it.

ML Concepts DS Interviews Test (vs What MLE Interviews Test)

Data scientist interviews at product companies go lighter on deep learning architecture and heavier on applied ML for tabular data. You will not be asked to explain self-attention in detail. You will be asked when to use logistic regression vs a tree-based model and what happens to feature importance when you add correlated features.

For a comprehensive treatment of ML interview depth, see ML Fundamentals on KnowEaseAI.

Linear vs logistic regression

Linear regression predicts a continuous outcome; logistic regression predicts a probability for a binary outcome via the logit link function. The key interview question: "How do you interpret a coefficient in logistic regression?" The answer: a one-unit increase in feature X changes the log-odds of the outcome by the coefficient value. To communicate it to a non-technical stakeholder, exponentiate the coefficient — that gives the odds ratio. A coefficient of 0.7 means the odds of the positive class multiply by e^0.7 ≈ 2.01 for each unit increase in X.

Use linear regression when the residuals can reasonably be assumed normal and the outcome is unbounded. Use logistic regression when the outcome is binary and you need calibrated probability estimates (e.g., churn prediction, click probability).

Decision trees and when they fail

Decision trees have high variance — small changes in training data produce very different trees. They are also sensitive to feature scale (despite being non-parametric in other ways), and they overfit on noisy datasets without aggressive pruning. The variance problem is why no production ML system uses a single decision tree: you ensemble them.

Gradient boosting vs random forest

Random forest builds trees in parallel on bootstrap samples with feature subsampling at each split, averages the predictions, and reduces variance by decorrelating trees. It is robust to hyperparameter choices, trains fast, and performs well on small-to-medium datasets.

Gradient boosting (XGBoost, LightGBM) builds trees sequentially, with each tree correcting the residual errors of the previous. It achieves higher accuracy on most structured tabular datasets — XGBoost and LightGBM dominate Kaggle tabular competitions for this reason — but it overfits more readily on small datasets and requires more careful tuning of learning rate, depth, and early stopping.

The direct answer when asked which to use: gradient boosting if you have enough data (>10K rows), time to tune, and accuracy is paramount; random forest if the dataset is small, you need a robust baseline fast, or you are doing feature importance analysis and want a stable result.

Feature engineering for tabular data

Interviewers at product companies care more about feature engineering than model architecture because most production DS work is tabular. The three things to know:

• Encoding categoricals: one-hot encoding for low-cardinality features, target encoding (mean of the label per category) for high-cardinality features, with out-of-fold estimation to prevent target leakage.
• Handling missing values: median imputation for continuous features; mode or an explicit "missing" category for categoricals; indicator flags ("was_missing") as additional features when missingness is informative.
• Interaction features: multiply or ratio two numeric features when domain knowledge suggests a relationship — e.g., revenue_per_session = total_revenue / sessions tells a tree model in one feature what would otherwise require many splits to discover.

The 3-Week Data Science Interview Prep Plan

Three weeks is enough time to close the preparation gaps that filter candidates, if the time is allocated to the right areas in the right order.

Week 1: Statistics and SQL

Statistics is the highest-leverage investment for most candidates because it is the area with the sharpest gap between preparation and interview weight. Cover CLT, hypothesis testing, confidence intervals, p-value definition (not the wrong one), Type I/II error tradeoffs, t-test vs z-test vs chi-squared, and Bayesian vs frequentist A/B testing. For SQL, drill window functions, CTEs, and the retention cohort pattern until you can write them without looking at references. The SQL interview questions for data engineering guide covers every window function pattern in depth.

Week 2: ML fundamentals and case study structure

Spend Week 2 on applied ML — not deep learning theory. Cover the linear/logistic regression coefficient interpretation, bias-variance tradeoff, decision tree failure modes, when to use gradient boosting vs random forest, and feature engineering patterns. Parallel to ML, build a product case study muscle: practice the four-step framework (clarify metric, identify causes, design investigation, propose framework) on five real case study prompts. Time yourself. The structure becomes fast with repetition.

Week 3: Mock interviews and company-specific prep

Week 3 is execution, not learning. Run timed mock SQL questions with no references. Practice stating your A/B testing reasoning aloud while writing. Do at least two full-length mock case study rounds. Research the company's data stack, north-star metrics (GMV for marketplaces, DAU/MAU for social, take rate for fintech), and recent product launches — interviewers reference their own product in the case study round, and familiarity pays off.

The gap between candidates who pass DS loops and those who don't is rarely ML knowledge — it is whether they walked in knowing how to structure a case study answer, write a retention cohort query from memory, and give the correct p-value definition without hesitation. The three-week plan closes those gaps systematically. The platform below gives you structured practice on all five areas with the question types that actually appear.