Tell about a past project and impact

How to answer effectively (framework) Use a structured, concise story (3–5 minutes), then be ready to dive deep technically. A good flow: 1) Context (1–2 sentences) - What the system/product does, who it serves, why it mattered now. 2) Goals & Success Criteria - State SMART goals with baselines and targets. - Example metrics: latency (p95/p99), availability (SLO), error rate, cost, adoption, revenue, NPS. 3) Your Role & Scope - Team size, your ownership (design, coding, rollout, on-call), leadership elements. 4) Timeline & Plan - Major phases and key milestones; show planning ability. 5) Key Decisions & Trade-offs - Alternatives considered, why you chose one, trade-offs (latency vs. correctness, consistency vs. availability, build vs. buy). 6) Challenges & Conflicts - Technical unknowns, incidents, cross-team conflicts; how you de-risked and resolved. 7) Stakeholder Management - Who (PM, infra, mobile, data, SRE, legal, ops), alignment methods (RFCs, design reviews, demos), communication cadence. 8) Results & Impact (Quantified) - Before/after numbers and business impact. Use percentages and absolute values when possible. - Simple formulas: - Percent reduction = (before − after) / before × 100% - Absolute delta = after − before 9) Reflection - What you’d change, process or technical improvements, what you learned. How to choose the project - Impact: Clear, measurable outcome. - Complexity: Non-trivial system or trade-offs. - Cross-functional: Shows collaboration and influence. - Recency: Within the last 1–2 years if possible. - Relevance: Aligns with real-time, backend, scalability, reliability, or product engineering problems. Sample answer (Software Engineer, backend, real-time system) 1) Context Our real-time matching service was responsible for pairing users with nearby providers. Peak-time p95 latency had grown to ~450 ms, causing timeouts in downstream clients and a lower match rate. 2) Goals & Success Criteria - Reduce p95 latency from ~450 ms to <200 ms and p99 <400 ms. - Improve match success rate by ≥2 percentage points (pp). - Maintain 99.99% availability; no regression in correctness (target ≥99.9% replay accuracy). 3) My Role I served as the tech lead for a team of 5 engineers. I owned the design, rollout plan, performance testing, and cross-team coordination with SRE, data, and mobile. 4) Timeline & Milestones (12 weeks) - Weeks 1–2: RFC, alignment, load testing to baseline. - Weeks 3–5: Implement candidate precomputation + Redis cache; introduce gRPC between services; add circuit breakers. - Weeks 6–7: Shard-by-region partitioning; hot-shard mitigation; backfill scripts; chaos drills. - Weeks 8–9: Canary (1% → 10% → 50%), automatic rollback gates; observability dashboards. - Weeks 10–12: Full rollout, post-launch tuning, postmortem and documentation. 5) Key Decisions & Trade-offs - Precompute candidate sets vs. compute-on-demand: chose hybrid (precompute top-N every few seconds + on-demand refinement) to balance freshness and latency. - gRPC over REST: improved serialization and connection reuse; required client updates but gave ~20–30% latency gain. - Region-based sharding: reduced hot spots at the cost of occasional cross-shard lookups. Added a fallback path for border cases. - Consistency vs. availability: added circuit breakers and stale-read fallback to preserve availability during partial outages. 6) Challenges & Conflicts - Infra limits: Redis cluster nearing memory ceilings; negotiated a tiered cache with TTL tuning and compression; added cache hit telemetry to justify capacity. - Cross-team conflict: PM wanted concurrent feature work; I proposed a two-track plan with a frozen API for the new feature atop the stabilized service; we aligned on safety first, then feature delivery. - Production incident during canary: increased GC pauses after enabling additional metrics. We reduced labels cardinality, batched metrics, and tuned GC, then resumed rollout. 7) Stakeholder Management - Weekly status with PM and ops; biweekly steering with SRE, data science, and mobile leads. - Shared RFC, design diagrams, and rollout dashboards; posted daily canary metrics and clear rollback criteria. 8) Results & Impact - p95 latency: 450 ms → 180 ms (−60%); p99: ~900 ms → 320 ms. - Match rate: +2.7 pp; timeout-related cancellations: −8%. - Availability: sustained 99.995% during peak post-rollout. - Cost: compute cost −18% via better caching and fewer retries. - Operational load: on-call pages dropped from ~12/month to ~2/month. - Business impact: estimated +$1.2M/quarter from higher conversion during peaks. 9) What I’d Do Differently - Run an earlier cross-team design review to uncover observability cardinality risk. - Add a staging load test mirroring peak traffic patterns; include chaos testing as a mandatory gate. - Publish a versioned API and migration guide earlier to reduce client integration friction. Why this works - Maps directly to the interviewer’s bullets and quantifies impact. - Demonstrates leadership, technical depth, decision-making, and stakeholder alignment. - Shows you can plan, execute, de-risk, measure, and reflect. Template you can reuse - Context: One sentence on the system and the problem. - Goals & Success: Baselines and targets (metric → before → after → target). - Role: Team size, your ownership. - Timeline: Phases and milestones. - Decisions: Options, choice, trade-offs, why. - Challenges/Conflicts: What happened, how you resolved it. - Stakeholders: Who, cadence, artifacts (RFCs, dashboards, demos). - Impact: Quantified results and business link. - Reflection: What you’d change. Tips & guardrails - Timebox to 3–5 minutes; be ready to deep dive on design and metrics. - Use numbers; if under NDA, use relative changes (e.g., “~50% reduction”). - Stay professional in conflicts; focus on behaviors and resolution. - Tie back to the role: scale, reliability, low-latency, distributed systems, or product outcomes as relevant. - Bring a simple diagram if asked; have logs/metrics examples in mind for follow-ups.