Select two narratives—one work-related and one outside work—that show you are a strong match for the position. For each story, cover: (1) Context: your title, team size and structure, timeframe, main stakeholders, and an objective explicitly connected to the job description; (2) Actions: three choices you owned, one debatable trade-off you accepted, and one error you fixed—and how; (3) Results: show measurable impact with at least two metrics (baseline versus afterward, plus a counterfactual). Next, answer: what exactly is making you look for new opportunities now—split push and pull reasons, order them by priority, and name any must-haves? Take one earlier project from start to finish, outlining the abilities you drew on and what you would change in hindsight. Explain the team setup (roles, seniority balance, working rituals) in which you performed best, and how you managed ambiguous ownership or disagreement. End by connecting these experiences to what you would do in your first 90 days in the job. Overview: The question assesses a Data Scientist's behavioral and leadership strengths: telling stories with measurable results, owning technical decisions, weighing trade-offs, spotting and fixing errors, motivation, collaboration, and end-to-end project thinking. Solution

How to Approach This Prompt (Data Scientist)

Use a clear narrative structure such as CAR or STAR: Context → Actions → Results. Make results quantitative, include a counterfactual to support causality, and reveal judgment through trade-offs, mistakes, and stakeholder management. Below are adaptable examples, templates, and a 90-day plan.

Story 1 — Professional Example (Experimenting to Lift New-User Activation)

Context

• Role: Data Scientist focused on Product/Growth
• Team: one data scientist (me), one PM, four SWEs, one MLE, two data engineers, one designer, one UXR; collaborating with Trust & Safety and Analytics Engineering
• Dates: January–June 2023 (six months)
• Stakeholders: Head of Growth, Trust & Safety Lead, Mobile Lead, Legal (policy limits)
• Goal aligned to the DS mandate: Raise new-user 7-day activation through feed ranking and onboarding experiments while keeping safety and quality guardrails unchanged or improved Actions
• Decision 1 (metrics and guardrails): Chose 7-day activation as the primary metric, defined as completing a key action plus two sessions. Used D1 retention as secondary. Guardrails were crash rate, report/violation rate per 1,000 sessions, and content quality score.
• Decision 2 (experiment design for power): Ran a 50/50 split with CUPED to lower variance, pre-registered success criteria, and sized the sample to detect a +1.5 percentage-point effect at 90% power with $\alpha = 0.05$.
• Decision 3 (modeling/feature scope): Deployed a regularized logistic model plus calibrated cold-start heuristics with latency below 50 ms, rather than a more complex GBDT requiring feature backfills; prioritized speed and safety using a staged rollout.
• Controversial trade-off: Started at a 30% traffic throttle with a reduced feature set to satisfy latency and safety constraints, which delayed potentially larger gains. Some stakeholders were dissatisfied, but this lowered downside risk and produced quicker learning.
• Mistake and correction: The first activation definition in the experiment tracker left out 'completed key action.' Caught it through metric parity checks comparing the dashboard with SQL validation. Fixed the definition, backfilled events, redid the interim analysis, extended the experiment by one week, and added a pre-launch metric-definition checklist for future experiments. Results
• Baseline versus after: 7-day activation rose from 24.0% to 26.2% (+2.2 points, +9.2% relative), $p < 0.01$; D28 retention improved by +1.1 points; session crash rate stayed flat; safety incident rate moved from 0.85% to 0.83% (−2.4% relative).
• Counterfactual: Seasonality/synthetic control built from earlier cohorts suggested an expected −0.5-point dip; difference-in-differences points to a net +2.7-point gain over that counterfactual.
• Business impact: about 140k added activated users per quarter; estimated incremental LTV around $1.2M per quarter.
• Learning: Staged rollouts with strong guardrails allowed faster shipping while protecting trust and safety outcomes.

---

Story 2 — Personal Example (Leading a Data-for-Good Hackathon)

Context

