Data Science Interview Questions: SQL, Statistics, ML, and Cases

A Data Scientist interview can emphasize product analytics, decision science, experimentation, predictive modeling, or a combination. The title alone does not define the assessment. Read the current job description and recruiter guidance, then weight preparation toward the decisions the role will make.

This guide organizes preparation by capability rather than a fixed sequence of rounds. It covers metric-first SQL, statistical reasoning, experiment diagnosis, modeling judgment, product cases, and evidence from past work. The goal is not to memorize answers. It is to make every population, assumption, tradeoff, and verification step visible.

Map the role to a capability mix

Translate the job description into work products. A role that owns experiments needs different depth from one that builds production models, even when both are labeled Data Scientist.

Ask which capabilities and tools are in scope. A useful question is: "Should I expect live SQL or Python, a statistics discussion, a business case, or a modeling design conversation?" Do not ask for exact prompts or assume a process based on another candidate's role.

Build one project or work example for every major responsibility. The Python resume project guide can help turn coursework or personal analysis into verifiable evidence without inflating its scope.

Define the metric before writing SQL

SQL correctness begins with the decision and output grain. "Most used" can mean time, sessions, or unique users. Those definitions can produce different winners. In this walkthrough, the explicit metric is total session duration during the seven calendar days ending on 2026-03-08, inclusive. The output is one row per app.

Input: apps

Input: user_activity

The sixth activity is outside the seven-day window and must not affect the result.

SELECT
    a.app_id,
    a.app_name,
    SUM(ua.duration_seconds) AS total_seconds,
    COUNT(DISTINCT ua.session_id) AS sessions,
    COUNT(DISTINCT ua.user_id) AS users
FROM user_activity AS ua
JOIN apps AS a
  ON a.app_id = ua.app_id
WHERE ua.activity_date >= DATE '2026-03-08' - 6
  AND ua.activity_date <  DATE '2026-03-08' + 1
GROUP BY a.app_id, a.app_name
ORDER BY total_seconds DESC, a.app_id;

Exact output

Focus wins on total duration. Planner wins on session count, and both apps tie on unique users. That difference is why the metric definition must come before the query.

The lower bound subtracts six because the ending day is included: March 2 through March 8 contains seven dates. The upper bound is exclusive, which makes the pattern safe if activity_date later becomes a timestamp. COUNT(DISTINCT session_id) protects the session count if a session can span multiple activity rows, but that choice should still be confirmed from the schema.

Use the SQL for data analysis guide to practice grain, joins, cohorts, and windows. For every query, verify row counts after joins, denominator populations, null policy, time boundaries, tie-breaking, and zero-activity cases.

Be precise about statistics and experiments

Statistical questions test whether a definition supports the decision you attach to it.

For an experiment, define the decision, eligible population, randomization unit, exposure, primary outcome, guardrails, analysis window, and stopping rule before reading the result. Check sample-ratio mismatch and assignment integrity before estimating an effect. Analyze at the randomization unit or use a method that accounts for dependence.

For a metric drop, verify before explaining:

1. confirm the definition, identity logic, and denominator;
2. check pipeline completeness and event volume;
3. locate the time of the change;
4. segment by platform, version, geography, cohort, and source;
5. identify the funnel stage that moved;
6. rank hypotheses and propose a discriminating check.

A holiday, launch, or external event is not an explanation until its expected contribution is sized against the observed movement. A global drop cannot be assigned to one region's calendar without checking that region's share and historical effect.

The A/B testing interview framework provides a complete design and diagnosis sequence, including interference and guardrails.

Connect modeling and cases to a decision

Modeling answers should begin with the prediction time, label, decision, and cost of errors. Only then choose features, algorithms, and metrics.

For a fraud decision, labels may arrive long after a transaction. A recent holdout can therefore be incompletely labeled. State whether you will wait for maturity or use a proxy with known bias. Under severe imbalance, ROC-AUC can hide the operating burden; precision-recall behavior, recall at a fixed review budget, calibration, and expected cost may be more relevant.

Prevent leakage structurally:

• define the eligible population before feature joins;
• close every feature window before the prediction timestamp;
• derive labels strictly after that timestamp;
• split by time when deployment predicts the future;
• fit preprocessing on the training partition only;
• compare with a simple measured baseline;
• verify training and serving use the same feature definitions.

Regularization and model complexity are tools, not substitutes for a correct dataset. The Lasso versus Ridge guide explains scaling, correlation, and feature-selection caveats.

For a product or business case, use a decision sequence:

Do not reach for a classifier before defining the label. A fuzzy segment such as "frequent traveler" needs an operational rule, measurement-quality review, and product use. A security intervention and an ad-targeting segment tolerate different false-positive costs.

The data science case study guide expands this structure. Behavioral answers should use the same decision focus: what you owned, what evidence changed the plan, which tradeoff you made, and what result or uncertainty followed. End at a decision, not at a dashboard or model artifact.

FAQ

What Data Science interview questions should I practice first?

Start with the capabilities named in the current role: SQL and metrics, statistics and experiments, modeling and validation, business cases, or deployment. Practice one end-to-end problem in each relevant area rather than memorizing a large company-tagged list.

How advanced should my SQL be?

Be able to define output grain, join without fanout, preserve the intended population, aggregate with correct denominators, use windows when needed, handle nulls and time boundaries, and validate exact output on a small fixture.

Do all Data Scientist interviews include machine learning?

No. Product and analytics roles may emphasize SQL, metrics, experiments, and cases. Modeling-focused roles may require deeper ML and deployment reasoning. Confirm the current role rather than assuming from the title.

How should I prepare statistics definitions?

Explain each definition aloud, attach it to a decision, and name its assumptions. Then work a small numeric example and a failure case. Precise interpretation matters more than reciting a formula.

How long should preparation take?

Use readiness checkpoints rather than a universal number of weeks. You are ready when you can solve a grain-sensitive SQL fixture, explain core statistical concepts precisely, design or diagnose an experiment, defend a validation plan, structure a case recommendation, and support behavioral claims with evidence.