← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Senior

Senior
Jul 2026

Summary

Went through a technical screen for a DS role at Meta, heavy on ML systems and modeling fundamentals. The whole thing was basically one long case study about inheriting a broken churn model, which sounds contained until you realize how many sub-problems they're actually testing at once.

Questions Asked (5)

Q1

You inherit a churn prediction model where some features leak information from within the prediction window. Identify at least five concrete leakage sources in a logs-based feature set and rewrite each so it's computable at prediction time using a strict event-time cutoff.

Product Analytics & MetricsTechnical Trade-offsRoot Cause Analysis
Author's notes

This is where I spent most of my mental energy.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the prediction time and the strict event-time cutoff, then systematically audit each feature for any information that would not be available at that moment. For each leakage source, explain why it leaks and propose a rewritten feature that uses only data up to the cutoff, ensuring it's computable in production.

Pro tip: Emphasize that leakage often arises from using future aggregates or labels; always validate by simulating a point-in-time join and checking feature availability. Mention that even subtle leaks like using the churn event itself or post-churn activity can inflate offline metrics but fail in production.

1. Define prediction time and cutoff

Clarify the exact moment predictions are made (e.g., daily at midnight) and enforce a strict event-time cutoff so only events before that time are used.

2. Audit features for temporal leakage

Review each feature to identify if it incorporates data from after the cutoff, such as future aggregates, labels, or post-event behavior.

3. Rewrite features with point-in-time correctness

For each leaking feature, redesign it to use only historical data up to the cutoff, ensuring it can be computed in real-time or with a point-in-time join.

4. Validate with backtesting

Simulate predictions at historical cutoffs and verify that rewritten features are available and produce realistic performance, avoiding overly optimistic metrics.

Key Points to Mention

  • Target leakage: using the churn label or post-churn events as features.
  • Future window aggregates: computing statistics over a window that includes the prediction period.
  • Temporal joins without cutoff: joining logs that include events after the prediction time.
  • Post-event features: features derived from user actions that occur after the cutoff, such as 'days since last login' computed after churn.
  • Global statistics computed on full data: using mean/median from the entire dataset including future data.
  • Feature availability: ensuring rewritten features can be computed in production with the same logic.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Propose a rolling-origin cross-validation scheme for this model. Define train, validation, and test splits with no future leakage, and explain how you'd handle users entering or leaving the cohort and cold-start users.

Data ModelingTechnical Trade-offs
Author's notes

I knew the rolling origin setup well enough but fumbled the cold-start piece.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining a time-based rolling-origin scheme with expanding or sliding training windows, ensuring that validation and test sets always come after the training data in time. Then address cohort dynamics by incorporating user activity windows and cold-start handling, such as using content-based features or meta-learning for new users. Finally, discuss trade-offs like window size, retraining frequency, and evaluation metrics that account for user churn.

Pro tip: Emphasize that the validation set should mimic the test set's temporal distance from training to avoid overfitting to a specific horizon, and consider using multiple rolling origins to get a distribution of performance metrics.

1. Define the rolling-origin structure

Choose a time-based split with multiple folds, where each fold's training set precedes its validation set, which precedes its test set. Use expanding or sliding windows and ensure no future data leaks into training.

2. Handle user cohort dynamics

For users entering or leaving, define active user cohorts per fold based on activity in the training window. For evaluation, only score users who are active in the validation/test period, and consider weighting or filtering to handle churn.

3. Address cold-start users

For new users with no historical interactions, use side information (demographics, content features) or a separate cold-start model. In cross-validation, simulate cold-start by holding out initial interactions of new users or using meta-learning.

4. Evaluate and iterate

Compute metrics on each fold's validation and test sets, aggregate results, and tune hyperparameters. Monitor for temporal drift and adjust window sizes or retraining frequency accordingly.