• Role: Volunteer organizer and lead for a community data-for-good hackathon
• Team: eight volunteers covering operations, sponsorship, and mentorship; three NGO partners
• Dates: September–November 2022 (ten weeks)
• Stakeholders: NGO program leads, university partners, sponsors, mentors
• Goal aligned with DS competencies: Grow participation and project completion by using data-informed planning and mentorship logistics Actions
• Decision 1 (format): Moved to a hybrid model—in-person kickoff with virtual sprints—after surveying constraints; aimed at participant diversity and mentor availability.
• Decision 2 (mentorship): Added scheduled mentor office hours and triage channels for data access, which shortened unblock times.
• Decision 3 (data curation): Pre-vetted datasets and shared notebooks with starter EDA to cut time-to-first-insight.
• Controversial trade-off: Limited teams to four people and capped total teams to protect mentor coverage and NGO quality, choosing depth of results over breadth.
• Mistake and correction: Early sign-up numbers double-counted re-registrations; resolved this by matching unique email plus device fingerprint, resetting targets, and automating deduplication in the registration form. Results
• Baseline versus after: participants grew from 60 to 110 (+83%); project completion rose from 45% to 72% (+27 points); event NPS increased from 41 to 72 (+31).
• Counterfactual: Similar campus events grew roughly 10–15% year over year; our synthetic control median was +12%, meaning we beat expected growth by about 70 points.
• Outcome: seven NGO handoffs included reproducible notebooks and documentation; two teams continued pro bono work for three months.

---

Motivation — Why Now (Push vs. Pull)

Ranked push factors (away from current role)

1. Experimentation and science scope have reached a learning plateau, with limited ownership.
2. A reorg increased on-call and interrupt work, cutting time for deep analysis.
3. Product roadmap is moving away from the user-impact areas I care about. Ranked pull factors (toward this role)
4. A chance to own high-scale product experimentation and metrics with strong engineering partners.
5. A culture that values rigorous causal inference, safety/quality guardrails, and rapid iteration.
6. Mature data access and tooling: an experimentation platform, analytics CI/CD, and dependable telemetry.
7. Close cross-functional collaboration with PM, engineering, design, and Trust & Safety. Non-negotiables

• Ethical data use and meaningful user impact
• Clear problem ownership and access to experimentation/telemetry
• A supportive manager/mentor and growth opportunities
• Reasonable on-call expectations and protected focus time
• Workplace flexibility aligned with team norms

---

End-to-End Project Walkthrough (Deeper Dive on Story 1)

Problem framing and hypothesis

• Problem: New users leave before forming a habit; onboarding and early recommendations are not personalized enough.
• Hypothesis: Better early-stage ranking and clearer key-action guidance will lift 7-day activation and later retention without raising safety incidents. Data sources and quality
• Logs: impressions, clicks, key-action events, violations/reports, crashes.
• User features: device, locale, cold-start embeddings; content features: recency and quality signals.
• Data checks: event schema coverage, lag/latency SLAs, bot and outlier filters. Methodology
• Metric definitions: primary metric is 7-day activation; secondaries are D1 retention and session length; guardrails are violation/report rate and crashes.
• Experiment design: 50/50 split, CUPED for variance reduction, pre-registration of metrics and stopping rules, and an A/A test to confirm bucket health.
• Model: regularized logistic model for early ranking plus cold-start heuristics for new users to meet latency; offline evaluation used time-based splits. Power and sample size (example)
• Target minimal detectable change: $\Delta = 1.5$ percentage points on a baseline $p = 0.24$ with $\alpha = 0.05$ and power $= 0.90$.
• Approximate per-arm sample size:

$$n \approx 2 \left(Z_{\alpha/2} + Z_\beta\right)^2 \frac{p(1-p)}{\Delta^2}$$

