Describe a failure and learning

# How to Answer (STAR-LV Framework) Use STAR-LV to ensure you cover every element the interviewer wants: - Situation: Brief context (team, system, goal). Keep to 1–2 sentences. - Task: The objective/SLO you aimed for. - Action: What you did and what you failed to do (own it; avoid blaming). - Result: The miss and impact on stakeholders with numbers. - Learning: 1–3 specific insights. - Validation: Concrete changes you implemented and later outcomes that prove they worked. Tips: - Pick a real miss you can fully own, not a catastrophic failure or a trivial nit. - Include metrics (percent, latency, error rates, timelines). If confidential, use bounded ranges. - Say “I” for your contributions/mistakes; use “we” for team collaboration. - Close with how you now operate differently and evidence that it works. # Example Answer (Software Engineer) Situation/Task - I led the rollout of a new backend service to unify pricing rules. The target was to keep p95 latency under 250 ms and error rate under 0.5% at 100% traffic. Action (including what I didn’t do) - I implemented the service and coordinated deployment, but I made two critical mistakes: 1) I did not insist on load tests that matched peak traffic; our tests covered ~30% of expected QPS. 2) I skipped a gradual canary rollout behind a feature flag and lacked a simple circuit breaker for quick rollback. Result/Impact - At full cutover, p95 latency spiked ~35% (to ~340 ms) and error rate hit ~2% for ~25 minutes. - Downstream services retried and amplified load; on-call had to throttle traffic. - Stakeholders impacted: product had to pause an experiment tied to dynamic pricing, customer support saw a temporary increase in tickets, and leadership delayed a marketing push by a day. Learning - Never promote to 100% without a measured canary and rollback path. - Performance gates must reflect real traffic patterns (QPS, payload size, cache warmup). - Observability has to be rollout-ready: SLO dashboards, alert thresholds, and runbooks tested before launch. Changes Implemented - Added a performance gate to CI using k6 with recorded production traces; builds fail if p95 latency exceeds target by >10% at projected peak QPS. - Standardized canary + feature flags: start at 1%, pause to validate SLOs and error budgets, then ramp to 5%/25%/50%/100% with automated abort on deviation. - Introduced a simple circuit breaker and one-click rollback; wrote a runbook and rehearsed it in a game day. - Created pre-launch checklist (load test report, canary plan, dashboards/alerts verified, rollback tested) and a blameless postmortem template with “Five Whys.” Validation (later results) - Next three service launches followed the checklist; all stayed within SLOs. One canary auto-aborted at 5% due to a cache-miss bug; we fixed it within 2 hours without customer impact. - Mean time to recovery for rollbacks dropped from ~45 minutes to ~8 minutes. - Error budget burn stabilized; no latency SLO breaches for two consecutive quarters. - Two other teams adopted the checklist; our CI perf gate now runs on five repos. # Why This Works - It directly answers all parts: what happened, your specific actions/inactions, stakeholder impact, lessons, changes, and proof the changes worked. - It shows ownership, data-driven thinking, and system-level leadership (process + technical). # Template You Can Reuse - Situation/Task: “I was responsible for X; our objective was Y (metric/SLO).” - Action: “I did A and B, but I failed to do C (be explicit).” - Result/Impact: “We missed Y by Z; stakeholders impacted were … (quantify).” - Learning: “Key takeaways were 1), 2), 3).” - Changes: “I implemented … (process/tech/communication changes).” - Validation: “In later projects, results were … (metrics, adoption, fewer incidents).” Pitfalls to avoid - Vague impact: say who felt it and how (customers, partner teams, timelines, costs). - Excuses/blame: own your part; mention collaboration without deflecting responsibility. - No validation: always end with measurable outcomes from subsequent work.