This is a behavioral round, so there is no single right answer — the interviewer is scoring the structure, judgment, and quantification of your stories. Below is the method plus a worked STAR example for each prompt, tailored to a Meta Data Scientist. Use them as templates and substitute your own real numbers, which you must be able to defend. ## How to answer (STAR + quantify) - Structure every story as **Situation** (context, stakes, baseline) → **Task** (your specific goal) → **Action** (your decisions and trade-offs) → **Result** (quantified impact, plus a counterfactual where possible). - Quantify with a clear formula: percent change = (new − old) / old; rough revenue impact ≈ Δmetric × baseline volume × ARPU. Always state your assumptions. - Name the stakeholders, the guardrails, and how you validated the outcome. End each story with a durable improvement (runbook, template, process change) to show compounding impact. - If numbers are sensitive, use defensible ranges or proxy metrics (e.g., “−2.1pp churn,” “+3.4% conversion”) and be ready to explain your estimation method. ## 1) Self-introduction Data scientist with ~6 years across product analytics, experimentation, and ML, most recently leading analytics for a consumer surface with tens of millions of MAU. I own the loop from event schema and metric definitions through A/B design/analysis to shipped models, partnering closely with PM, Eng, and Design. Recent highlights: launched a notifications-ranking model (+6.3% CTR), tripled experiment velocity (2 → 6 tests/month), and improved 7-day activation by 12%. ## 2) Working with very different people (engineers, designers, sales) - Situation: Inbound lead quality lagged — sales said leads weren’t sales-ready, marketing prioritized volume, and engineering had limited bandwidth. - Task: Build a lead-scoring system and align everyone on a shared definition of a “qualified lead” without hurting top-of-funnel volume. - Action: Wrote a 2-page problem definition with a metric contract (precision/recall targets + SLA). Translated the model into call-list quality / win-rate impact for sales (confusion-matrix ROI), modeled a volume-vs-quality trade-off curve for marketing, and gave engineering a crisp spec (features, latency, fallbacks). When the score threshold became contentious, I ran a threshold sweep so each side could see conversion vs. SDR utilization; we agreed on a 0.62 threshold and a 4-week pilot. - Result: Sales-accepted lead rate +18%, SDR time-to-first-contact −30%, cost per qualified lead −12%, missed follow-ups −25%. The approach became our default for routing changes. ## 3) Give and receive constructive feedback Giving feedback: - Situation: A peer analyst’s weekly KPI dashboard had a ~15% error rate and missed its Monday-10am SLA 40% of the time, causing churn in product reviews. - Task: Raise data quality without damaging the relationship. - Action: Asked permission to share feedback, used SBI (Situation–Behavior–Impact), led with appreciation and specifics, and invited their view. Co-created a lightweight QA checklist (freshness checks, join unit tests), paired on the next 3 releases, and added dbt null/uniqueness tests in CI. - Result: Error rate 15% → 1.8% (−88%) in 6 weeks; SLA adherence 60% → 98%; the analyst later rolled the checklist out to 4 other dashboards. Receiving feedback: - Situation: My manager told me my readouts were too deep in methods, losing non-technical stakeholders and delaying decisions. - Task: Improve executive communication while keeping technical rigor. - Action: Adopted an “executive-summary-first” / pyramid format — one TL;DR slide (decision, impact, risk) with methods in an appendix — dry-ran with a peer PM, and added a consistent “What we need from you” section. - Result: Stakeholder CSAT on clarity 3.2 → 4.5/5; share of meetings reaching a clear decision in-room 55% → 86%; proposals adopted ~25% more often on first pass. ## 4) Disagree and commit (with de-risking and counterfactual) - Situation: A PM proposed a global launch of a new ranking feature with no A/B test to hit a seasonal deadline. - Task: Advocate for evidence without blocking the timeline; protect user and revenue guardrails. - Action: Proposed a compromise ramp (0% → 20% → 50% → 100% over 10 days) with a 10% holdout and pre-registered guardrails (session length, conversion, creator retention) with MDEs and p-thresholds; built a synthetic-control counterfactual from 12 weeks of pre-period and matched markets; added a kill switch and daily Eng/PM/DS triage. When Day-2 data showed −4.2% session length in high-churn cohorts at 20%, I recommended a pause; the PM agreed, we iterated on decay factors, then resumed. - Result: Final launch after 2 iterations: +1.6% conversion, +0.9% session length, ~+$1.2M/quarter vs. the counterfactual, while avoiding an estimated −$2.4M/quarter loss had v1 shipped globally — all within the original deadline. ## 5) A conflict where you were initially wrong - Situation: I argued with an engineer to enable CUPED on a new metric to cut experiment runtime, insisting it was safe because covariance looked high over one week, under pre-launch pressure. - Task: Reduce runtime without biasing the metric. - Action: A peer flagged that the covariate had drifted due to a marketing spike; an A/A test showed inflated Type-I error plus an SRM alert, and I realized my stationarity assumption was wrong. I paused the rollout, owned the mistake publicly in the experiment channel, and switched to a 28-day rolling covariate with seasonality adjustment plus a pre-check that blocks CUPED when covariate drift exceeds 10% week-over-week. I documented failure modes in a pre-mortem and required an RFC for any change to inference settings. - Result: False-positive rate returned to 5% on A/A; runtime still improved ~18% with the safer settings; the engineer co-authored the follow-up RFC. Observable behavior change: I now pre-register hypotheses and run SRM + covariate-stability checks before sharing any result, and include an “Assumptions & Validations” slide in every readout. ## 6) Biggest obstacle and winning over skeptics - Situation: Three teams used different definitions of “Weekly Active User,” so experiment readouts conflicted and decisions churned; separately, an ads-ROI model broke after an identity-graph change (12% duplicate conversions, 8% timestamp skew, MAPE 28%). - Task: Establish one governed metric definition (and, in the ads case, restore trustworthy data) and bring skeptical PMs/Marketing along. - Action: Authored an RFC comparing WAU definitions with 12-month backfills, quantifying up to 3.2pp swings in measured lift; proposed a versioned semantic/metrics layer (dbt + tests + owners) with an 8-week dual-report migration; ran a 2-product pilot to de-risk; secured an exec sponsor by showing ~40 hours of prior leadership time lost to definition debates. For the ads data, I led a cross-team audit, added dbt anomaly tests and idempotent 90-day backfills, built an ad-events↔billing↔CRM reconciliation dashboard, and retrained with outlier clipping. - Result: 7 teams (85% of DAU surface) migrated in 10 weeks; dispute meetings 10 → 3/quarter; dashboard variance ±6% → ±0.8%. Ads MAPE 28% → 9% (−68%), time-to-insight 36h → 10h, and optimization drove +3.8% ROAS. ## 7) A breakthrough you drove - Situation: Experiment readouts took ~7 days, used inconsistent event logs, and often conflicted, so leadership lost confidence in results. - Task: Cut analysis latency and restore trust in experimentation. - Action: Standardized the event taxonomy with auto-QA for logging coverage, built a reusable analysis template with guardrails (SRM checks, power/MDE calculator, CUPED variance reduction), pre-registered success criteria, and shipped a self-serve dashboard for primary/guardrail metrics. - Result: Time-to-readout ~7 days → <24h; throughput 2 → 10 tests/month (5×); enabled a new onboarding path that lifted 7-day retention +3.1% with no guardrail regressions; stakeholder trust survey 3.2 → 4.6/5. ## 8) Ambiguous analytics/infra work under time pressure - Situation: Six weeks to a major launch, but the experiment-analysis pipeline produced results in 48–72h — too slow to decide daily — with data split across two logging schemas and no owner for guardrail metrics. Resourcing: 1 DS (me) + 1 shared SWE, fixed compute. - Task: Get time-to-decision under 24h while keeping statistical rigor and adding guardrails. - Action: Scoped MVP vs. v2 (MVP = canonical metrics + SRM/crash guardrails + CUPED; deferred heterogeneity analysis). Authored a 7-page design doc, defined a RACI and a decision log, chose sequential testing with O’Brien–Fleming alpha-spending over fixed-horizon (accepting slight power loss for earlier looks), implemented CUPED on a 7-day baseline, added χ² SRM auto-checks that hard-fail dashboards, and migrated heavy joins to partitioned parquet. Ran a pre-mortem (schema drift, SRM blind spots, compute quota) with explicit mitigations. - Result: p50 analysis latency 36h → 9h (−75%); p95 84h → 18h (−79%); time-to-significance median 10 → 7 days (−30%) via CUPED + sequential looks; compute −18%; guardrail coverage 0 → 6 metrics; 4 early SRM catches prevented 2 false launches. Artifact I authored: a design-doc outline (objective & SLOs → architecture: event stream → ETL → metrics service → report generator → statistical design → data contracts → guardrails/alerts → rollout → risks/decision log). What I’d do differently: involve SRE earlier for explicit error budgets and add chaos testing for schema drift. ## 9) Breaking metric regression (triage within hours) - Situation: During a staged rollout of a new ranking feature, the real-time dashboard alerted a −4.8% drop in daily messages sent within 90 minutes of ramping 10% → 50% (baseline ~20M messages/day). - Task: As on-call DS, find root cause and stop the bleeding fast while preserving evidence for diagnosis. - Action: Sliced by country/client/device and isolated the regression to Android low-end devices in certain locales; guardrails showed Android p95 latency +120ms correlated with the drop. Key trade-off: instead of a full rollback (which would destroy the clean A/B contrast), I did a partial rollback — Android to 0%, iOS held at 50% — cutting impact ~70% while keeping a live contrast for debugging. Added a latency kill-switch (p95 > 500ms auto-disable) and extra telemetry, partnered with Eng on a client-cache hotfix, and re-ramped Android behind a 10% canary with a 30-minute soak. - Result: Time-to-mitigation ~2h; messages restored to within −0.3% of baseline by EOD; avoided an estimated $80k–$120k revenue loss that day; the postmortem produced an anomaly-detection threshold (Z-score + seasonality) and a triage runbook that cut median MTTR 3.1h → 2.0h over the next 6 incidents. ## 10) Skill learned by observing a peer (velocity/quality) - Situation: A core experiment pipeline took ~95 minutes and often failed near the 80–90-minute mark against BigQuery slot limits. - Task: Improve reliability and latency without throwing more compute at it. - Action: I watched a senior DS use EXPLAIN plans and window functions to cut data scans, paired on one job, and turned it into a repeatable tuning checklist (prune columns early, push filters down, replace DISTINCT with QUALIFY + ROW_NUMBER(), pre-aggregate in staging). I refactored a 900-line SQL into modular CTEs, added partitioning/clustering, and dbt row-count/null tests — then documented the pattern so it compounded. - Result: Runtime 95 → 38 min (−60%); weekly failure rate 12% → 2%; decision cadence 2× → 4×/week; ~8 analyst-hours/week saved. I credited the peer explicitly and generalized the skill into team templates. ## 11) Diversity and inclusion - Situation: Our content-ranking model under-served creators in smaller-language communities — their content appeared ~40% less often in top slots, with higher complaint rates (scope: large multilingual DAU base). - Task: Improve exposure parity without degrading overall engagement, and institutionalize a guardrail so it can’t regress. - Action: Instrumented subgroup AUC and exposure share by language plus an equal-opportunity gap metric, with a parity-ratio goal ≥ 0.85 (min-subgroup exposure / max-subgroup exposure). Ran a weekly fairness review with a rotating panel (DS/SWE/PM/Policy) using a structured rubric and anonymized language labels in model comparisons. Collected more multilingual training data, added language-aware features and a small exposure floor via constrained optimization, and added a fairness gate to the launch checklist that blocks promotion when parity < 0.80 without a VP waiver. - Result: Exposure parity 0.62 → 0.86; underrepresented-language creator retention +6.2pp; report rate −18%; overall engagement neutral (+0.3%). Guarded against tokenism with objective thresholds, anonymized evals, and rotating reviewers — success tied to metrics, not to showcasing specific creators. Permanent change: the fairness gate and dashboard are now part of every ranking model’s CI. ## 12) Inclusive meetings for quieter teammates - Situation: Data design reviews were dominated by two senior voices; junior and remote teammates rarely contributed. - Task: Make the process inclusive to surface more risk and improve solution quality. - Action: Sent a 24-hour pre-read with 3 explicit questions and a doc for async comments; opened each review with a 10-minute silent read/comment period, then round-robin by name (opt-out allowed); collected anonymous questions via a form; time-boxed segments and facilitated to balance airtime. - Result: Speaking participation ~35% → 82% of attendees; pre-meeting doc comments 3–5 → 18; two critical risks (PII leakage in a join; sampling bias) were raised by quieter members, preventing a privacy incident and ~3 weeks of rework. The format became our default review (+4.6/5 feedback). ## 13) Proactive alignment before execution - Situation: I proposed a churn-prediction model to target save offers, with the risk of building something complex no one would operationalize. - Task: Align goals, guardrails, and success metrics with cross-functional partners before building. - Action: Mapped stakeholders — PM (target KPI), Eng (integration), Data Eng (features & SLAs), Finance (ROI thresholds), Legal (fairness), Lifecycle Marketing (treatment design), and my manager (prioritization) — and wrote a 1-pager (problem, baseline churn 12%, proposed uplift, offline/online metrics, fairness checks, experiment design). I incorporated feedback by adding a simple logistic baseline alongside the complex model, defining fairness guardrails (no sensitive attributes; equal opportunity within ±3pp across segments), and pre-agreeing a 4-week A/B at 95% power. - Result: Shipped the baseline in 3 weeks; the A/B showed churn 12.0% → 10.1% (−1.9pp) and ~+$420k/quarter net of offer costs; because alignment covered ops details, Marketing operationalized it within one sprint and fairness metrics stayed within guardrails. ## 14) Building long-term relationships and trust - Situation: New DS on a cross-functional surface with multiple teams and ambiguous metric ownership. - Task: Build durable trust and reduce thrash across PM/Eng/Design/Marketing/Support. - Action: Reusable mechanisms — cadences (weekly PM/Eng/DS triad to unblock, bi-weekly experiment review, monthly business review with pre-reads); living docs (versioned metric definitions, experiment templates with success/guardrail criteria, decision logs); a single-source-of-truth dashboard with role-based views and anomaly alerts; and working agreements (DRI map, SLAs for analysis requests, office hours). - Result: Dashboard adoption reached ~120 weekly active users; ad-hoc Slack pings −40%; request turnaround −35%; cross-team satisfaction 3.9 → 4.6/5 over two quarters. ## Guardrails and validation to mention if asked - Pre-register primary success and guardrail metrics with MDE before launching; check sample-ratio mismatch, novelty decay, and bot/duplicate traffic; use variance reduction (CUPED) where covariate stability holds. - Handle sequential peeking with proper alpha spending or fixed-horizon rules; validate long-term effects with holdouts or switchbacks. - Ensure reproducibility (versioned code/notebooks, data contracts) and document assumptions and limitations in every readout. ## Common pitfalls - Vague results — always quantify or explain why you can’t, then use a proxy. - Over-indexing on heroics — emphasize cross-functional collaboration and risk management. - Missing trade-offs — state explicitly what you sacrificed (speed vs. data quality, learning vs. safety) and why.

This is the Meta DS onsite behavioral & leadership round, so the rubric scores story structure, judgment, and credibility, not a single correct answer. A strong candidate answers each prompt in tight STAR form, names stakeholders and trade-offs, quantifies impact against a stated baseline, and closes with a durable process change. The worked examples are templates to be replaced with the candidate’s own defensible numbers; the recurring DS-specific signals interviewers reward are correct experiment hygiene (pre-registration, SRM/A-A checks, CUPED only when the covariate is stable, proper alpha spending), explicit counterfactuals, and validation of every claimed result.