Describe resume highlights and confirm logistics

Below is a teaching-oriented way to craft your answer, followed by a polished example tailored to a Machine Learning Engineer technical screen. Adapt the examples to your actual experience. ## How to Structure Your Answer (3–5 minutes total) - Select 2–3 projects aligned to product ML: ranking/recommendations, integrity/trust, growth/retention, search, notifications. - Use Problem–Action–Result (PAR): - Problem: 1–2 sentences with business goal and metric. - Action: your decisions across data, modeling, infra, experimentation; note collaborators. - Result: measurable impact with guardrails; include trade-offs. - Offer a deep-dive option: “Happy to go deeper on modeling objective or online serving.” Helpful metrics and concepts: - Offline: AUC/PR, NDCG@k, calibration, MAPE/MAE, coverage. - Online: CTR/ER, engaged sessions, retention, complaint/unsubscribe rate, TTR (time-to-removal), latency (p50/p95), cost. - Experimentation: A/B with CUPED, sequential testing, off-policy evaluation (IPS/DR), guardrails. Formulas you might reference succinctly: - Inverse Propensity Scoring (simplified): IPS = (1/n) ∑ [ y_i / p(a_i|x_i) ] - Uplift (two-model): uplift(x) = p(y|t=1,x) − p(y|t=0,x) --- ## Example Answer (3 projects) ### Project 1 — Home Feed Ranking Overhaul - Problem: Engagement on the feed was plateauing; we targeted a lift in engaged sessions and retention while protecting quality and latency. - My role: Lead IC; partnered with a DS, a ranking infra engineer, and two product engineers. I owned modeling, offline/online evaluation, and rollout. - Technical decisions: - Objective: Multi-objective loss balancing short-term engagement with long-term quality. We used a weighted objective: L = w1·CE(click) + w2·CE(save/share) − w3·CE(negative signals), tuned via Bayesian optimization. - Bias reduction: Used off-policy evaluation (IPS/DR) to compare candidates before A/B, mitigating position bias. - Representation: Two-tower embeddings (user/content) trained with sampled softmax; added graph/co-visit features; feature store for consistency. - Ranking system: 2-stage (ANN retrieval → GBDT/Transformer ranker), with 120 ms p95 latency budget; per-request feature caching. - Experimentation: CUPED to reduce variance; guardrails for creator exposure, ad RPM, and complaint rate. - Impact: - +4.2% engaged feed sessions (p<0.05), +7.0% saves/shares, neutral on ad RPM, +0.6 pp D1 retention for new users. - p95 latency down from 160 ms to 118 ms; feature computation cost −12% via caching. - Lessons: Calibration improved offline→online correlation; we added online monitoring for feature drift and model calibration. ### Project 2 — Spam/Policy-Violating Content Detection - Problem: Increase in spam and low-quality content raised complaint rates and hurt trust. - My role: Drove model design and streaming pipeline; collaborated with Policy, Ops, and Trust & Safety. - Technical decisions: - Labels: Combined user reports and reviewer labels; handled noisy positives via positive–unlabeled learning. - Models: Text/image embeddings + XGBoost baseline; later moved to a lightweight Transformer classifier for better recall at fixed latency. - Thresholding: Cost-sensitive decision thresholds per segment to control false positives for high-value creators. - Active learning: Uncertainty sampling to focus reviewer effort; weekly retraining. - Serving: Kafka → Flink for near-real-time scoring; SHAP summaries for explainability to reviewers. - Impact: - −23% user-reported spam, −37% median time-to-removal, creator false-positive rate −2.1 pp. - Maintained p95 scoring latency under 80 ms; reviewer throughput +15% with model explanations. - Lessons: Feedback loops can amplify bias; we instituted stratified sampling and periodic “golden set” audits to prevent drift. ### Project 3 — Notification Send-Time Personalization & Uplift - Problem: Push notification engagement was inconsistent; blanket schedules caused unsubscribes. - My role: Owned modeling and experimentation; partnered with lifecycle marketing and mobile. - Technical decisions: - Send-time: Contextual bandits to learn user-local send windows; constraints for quiet hours and rate limits. - Objective: Optimized for incremental opens (uplift), not average CTR. Implemented a DR-learner to estimate treatment effects. - Experimentation: Geo/user holdouts to estimate long-term retention effects; sequential testing with guardrails on opt-outs/complaints. - Impact: - +9.5% push open rate, −18% complaint/unsubscribe rate, +1.3% 7-day retention for new users from lifecycle programs. - Reduced over-sends by 21%, cutting infra costs ~8% for the channel. - Lessons: Optimizing for uplift avoids over-notifying highly active users; long-term holdouts were essential to detect retention impacts. --- ## Common Pitfalls to Avoid - Vague ownership: Be explicit about what you personally decided/built vs. team work. - No metrics: Use percent changes, CIs, or ranges if you can’t share absolutes; note guardrails. - Only model talk: Include data quality, serving, latency, and experiment design. - Ignoring trade-offs: Acknowledge what you sacrificed and why (e.g., slight CTR drop for quality/retention gains). ## If You Can’t Share Exact Numbers - Use relative terms: “low single digit,” “mid single digit,” “double digit.” - Provide ranges and confidence: “~3–5% lift with p<0.05; no movement on churn.” ## Logistics (close succinctly) Provide a crisp summary at the end. Template: - Earliest start date: <date or notice period> - Work authorization: <status; any sponsorship/transfer needs> - Work preference: <onsite/hybrid/remote>; <cities or time in office> - Time zone: <base TZ>; availability window if constrained Example: - Earliest start date: 3 weeks after offer - Work authorization: Permanent resident; no sponsorship required - Work preference: Hybrid in the Bay Area; 2–3 days onsite - Time zone: Pacific Time; available 9am–5pm PT, flexible for occasional early meetings Deliver your projects in the above structure, then read out the logistics block to finish cleanly.