Demonstrate fit with quantified stories and motivations

# How to Approach This Prompt (Data Scientist) Use a structured narrative (CAR or STAR): Context → Actions → Results. Make your impact measurable, include a counterfactual for causality, and surface judgment (trade-offs, mistakes, stakeholder management). Below are examples you can adapt, plus templates and a 90‑day plan. --- ## Story 1 — Professional Example (Experimentation to Increase New‑User Activation) Context - Role: Data Scientist (Product/Growth) - Team: 1 DS (me), 1 PM, 4 SWE, 1 MLE, 2 Data Engineers, 1 Designer, 1 UXR; partners: Trust & Safety, Analytics Engineering - Dates: Jan–Jun 2023 (6 months) - Stakeholders: Head of Growth, Trust & Safety Lead, Mobile Lead, Legal (policy constraints) - Goal tied to DS scope: Increase new‑user 7‑day activation via feed ranking and onboarding experiments, while holding safety/quality guardrails flat or better Actions - Decision 1 (Metrics and guardrails): Defined primary metric as 7‑day activation (completed key action + 2 sessions). Secondary: D1 retention. Guardrails: crash rate, report/violation rate per 1,000 sessions, content quality score - Decision 2 (Experiment design for power): 50/50 split with CUPED to reduce variance; pre‑registered success criteria; estimated sample size for +1.5pp detectable effect at 90% power, α=0.05 - Decision 3 (Modeling/feature scope): Shipped a regularized logistic model + calibrated heuristics for cold start (latency <50ms), instead of a deeper GBDT that required feature backfills; prioritized speed and safety with staged rollout - Controversial trade‑off: Launched at 30% traffic throttle with a narrower feature set to meet latency/safety constraints, delaying potentially higher upside. This disappointed some stakeholders but reduced downside risk and enabled faster learnings - Mistake and correction: Initial activation definition in the experiment tracker omitted “completed key action.” Detected via metric parity checks (dashboard vs. SQL validation). Corrected the definition, backfilled events, re‑ran the interim analysis, extended the test one week, and added a pre‑launch metric definition checklist for all future experiments Results - Baseline vs. After: 7‑day activation 24.0% → 26.2% (+2.2pp, +9.2% lift), p<0.01; D28 retention +1.1pp; session crash rate unchanged; safety incident rate 0.85% → 0.83% (−2.4% rel) - Counterfactual: Seasonality/synthetic control from prior cohorts indicated a −0.5pp expected dip; difference‑in‑differences suggests net +2.7pp vs. counterfactual - Business impact: ≈140k additional activated users/quarter; projected incremental LTV ≈$1.2M/quarter - Learning: Staged rollouts with strong guardrails let us ship faster while preserving 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: 8 volunteers (ops, sponsorship, mentorship), 3 NGO partners - Dates: Sep–Nov 2022 (10 weeks) - Stakeholders: NGO program leads, university partners, sponsors, mentors - Goal tied to DS competencies: Increase participation and project completion by using data‑driven planning and mentorship logistics Actions - Decision 1 (Format): Switched to hybrid (in‑person kickoff, virtual sprints) after surveying constraints; targeted participant diversity and mentor availability - Decision 2 (Mentorship): Introduced scheduled mentor office hours and triage channels for data access, resulting in faster unblock times - Decision 3 (Data curation): Pre‑vetted datasets and provided shared notebooks with starter EDA to reduce time‑to‑first‑insight - Controversial trade‑off: Capped team size at 4 and limited total teams to ensure mentor coverage and NGO quality, trading breadth for depth of outcomes - Mistake and correction: Early sign‑up metrics double‑counted re‑registrations; reconciled by unique email + device fingerprint, re‑baselined targets, and automated dedupe in the registration form Results - Baseline vs. After: Participants 60 → 110 (+83%); project completion 45% → 72% (+27pp); event NPS 41 → 72 (+31) - Counterfactual: Comparable campus events grew ~10–15% YoY; our synthetic control median was +12%, indicating we outperformed expected growth by ~70pp - Outcome: 7 NGO handoffs with reproducible notebooks and documentation; two teams continued pro‑bono work for 3 months --- ## Motivation — Why Now (Push vs. Pull) Ranked Push Factors (away from current role) 1) Learning plateau on experimentation/science scope (limited ownership) 2) Reorg increased on‑call/interrupt work, reducing time for deep analysis 3) Product roadmap shifting away from user‑impact areas I care about Ranked Pull Factors (toward this role) 1) Opportunity to own high‑scale product experimentation and metrics with strong engineering partners 2) Culture that values rigorous causal inference, safety/quality guardrails, and fast iteration 3) Data access and tooling maturity (experimentation platform, CI/CD for analytics, reliable telemetry) 4) Strong cross‑functional collaboration with PM/Eng/Design/Trust & Safety Non‑negotiables - Ethical data use and meaningful user impact - Clear problem ownership and access to experimentation/telemetry - Supportive manager/mentorship and growth opportunities - Reasonable on‑call expectations and focus time - Workplace flexibility consistent with team norms --- ## End‑to‑End Project Walkthrough (Deeper Dive on Story 1) Problem framing and hypothesis - Problem: New users churn before forming a habit; onboarding and early recommendations under‑personalized - Hypothesis: Improving early‑stage ranking and key action guidance will increase 7‑day activation and downstream retention without increasing 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, quality signals - Data checks: event schema coverage, lag/latency SLAs, bot/outlier filters Methodology - Metric definitions: primary (7‑day activation), secondaries (D1 retention, session length), guardrails (violation/report rate, crashes) - Experiment design: 50/50 split; CUPED for variance reduction; pre‑registration of metrics and stopping rules; A/A test for bucket sanity - Model: Regularized logistic for early ranking + heuristics for new users to meet latency; offline evaluation with time‑based splits Power and sample size (example) - Target minimal detectable change (MDC): Δ = 1.5pp on baseline p = 0.24, α = 0.05, power = 0.90 - Approximate per‑arm sample: n ≈ 2 * (Zα/2 + Zβ)^2 * p(1−p) / Δ^2 - With Zα/2 ≈ 1.96, Zβ ≈ 1.28, p(1−p) ≈ 0.1824, Δ = 0.015 → n ≈ 140k per arm (adjusted downward with CUPED) Risk and guardrails - Safety: monitor violation rate, blocklist drift; gating rollout at 30% → 60% → 100% - Latency: <50ms p95; fail‑open to baseline ranking on timeouts Results and interpretation - Observed lift +2.2pp; guardrails stable; heterogeneous effects stronger in EN/US and Android low‑end devices - DiD against synthetic control supports causal impact beyond seasonality What I’d do differently - Pre‑launch: stricter metric definition checklist, earlier schema validation - Experimentation: sequential testing (alpha‑spending) to manage duration without inflating Type I error - Modeling: invest in debiased offline evaluation (IPS/DR) to better predict online impacts --- ## Team Topology Where I’m Most Effective Configuration - Core: 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; monthly roadmap - Artifacts: metric dictionary, experiment PRDs, RACI for decision rights, analytics runbooks Handling unclear responsibilities or conflict - Establish RACI early (e.g., DS accountable for experiment design/analysis; PM accountable for problem framing; Eng for implementation/latency) - Use written pre‑reads to surface disagreements before meetings - Resolve conflicts with data and shared principles (e.g., do not end experiments early without pre‑defined stopping rules; safety guardrails trump 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 - Ship: environment setup; reproduce 3 core dashboards; metric dictionary read‑through; A/A sanity check on experiment platform - Meet stakeholders (PM/Eng/Design/T&S/DE) and shadow decision reviews - Identify 2–3 quick wins (metric definition clarifications, 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; add guardrail monitoring - Deliver one deep‑dive insight that influences roadmap prioritization Days 61–90: Scale and roadmap - Read out results with causal interpretation and sensitivity checks - Propose next‑step experiments and a 6‑month measurement plan (KPIs, guardrails, data quality SLAs) - Partner with DE/Eng to harden analytics CI/CD and experiment review rituals Success criteria - One shipped experiment with clear readout and at least one decision influenced - Improved metric definitions or dashboards adopted by the team - Stakeholders see me as the go‑to for experimentation and measurement --- ## Fill‑In Templates You Can Copy Two‑Story Template (per story) - Context: Role; Team (size/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 (Δ, significance); Metric B baseline → after; Counterfactual method and net effect; Business impact Motivation Template - Push (ranked): 1) … 2) … 3) … - Pull (ranked): 1) … 2) … 3) … - Non‑negotiables: … End‑to‑End Walkthrough Template - Problem & hypothesis → Data sources/quality → Method (analysis/model/experiment) → Decisions & risks → Results & counterfactual → What I’d change --- ## Validation Checklist (Before You Deliver Your Answers) - Do both stories include three owned decisions, one controversial trade‑off, and one mistake with correction? - Are there at least two quantified metrics with baseline vs. after, plus a counterfactual? - Are metric definitions precise and guardrails included? - Is causality addressed (A/A, DiD, seasonality control, or holdout)? - Are trade‑offs and stakeholder dynamics explicit, not implied? - Can you defend methodology (power, stopping rules, logging QA)? This structure shows impact, judgment, and scientific rigor—what interviewers expect from a strong Data Scientist in a technical behavioral screen.