Key Points to Mention

  • Time-based splits with no shuffling to prevent future leakage
  • Expanding vs. sliding window trade-offs (more data vs. adaptivity to drift)
  • User activity windows to define cohorts and handle churn
  • Cold-start strategies: content-based features, meta-learning, or separate models
  • Evaluation metrics that account for user-level aggregation and temporal dynamics
  • Multiple rolling origins to assess stability and variance of performance

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Offline AUC is 0.79 and PR-AUC is 0.23. Online, targeting the top decile lifts conversion 1.5% but also raises cancellations by 0.3 percentage points. How do you define business KPIs and a cost-sensitive objective to tune the decision threshold? Include calibration and how you'd monitor calibration drift in production.

A/B Testing & ExperimentationProduct Analytics & MetricsTechnical Trade-offs
Author's notes

The cancellation increase was the interesting wrinkle and I almost glossed over it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by translating the offline metrics and online experiment results into a business-oriented cost-benefit framework, then define KPIs that capture both conversion lift and cancellation cost. Propose a cost-sensitive objective that weights false positives and false negatives according to their business impact, and tune the threshold to maximize expected profit. Finally, discuss calibration methods and a monitoring plan for calibration drift in production.

Pro tip: Emphasize that the optimal threshold depends on the business cost ratio and the base rate, and that calibration is crucial because ranking metrics like AUC don't guarantee well-calibrated probabilities. Show you can connect offline model performance to online business outcomes.

1. Define Business KPIs

Identify primary and guardrail metrics: e.g., conversion rate lift, cancellation rate, net revenue per user, and customer lifetime value impact. Quantify the monetary cost of a cancellation versus the benefit of a conversion.

2. Construct Cost-Sensitive Objective

Formulate an expected profit function: profit = (true positives * benefit) - (false positives * cost) - (false negatives * missed opportunity). Use the online experiment to estimate these parameters.

3. Tune Decision Threshold

Optimize the threshold on a validation set to maximize expected profit, considering the calibrated probabilities. Validate via online A/B test or switchback experiment to ensure business impact.

4. Calibrate Probabilities

Apply calibration methods (Platt scaling, isotonic regression) to align predicted probabilities with observed frequencies. Evaluate calibration with reliability diagrams and metrics like Brier score or ECE.

5. Monitor Calibration Drift

Set up production monitoring for calibration drift using statistical tests (e.g., KS test, PSI) on predicted vs. actual outcomes, and track business KPIs. Retrain or recalibrate when drift exceeds thresholds.

Key Points to Mention

  • Cost-benefit analysis: quantify the monetary value of a conversion and the cost of a cancellation to set the threshold.
  • Calibration importance: AUC and PR-AUC measure ranking, not calibration; well-calibrated probabilities are needed for threshold optimization.
  • Threshold optimization: use expected profit maximization, not just accuracy, and consider the base rate and cost ratio.
  • Online validation: A/B test the threshold change to measure incremental impact on business KPIs.
  • Calibration drift monitoring: track ECE, reliability diagrams, and statistical tests on prediction distributions over time.
  • Guardrail metrics: ensure cancellations don't exceed acceptable limits, and consider long-term effects like customer churn.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

A standardized feature has a logistic regression coefficient of 0.40 and the model's baseline log-odds of churn is negative 1.50. Compute the odds ratio for a one standard deviation increase and the resulting change in churn probability from baseline. Then explain the limitations of interpreting coefficients this way when features are correlated.

Product Analytics & MetricsTechnical Trade-offs
Author's notes

The math itself is fine: exp(0.40) is about 1.49, baseline probability works out to roughly 18%, after the shift you're around 24%.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First compute the odds ratio as exp(0.40) ≈ 1.49, then convert the baseline log-odds to a baseline probability using the logistic function. For the new probability, add 0.40 to the baseline log-odds and apply the logistic function again, then take the difference. Finally, discuss how multicollinearity and correlated features can distort individual coefficient interpretations, especially in product analytics where features like user engagement metrics are often highly correlated.

