Data Scientist Interview FAQs — Most Asked in 2026

This tests window functions + partitioning. The interviewer wants to see if you know ROW_NUMBER() or RANK().

WITH ranked AS (
  SELECT
    category,
    product_id,
    SUM(revenue) AS total_revenue,
    ROW_NUMBER() OVER (
      PARTITION BY category
      ORDER BY SUM(revenue) DESC
    ) AS rn
  FROM orders
  GROUP BY category, product_id
)
SELECT * FROM ranked WHERE rn <= 3;

Why the interviewer asks: to test window functions + CTEs — a fundamental skill for real analysis work.

INNER JOIN returns only matching rows from both tables. LEFT JOIN returns all rows from the left table plus matches from the right (NULLs where no match). FULL OUTER JOIN returns all rows from both — NULLs where there's no match on either side.

Why the interviewer asks: to test your understanding of joins. Many candidates memorise the definitions but can't explain when to use each. Be ready to give examples.

Use GROUP BY + HAVING COUNT(*) > 1:

SELECT email, COUNT(*) AS count
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

Why the interviewer asks: to test aggregation and data-cleaning intuition. Real data is messy — you'll deal with duplicates constantly.

A p-value is the probability of observing data at least as extreme as what you saw, assuming the null hypothesis is true. A low p-value (typically < 0.05) means "this result would be unlikely if there were no real effect" — suggesting the effect is real.

Common mistake: Saying "p-value is the probability the null is true". It's not — it's the probability of the data given the null. Interviewers will catch the error.

Structure the answer as a checklist:

• Hypothesis — what do you expect to change?
• Success metric — one primary metric + guardrail metrics.
• Sample size — calculate using power analysis (typically 80% power, 0.05 alpha).
• Randomisation — split users randomly into test and control.
• Duration — run for at least one full business cycle (usually 2 weeks).
• Analysis — compare metric between groups with statistical significance.
• Decision — ship if significant and no guardrail regressions.

Why the interviewer asks: to test whether you understand experimentation — a core skill for any product data scientist.

Bias is error from overly simple models (underfitting) — they miss real patterns. Variance is error from overly complex models (overfitting) — they fit noise. The tradeoff: as you make a model more complex, bias decreases and variance increases.

How to manage: cross-validation, regularisation, ensembling, more data, or simpler models. The right balance depends on the problem.

List solutions in order of priority:

1. Get more data — the best fix if possible.
2. Reduce model complexity — fewer features, shallower trees, smaller networks.
3. Regularisation — L1/L2 for linear models, dropout for neural networks, early stopping.
4. Cross-validation — use k-fold to get a reliable estimate of generalisation.
5. Data augmentation — especially for vision/text tasks.
6. Ensembling — bagging (e.g. Random Forest) reduces variance.

Don't use accuracy. A 99% accuracy model that predicts "not fraud" for every sample is useless. Use instead:

• Precision / recall / F1 — depending on whether false positives or false negatives are worse.
• ROC-AUC — overall discriminative ability.
• Precision-Recall AUC — better than ROC-AUC when classes are heavily imbalanced.
• Cost-sensitive metrics — if the business costs of errors differ.

A Random Forest is an ensemble of decision trees. Each tree is trained on a bootstrap sample (random sample with replacement) of the data, and at each split, only a random subset of features is considered. The final prediction is the majority vote (classification) or average (regression) of all trees.

Why it works: averaging many decorrelated trees reduces variance (overfitting) without increasing bias much. It's a very strong baseline for tabular data.

Tree models (Random Forest, XGBoost, LightGBM) — for tabular data, non-linear relationships, missing values, feature interactions. Usually the best baseline.

Linear models — for interpretability, small datasets, or when the relationship is known to be linear. Easier to explain to stakeholders.

Deep learning — for images, text, audio, or very large datasets where patterns are hard to hand-craft.

Use STAR structure: Situation → Task → Action → Result. Focus on impact, not just what you did. Include numbers: "Improved prediction accuracy by 15%", "Reduced costs by ₹2 lakh per month", "Shipped in 6 weeks".

Common mistake: Describing the technical stack in detail while ignoring the business impact. Interviewers want to know what changed because of your work.

They're testing your ability to push back constructively without being difficult. Good answers show:

• You listened to their perspective.
• You used data to make your case.
• You compromised when appropriate.
• You maintained the relationship.

Bad answer: "I was right and they were wrong." That's a red flag — it suggests you can't collaborate.

Pick a real failure — not a humblebrag ("I worked too hard"). Structure it honestly:

• What you were trying to do.
• What went wrong.
• What you learned.
• How you've changed since.

Pro tip: Choose a failure that's meaningful but not career-ending. "I underestimated how long data cleaning would take and missed a deadline" is a good one. "I shipped a model that caused a production outage" is too risky.

Typically 3–4 rounds: (1) screening call, (2) technical round (SQL + stats + ML), (3) case study, (4) behavioural/hiring manager round. Some companies merge rounds or add one more — but this is the standard pattern.

No — most data science roles don't require deep learning. Classical ML (regression, tree-based models) + SQL + statistics + good business judgment are what most roles actually test. Deep learning matters for specialised roles (vision, NLP, LLMs), but you don't need it for entry-level data scientist jobs.

Enough to solve problems on your own. Specifically: JOINs (all types), GROUP BY + aggregations, subqueries, CTEs, window functions (ROW_NUMBER, RANK, LAG/LEAD), and basic query optimisation. Practice on real datasets — not just textbook examples.

Keep it to 60–90 seconds. Structure: current role → relevant experience → why this role → what you bring. Focus on relevance to the job, not a full biography. The interviewer has your resume — they want the story, not the data.

Be honest. Say "I don't know that specific answer, but here's how I'd think about it..." Then walk through your reasoning. Interviewers respect honesty and structured thinking far more than bluffed answers they can easily catch. Never pretend to know something you don't.