Give your elevator pitch in 60 seconds: who you are, the scale you have worked at, and your superpower. Then take one experimentation project that produced a measurable business impact and walk it end to end: problem framing, hypothesis, unit of randomization, primary and guardrail metrics, sample size/power, duration, pre-registration/analysis plan, execution challenges, and final results with concrete numbers (e.g., +X% conversion at Y% significance, a Z p.p. change in a guardrail). Explain the causal story (why it worked), the trade-offs you weighed, and what you would change. Close by answering "Why Meta?" — connect your motivations to a specific product surface you would join and to how your skills suit the role.

Overview: This question assesses a data scientist's communication and leadership competencies: tight elevator pitching, product sense, end-to-end experimentation design and statistical rigor, causal reasoning, and the ability to put a number on business impact inside a product context.

Solution

1) The 60-Second Elevator Pitch

• I am a data scientist with 7+ years across consumer growth and marketplace/notifications. I have run 200+ online experiments on products reaching 100M+ MAU and shipped features that moved DAU and revenue at scale.
• My superpower is turning ambiguity into decision-ready experiments: crisp problem framing, clean metrics, and pre-registered analyses that stakeholders trust.
• I work closely with engineering and PMs, and I am known for fast, reliable reads (CUPED/stratification) and for telling a causal story that steers roadmap choices. Tip: Rehearse a 3-sentence cut: role + scale, superpower + one quantified impact, collaboration style.

2) Experimentation Case Study: Personalized Send Times for Push Notifications

Scenario: The aim was to grow high-quality sessions by delivering each user's notifications at their best time of day. A) Problem Framing

• Observation: Notification open rates had flattened, and weekly opt-out ("mute/unsubscribe") rates were creeping up by +0.05 p.p./week.
• Goal: Increase notification-driven session starts without hurting the user experience.
• Decision: Build a per-user send-time model rather than fixed times, and validate it with an A/B test. B) Hypothesis
• H1: Personalizing send time will raise notification-driven session starts per user-week by ≥2% relative.
• H2 (guardrail): Opt-out rate will not worsen by more than +0.10 percentage points. C) Unit of Randomization
• Randomize at the user level (1:1). Rationale: the treatment is delivered per user, network interference is minimal, and contamination is avoided.
• Stratify by: app platform (iOS/Android), region (US/ROW), and engagement tier (low/med/high) to balance covariates and gain power. D) Metrics
• Primary: Notification-driven session starts per user per week.
  • Attribution: a session starting within 10 minutes of a received push (last-touch).
• Key secondary: Notification open-through rate (OTR).
• Guardrails:
  • Opt-out/mute rate (weekly, p.p.).
  • Negative feedback rate on notifications (p.p.).
  • Battery impact (average CPU/network per active user).
  • Experiment collision rate (overlapping tests), crash rate. E) Sample Size, Power, Duration
• Design: Two-sided test, $\alpha = 0.05$, power $= 0.80$.
• Metric type: Approximate the primary as continuous (sessions per user-week) with historical $\sigma \approx 0.90$ and mean $\approx 0.80$.
• Minimum Detectable Effect (MDE): +2% relative on the mean, i.e. $\delta = 0.016$ sessions/user-week.
• Formula (two-sample t-test approximation):

$$n_{\text{per group}} \approx 2 \times (Z_{1-\alpha/2} + Z_{1-\beta})^2 \times \frac{\sigma^2}{\delta^2}$$

Taking $Z_{1-\alpha/2} = 1.96$ and $Z_{1-\beta} = 0.84$:

$$n_{\text{per group}} \approx 2 \times (2.8)^2 \times \frac{(0.9)^2}{(0.016)^2} \approx 61{,}000$$

users per group per full week.

• CUPED variance reduction (25% seen historically) effectively cuts the required n to about 46k per group.
• Duration: 14 days, covering two weekly cycles and weekend effects; ramp 10% → 50% → 100% inside the experiment while keeping 1:1 assignment intact. F) Pre-registration / Analysis Plan
• Assignment: User-level ITT (intention-to-treat).
• Invariants check: Balance on key covariates (platform/region/engagement) and pre-period outcomes.
• Variance reduction: CUPED on prior-week sessions ($X$):

$$Y_{\text{adj}} = Y - \theta (X - \mathbb{E}[X]), \quad \theta = \frac{\operatorname{Cov}(Y, X)}{\operatorname{Var}(X)}$$