Pro tip: Emphasize that while the odds ratio is straightforward, the change in probability depends on the baseline risk—a common pitfall in interpreting logistic regression. Also, mention that in practice, you'd validate with techniques like VIF or regularization, and consider model-agnostic methods like SHAP for correlated features.

1. Compute the odds ratio

Calculate exp(0.40) ≈ 1.49, meaning a one standard deviation increase in the feature multiplies the odds of churn by about 1.49.

2. Convert baseline log-odds to probability

Use the logistic function: p = 1 / (1 + exp(-(-1.50))) ≈ 0.182, so baseline churn probability is about 18.2%.

3. Compute new probability and change

Add 0.40 to baseline log-odds: new log-odds = -1.10. New probability = 1 / (1 + exp(1.10)) ≈ 0.250. Change = 0.250 - 0.182 = 0.068, or 6.8 percentage points.

4. Explain limitations with correlated features

When features are correlated, coefficient estimates become unstable and their interpretation as independent effects is misleading; the odds ratio may not reflect the true effect of changing one feature while others remain constant.

Key Points to Mention

  • Odds ratio calculation: exp(coefficient) = exp(0.40) ≈ 1.49.
  • Baseline probability from log-odds: p = 1/(1+exp(-log_odds)).
  • Change in probability depends on baseline risk; non-linear relationship.
  • Multicollinearity inflates standard errors and can flip signs of coefficients.
  • Correlated features violate the 'all else equal' assumption in coefficient interpretation.
  • Alternatives: regularization (L1/L2), feature selection, or model-agnostic methods (e.g., SHAP) for correlated features.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q5

Outline a production monitoring plan covering data quality, feature distribution shifts, PSI, label delay, and prediction drift. Include a retraining policy tied to both performance degradation and covariate shift triggers.

System DesignRoot Cause AnalysisTechnical Trade-offs
Author's notes

Ended on this one and was running low on time.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by framing the monitoring plan around the ML lifecycle, covering data quality, feature drift, label delay, and prediction drift with specific metrics and thresholds. Then describe a retraining policy that triggers on both performance degradation and covariate shift, emphasizing automation and trade-offs. Use a structured, layered approach to show depth and practicality.

Pro tip: Tie every monitoring metric to a concrete action (e.g., alert, retrain, rollback) and quantify thresholds based on business impact—this shows you think like an owner, not just a modeler.

1. Data Quality Monitoring

Define checks for missing values, schema violations, range violations, and distribution anomalies on input data. Set up automated alerts for deviations from expected patterns.

2. Feature Distribution & PSI

Monitor feature distributions over time using PSI (Population Stability Index) and other drift metrics. Establish thresholds (e.g., PSI > 0.2 indicates significant shift) and track per-feature and overall drift.

3. Label Delay & Prediction Drift

Account for delayed labels by monitoring proxy metrics (e.g., prediction distribution, confidence scores) and when labels arrive, compute performance metrics. Track prediction drift via distribution comparisons and statistical tests.

4. Retraining Policy

Define triggers: performance degradation (e.g., accuracy drop >5%) and covariate shift (e.g., PSI > 0.2 on key features). Specify retraining frequency, data windows, and validation before deployment.

5. Automation & Governance

Automate monitoring, alerting, and retraining pipelines. Include human-in-the-loop for critical decisions, and document thresholds and actions for auditability.

Key Points to Mention

  • PSI thresholds and interpretation (e.g., <0.1 stable, 0.1-0.2 moderate shift, >0.2 significant shift)
  • Handling label delay: use proxy metrics, delayed feedback loops, and when to trigger retraining without labels
  • Prediction drift detection: compare prediction distributions, use statistical tests (e.g., KS test), and monitor calibration
  • Retraining triggers: combine performance degradation (e.g., AUC drop) and covariate shift (e.g., PSI) with logical OR/AND conditions
  • Retraining strategy: sliding window vs. cumulative data, frequency, and validation to prevent regressions
  • Trade-offs: false alarms vs. missed drift, retraining cost vs. performance gain, and automation vs. manual oversight

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.