← Meta Interview Insights

Meta·Data Scientist·Technical Phone Screen·Senior

SeniorPrefer not to say
Jul 2026Remote

Summary

Meta data scientist interview, looked like a single deep technical question that sprawled into like five sub-problems at once. The whole thing revolved around multi-armed bandits with real-world messiness layered on top. Pretty brutal if you're not already living in experimentation land.

Questions Asked (4)

Q1

You have three product variants, a churn guardrail metric, and delayed conversion signals. Design a Thompson Sampling bandit from scratch: specify the likelihood model, explain how you handle conversion delays (optimistic vs. debiased estimators), and address non-stationarity through discounting or similar approaches.

A/B Testing & ExperimentationTechnical Trade-offsSystem Design
Author's notes

This is where I spent most of my mental energy and still feel like I only half-answered it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by framing the problem as a sequential decision-making task with delayed binary rewards and non-stationary arms. Propose a Thompson Sampling bandit with a Beta-Bernoulli model for conversions, then discuss how to handle delays via optimistic or debiased estimators, and finally address non-stationarity using discounting or sliding windows. Emphasize the churn guardrail by incorporating it as a constraint or penalty in the reward function.

Pro tip: Show awareness of the exploration-exploitation trade-off in the context of delayed feedback: naive optimistic estimates can over-explore, while debiasing may under-explore; suggest a hybrid approach with a decay factor on optimism as data accumulates.

1. Define the likelihood model and reward

Model each variant's conversion as a Bernoulli random variable with a Beta prior, and incorporate the churn guardrail by either constraining the posterior or adjusting the reward to penalize churn.

2. Handle delayed conversions

Discuss optimistic vs. debiased estimators: optimistic assumes pending conversions are successes, debiased uses inverse propensity weighting or survival analysis to correct for delay; recommend a hybrid that starts optimistic and transitions to debiased as data matures.

3. Address non-stationarity

Apply discounting to past observations (e.g., exponential decay) or use a sliding window to give more weight to recent data, ensuring the bandit adapts to changing user behavior.

4. Incorporate guardrail constraints

Treat churn as a guardrail by either setting a hard constraint on the posterior churn rate or adding a penalty term to the reward, and monitor it alongside conversion to avoid harmful variants.

5. Implement and evaluate

Describe the Thompson Sampling loop: sample from posterior, select variant, observe reward (with delay), update posterior with discounting. Suggest offline evaluation via replay or simulation to tune parameters.

Key Points to Mention

  • Beta-Bernoulli conjugate prior for Thompson Sampling
  • Optimistic vs. debiased estimators for delayed feedback (e.g., inverse propensity weighting, survival analysis)
  • Discounting (exponential decay) or sliding window for non-stationarity
  • Churn guardrail as a constraint or penalty in the reward function
  • Exploration-exploitation trade-off and how delays affect it
  • Offline evaluation and parameter tuning (e.g., decay rate, prior strength)

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

Q2

How would you set traffic floors and fairness constraints across the variants in this bandit setup?

A/B Testing & ExperimentationTechnical Trade-offs
Author's notes

I knew the concept but my answer was vague.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the business objective and risk tolerance, then propose a floor mechanism (e.g., epsilon-greedy or Bayesian prior) to ensure each variant gets minimum exposure. Next, define fairness constraints such as equal opportunity or proportional representation, and explain how to enforce them via constrained optimization or post-hoc adjustments. Finally, discuss monitoring and trade-offs between fairness and regret.

Pro tip: Emphasize that traffic floors and fairness constraints are not just technical but also business and ethical decisions—show you can balance statistical rigor with product needs. Mention that you would simulate or A/B test the bandit policy itself to validate fairness metrics before full deployment.

1. Clarify objectives and constraints

Ask about the goal: maximize overall reward, ensure fair exposure, or both? Identify any regulatory or business requirements for minimum traffic per variant.

2. Choose a floor mechanism

Select a method to guarantee minimum traffic, such as epsilon-greedy with a floor, Thompson sampling with a minimum probability, or a constrained bandit algorithm that enforces a lower bound on selection probabilities.

3. Define fairness constraints

Specify fairness metrics (e.g., equal opportunity, demographic parity, proportional representation) and translate them into mathematical constraints on the bandit's selection probabilities or reward estimates.

4. Implement constrained optimization

Use techniques like Lagrangian relaxation, constrained Thompson sampling, or post-hoc reweighting to satisfy fairness constraints while optimizing the primary objective.

5. Monitor and iterate

Set up dashboards to track traffic allocation and fairness metrics in real-time. Be prepared to adjust floors or constraints if they cause excessive regret or fail to meet business needs.