• Estimator: Difference in means with cluster-robust SEs at the user level; stratification fixed effects.
• Multiple metrics: Keep family-wise error under control by pre-specifying the primary and reading guardrails descriptively unless one is breached.
• Early looks: O'Brien–Fleming alpha-spending for optional stopping (checks at day 7 and 14).
• Exclusions: Known push-denied users; catastrophic log gaps; everyone else stays in the ITT population. G) Execution Challenges
• Capacity limits: Coordinated with infra to stagger send windows; used feature flags to rate-limit.
• Time zones/daylight savings: Derived local send windows from device time and validated them with synthetic tests.
• Event attribution: Applied a 10-minute last-touch rule and de-duplicated bursts.
• Experiment collisions: Registered and filtered users in high-conflict cohorts (other notification tests); monitored collision rate.
• Novelty effects: Tracked effect decay over the 2-week window; planned a post-ramp holdout. H) Results (illustrative but internally consistent)
• Primary: +2.6% sessions/user-week (ITT), 95% CI [+1.8%, +3.4%], p < 0.001.
• Secondary: +5.1% OTR, 95% CI [+3.9%, +6.3%].
• Guardrails:
  • Opt-out rate: −0.08 p.p. (an improvement), 95% CI [−0.12, −0.04].
  • Negative feedback: +0.01 p.p., n.s.
  • Battery: +0.2% CPU per active user, within SLO.
• Heterogeneity (pre-specified): Bigger effects among "low engagement" users (+4.3%) and evening-preferring clusters; iOS > Android.
• Business impact: Across 50M eligible weekly users, +2.6% works out to roughly 1.3M incremental weekly sessions, with opt-outs improving — approved for 100% rollout. I) Causal Story (Why It Worked)
• Mechanism: Matching send time to when a user is available raises salience and lowers interruption cost. A higher last-touch probability produces more opens and near-immediate sessions.
• Evidence: The lift concentrated where model confidence was high and during predicted peak times, with no rise in negative feedback — pointing to greater relevance rather than more sending. J) Trade-offs Considered
• Volume vs. quality: Message volume was held constant to isolate timing; the next step is optimizing volume and timing jointly.
• Fairness: Guarded against systematically deprioritizing certain time zones or work schedules; monitored subgroup effects.
• Platform complexity: Extra scheduling complexity weighed against measurable lift; reliability validated under infra constraints. K) What I'd Do Differently
• Long-run effects: Staggered geo rollouts with a dark holdout to measure persistence and novelty decay.
• Modeling: Contextual bandits for joint timing + content; add cost-aware policies (battery, channel fatigue).
• Quality outcomes: Add downstream guardrails (session depth, well-being proxies) so we are not optimizing last-touch alone.
• Interference checks: A small cluster-randomized holdout by household/device family to confirm spillovers are negligible. Teaching notes: The key is crisp pre-specification, a defensible primary metric that maps to business value, realistic power math, and a clean causal narrative. Guardrails should reflect user trust and system health.

3) Why Meta? Product Surface + Fit

• Motivation: Meta's scale, its rapid experimentation culture, and the chance to balance growth against integrity and long-term user value are what attract me.
• Product surface: Instagram Reels notifications and discovery. It is a high-leverage surface connecting creators and viewers where timing, ranking, and user well-being all matter.
• Fit: My strengths in experimental design (powering large-scale AA/A/Bs, CUPED, stratification), causal inference, and metric design map directly onto optimizing alert relevance, watch-time quality, and opt-out/negative feedback guardrails. I am comfortable partnering with engineering to build reliable experimentation plumbing and with PMs to define MDEs that matter.
• Impact plan: Start with a metrics and invariants audit, ship a fast end-to-end timing/content test with pre-registered guardrails, then scale through adaptive policies and heterogeneity-aware insights for creators and cohorts. Checklist you can adapt:
• State the business problem in one sentence and name the lever (e.g., timing).
• Hypothesis with a numeric MDE that matters.
• Unit of randomization and interference rationale.
• Primary metric and 2–4 guardrails tied to user trust/system health.
• Power math with assumptions and a duration plan.
• Pre-registration: ITT, variance reduction, multiple-testing approach.
• Execution risks and mitigations.
• Results with CI/p-values and p.p. changes on guardrails.
• Causal story, trade-offs, and a concrete "do next."
• Close with a specific team/surface and how your skills drive impact there.