• With $Z_{\alpha/2} \approx 1.96$, $Z_\beta \approx 1.28$, $p(1-p) \approx 0.1824$, and $\Delta = 0.015$, this gives $n \approx 140{,}000$ per arm, adjusted downward with CUPED. Risk and guardrails
• Safety: monitor violation rate and blocklist drift; rollout gating at 30% → 60% → 100%.
• Latency: under 50 ms p95; fail open to baseline ranking on timeouts. Results and interpretation
• Observed lift of +2.2 points; guardrails were stable; effects were stronger for EN/US and lower-end Android devices.
• Difference-in-differences against a synthetic control supports a causal effect beyond seasonality. What I'd do differently
• Pre-launch: use a stricter metric-definition checklist and validate schemas earlier.
• Experimentation: adopt sequential testing with alpha-spending to control duration without raising Type I error.
• Modeling: invest in debiased offline evaluation such as IPS/DR to better anticipate online impact.

---

Team Topology Where I'm Most Effective

Configuration

• Core team: 1 PM, 1–2 DS, 4–6 SWE, 1 MLE, 1–2 data engineers, 1 designer, 1 UXR.
• Rituals: weekly planning, daily stand-up, experiment design reviews, metric health reviews, post-mortems, and a monthly roadmap.
• Artifacts: metric dictionary, experiment PRDs, a RACI for decision rights, and analytics runbooks. Handling unclear responsibilities or conflict
• Set up RACI early—for example, DS accountable for experiment design/analysis, PM for problem framing, engineering for implementation/latency.
• Use written pre-reads to surface disagreements before meetings.
• Settle conflicts with data and shared principles—e.g., do not stop experiments early without predefined stopping rules; safety guardrails outrank short-term gains.
• Escalate respectfully, with options and trade-offs documented.

---

First 90 Days Plan (Mapping Experiences to Impact)

Days 0–30: Learn and baseline

• Deliver environment setup, reproduce three core dashboards, read through the metric dictionary, and run an A/A sanity check on the experiment platform.
• Meet stakeholders across PM, engineering, design, Trust & Safety, and data engineering; shadow decision reviews.
• Identify two to three quick wins such as metric-definition clarifications or logging gaps. Days 31–60: Quick wins and first experiment
• Propose and launch one low-risk experiment tied to onboarding/discovery or trust/quality.
• Close logging/telemetry gaps and add guardrail monitoring.
• Deliver one deep-dive insight that shapes roadmap prioritization. Days 61–90: Scale and roadmap
• Present results with causal interpretation and sensitivity checks.
• Propose next-step experiments and a six-month measurement plan covering KPIs, guardrails, and data-quality SLAs.
• Partner with data engineering and engineering to harden analytics CI/CD and experiment review rituals. Success criteria
• One shipped experiment with a clear readout and at least one decision influenced.
• Improved metric definitions or dashboards adopted by the team.
• Stakeholders see me as the go-to person for experimentation and measurement.

---

Fill-In Templates You Can Copy

Two-story template (per story)

• Context: role; team size and roles; dates; stakeholders; goal linked to DS scope.
• Actions: [Decision 1], [Decision 2], [Decision 3]; trade-off [X vs. Y]; mistake → detection → fix → prevention.
• Results: metric A baseline → after with delta and significance; metric B baseline → after; counterfactual method and net effect; business impact. Motivation template
• Push factors, ranked: 1) … 2) … 3) …
• Pull factors, ranked: 1) … 2) … 3) …
• Non-negotiables: … End-to-end walkthrough template
• Problem and hypothesis → data sources and quality → method (analysis/model/experiment) → decisions and risks → results and counterfactual → what I'd change.

---

Validation Checklist (Before You Deliver Your Answers)

• Do both stories include three decisions you owned, one debatable trade-off, and one mistake plus the correction?
• Are there at least two quantified metrics with baseline versus after, and a counterfactual?
• Are metric definitions precise and guardrails included?
• Is causality covered through A/A, difference-in-differences, seasonality control, or a holdout?
• Are trade-offs and stakeholder dynamics explicit rather than implied?
• Can you defend the methodology, including power, stopping rules, and logging QA? This structure demonstrates impact, judgment, and scientific rigor—what interviewers look for from a strong Data Scientist in a technical behavioral screen.