Key Points to Mention

  • Trade-off between exploration (fairness) and exploitation (reward maximization)
  • Use of epsilon-greedy or Thompson sampling with minimum probability floors
  • Fairness definitions: equal opportunity, demographic parity, proportional representation
  • Constrained optimization techniques (e.g., Lagrangian relaxation, constrained bandits)
  • Monitoring and alerting for fairness violations and regret
  • Simulation or offline evaluation to tune floor and constraint parameters

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

Q3

Define stopping rules and rollback policies for when a guardrail metric gets breached during the bandit experiment.

A/B Testing & ExperimentationProduct Analytics & Metrics
Author's notes

Easier than the others for me.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining guardrail metrics and their thresholds, then outline a tiered response system based on breach severity. Emphasize automation for immediate rollback and manual review for nuanced cases, and highlight the importance of pre-registration and monitoring.

Pro tip: Propose a 'circuit breaker' mechanism that automatically pauses the experiment and triggers a rollback if guardrail metrics breach a critical threshold, but also includes a manual override for data scientists to investigate before full rollback. This shows you balance safety with learning.

1. Define guardrail metrics and thresholds

Identify key guardrail metrics (e.g., revenue, user satisfaction, latency) and set acceptable thresholds based on historical data and business impact. Pre-register these thresholds before the experiment starts.

2. Establish monitoring and alerting

Set up real-time monitoring with automated alerts when guardrail metrics approach or breach thresholds. Use statistical methods like sequential testing to detect breaches early.

3. Define tiered stopping rules

Create a tiered response: for minor breaches, pause and investigate; for severe breaches, immediately stop the experiment and rollback. Specify who has authority to make these decisions.

4. Implement rollback policies

Outline the rollback process: revert to control, communicate to stakeholders, and analyze the breach. Ensure rollback is automated where possible to minimize harm.

5. Post-mortem and iteration

After a breach, conduct a post-mortem to understand causes and refine guardrail definitions and stopping rules for future experiments.

Key Points to Mention

  • Pre-registration of guardrail metrics and thresholds to avoid p-hacking
  • Automated monitoring and alerting systems for real-time detection
  • Tiered response based on breach severity (e.g., warning vs. critical)
  • Clear ownership and decision-making authority for stopping/rollback
  • Impact on experiment validity and learning when stopping early
  • Communication plan for stakeholders during and after a breach

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

Q4

Compare the expected regret and business impact of this bandit approach versus a fixed-horizon A/B test, specifically under seasonal conditions.

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

Regret comparison I could do in theory but the seasonality angle made it harder to be precise.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining the core trade-off: bandits adapt continuously to maximize cumulative reward, while fixed-horizon A/B tests provide clean causal inference but may be suboptimal under non-stationarity. Then, analyze how seasonality affects both approaches—bandits can exploit seasonal shifts but risk confounding, while A/B tests may suffer from delayed or biased estimates. Conclude with a business impact assessment, weighing short-term gains against long-term learning and decision-making needs.

Pro tip: Emphasize that the choice depends on the decision-making horizon and the cost of exploration—bandits are better for short-term optimization, but A/B tests are superior for strategic, long-term decisions. Also, mention that hybrid approaches (e.g., bandits with holdout groups) can balance both.

1. Define the objectives and constraints

Clarify whether the goal is to maximize cumulative reward (e.g., revenue) or to measure causal impact for a strategic decision. Consider the time horizon, cost of exploration, and the need for unbiased estimates.

2. Analyze regret under seasonality

Explain how bandit algorithms incur regret by exploring suboptimal arms, but can adapt to seasonal changes. Fixed A/B tests incur opportunity cost by sticking to a fixed allocation, potentially missing seasonal peaks.

3. Assess business impact and decision-making

Discuss how bandits can drive short-term revenue but may complicate long-term learning due to adaptive data collection. A/B tests provide clean estimates but may underperform during seasonal fluctuations if not timed correctly.

4. Consider hybrid or contextual approaches

Propose using contextual bandits that incorporate seasonal features, or running A/B tests with seasonal stratification. Mention the possibility of a holdout group to measure long-term effects.

5. Recommend based on scenario

Conclude with a recommendation: for fast-changing seasonal environments, bandits may be preferable; for strategic decisions requiring robust causal inference, A/B tests are better. Suggest evaluating both via simulation or pilot.

Key Points to Mention

  • Regret definition: difference between optimal and actual cumulative reward; bandits minimize regret by balancing exploration and exploitation.
  • Seasonality impact: non-stationary reward distributions; bandits can adapt, but may over-exploit early and miss long-term trends.
  • A/B test limitations: fixed allocation, no adaptation, potential for biased estimates if seasonality is not accounted for in analysis.
  • Business metrics: revenue, user engagement, long-term value; bandits optimize short-term metrics, A/B tests inform strategic decisions.
  • Statistical power and sample size: A/B tests require sufficient data for significance; bandits may need less data but introduce bias.
  • Hybrid approaches: contextual bandits, switchback tests, or A/B tests with sequential monitoring to handle seasonality.

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