Q9 of 32 · Behavioural
Tell me about a time you missed a bug that reached production. What did you do?
Short answer
Short answer: Take ownership without minimising. Walk through the bug's nature, the gap in your test coverage that allowed it through, the immediate fix, and the structural change you put in place to prevent recurrence — including sharing the lesson outside your team.
Detail
Behavioural questions about missed bugs test emotional maturity and systems thinking — not whether you've never made a mistake (that answer is itself a red flag).
STAR walkthrough — sample answer:
Situation: A previous team I was on shipped a settings page rewrite. As the QA owner, I'd verified the new UI against the design, tested form submissions, and run regression on the most-used settings.
Task: I was on the hook for confirming nothing broke for existing users on rollout.
Action: I tested with several seed users in staging and the flow worked. What I didn't test was a particular settings combination that only existed for legacy customers from a 2019-era plan tier — about 4% of the user base. The new UI silently dropped one of their toggles when saved, reverting it to the default. The bug surfaced 6 hours after release when a customer wrote in saying their notification preference had changed.
Result: I owned the post-incident report. I led with the gap matter-of-factly: "the test plan didn't include legacy plan-tier accounts, and my staging seed data didn't represent that population." Engineering shipped a hotfix within 2 hours and a backfill script that re-saved the dropped toggles for affected users.
The structural change I made: added a "test data inventory" to the QA wiki that catalogued the user populations we needed to cover (current paid, legacy paid, free tier, admin, suspended) with seed accounts in staging for each. Any feature touching user settings now had a checklist item: "tested against all five populations." I also wrote a short post-mortem and shared it cross-team — three other QA peers added similar checks for their areas.
What I learned: my mental model of "users" was implicitly the most-recent population. Edge populations are real users too, and a representative test data set is a non-negotiable, not a nice-to-have.
Why this answer works: ownership without self-flagellation, system-level analysis (the gap was in test data planning, not just "I missed it"), structural follow-up that scales beyond the immediate bug, and sharing the lesson outside your team.