Data Scientist Interview Prep Path

Most DS candidates study in the wrong order: they jump to ML because it feels most relevant to the job title, then scramble through SQL and stats in the last week before their loop. That strategy fails at FAANG — not because ML isn't tested, but because SQL and statistics are tested more frequently and show up in every single round, while deep ML theory appears in only one or two.

The correct ordering is SQL → Stats → Analytics → ML → Scenarios, and each stage builds on the last:

• SQL first because it's the highest-leverage, fastest-to-improve skill. A candidate who does two focused weeks on SQL will outperform one who has spent six weeks on ML but can't write a window function. SQL also appears in take-home assessments, phone screens, and full loops — it has the highest return on prep time.
• Stats before ML because ML without statistics is memorizing formulas without understanding them. If you don't know why p-values are not the probability the null hypothesis is true, you cannot meaningfully answer A/B test result questions — and those appear in every DS loop at Facebook, Google, and Uber.
• Analytics before ML because DS interviews at most companies test product sense and metric interpretation at least as heavily as model building. Knowing how to diagnose a DAU drop or perform a funnel analysis is non-negotiable for DS roles, and these are consistently the most-failed sections among candidates with strong ML backgrounds.
• ML before Scenarios because scenario questions assume you can reason about models, features, and evaluation — you cannot fake that reasoning without the ML foundation.
• Scenarios last because they synthesize everything: a scenario question like "our 7-day retention dropped 4% after a product change — walk me through your investigation" requires SQL fluency, statistical intuition, product analytics reasoning, and light ML instinct all at once.

Total time budget: 8 weeks for a candidate prepping from a moderate baseline. Candidates with strong SQL or stats backgrounds can compress the relevant stages to 1 week each.

DS SQL interviews are not testing whether you know SELECT. They're testing whether you can translate a business question into a correct, readable, efficient query — under time pressure and while explaining your reasoning out loud.

The window function gap: In a typical DS SQL interview cohort, roughly 60% of candidates struggle with window functions. The patterns you must be fluent in:

• Running totals: SUM(revenue) OVER (PARTITION BY user_id ORDER BY date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
• Row comparison: Using LAG(metric, 1) to compute day-over-day change without a self-join
• Deduplication: ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_time DESC) with WHERE rn = 1 to get the most recent record per user
• Top-N per group: DENSE_RANK() OVER (PARTITION BY category ORDER BY revenue DESC) with WHERE dr <= 3

The NULL trap: After a LEFT JOIN, filtering in WHERE on the right-side table columns converts it to an INNER JOIN because NULL = value evaluates to NULL (not FALSE), which WHERE treats as false. Interviewers specifically test this. Move right-side filters to the ON clause.

The GROUP BY + window hybrid: The question "find users who spent more than the average for their country" requires a subquery or window function — you cannot reference a window function in a WHERE clause directly. Use a CTE:

WITH avg_by_country AS (
    SELECT user_id, country,
           spend,
           AVG(spend) OVER (PARTITION BY country) AS country_avg
    FROM users
)
SELECT user_id FROM avg_by_country WHERE spend > country_avg;

A/B testing — what FAANG interviewers actually ask:

1. Sample size calculation: Given a baseline conversion rate of 5%, a desired minimum detectable effect of 0.5% absolute (10% relative), 80% power, and α=0.05 (two-tailed), how many users per variant do you need? The formula: n = (z_α/2 + z_β)² × 2p(1-p) / Δ². For these values: z_α/2 = 1.96, z_β = 0.84, p = 0.05, Δ = 0.005. Result: ~24,400 users per variant. If you can't derive this, that's a gap to close before your loop.

2. The p-value misconception: p-value is the probability of observing this result (or more extreme) assuming the null is true. It is NOT the probability that the null hypothesis is true, and it is NOT the probability that your result is due to chance. Stating the correct definition clearly in an interview signals genuine statistical literacy.

3. Chi-squared vs t-test: Use chi-squared when both variables are categorical (e.g., click vs no-click × treatment vs control). Use t-test when comparing means of continuous outcomes. Most DS interviews use binary metrics (clicked, converted, churned), which means chi-squared or z-test for proportions, not t-test.

4. p-hacking / peeking: Checking results daily and stopping the experiment when p < 0.05 inflates the false positive rate far above 5%. Sequential testing methods (e.g., mSPRT) solve this. FAANG interviewers specifically probe whether candidates know this problem exists.