Q7 of 32 · Behavioural
Tell me about a time you found a critical bug — what happened?
Short answer
Short answer: Pick a real critical bug, walk through how you noticed it, what you did to confirm severity, how you escalated, and the outcome. Show methodical investigation, calm escalation, and follow-up to prevent recurrence.
Detail
Interviewers want to see the moment of finding it and what you did next — calm investigation, clear escalation, and structural follow-up.
STAR walkthrough — sample answer:
Situation: I was running through a smoke check on a release candidate for an internal billing tool the day before deployment. The change in the release was minor — a copy update on the invoice screen.
Task: I'd been assigned smoke testing as a final check. Not deep regression — just verify nothing obvious had broken.
Action: I noticed that one of the customer accounts I was testing had its currency formatted differently — what should have been £1,234.56 was rendering as £123,456 (no decimal). I tried a few other accounts and the issue reproduced for accounts with amounts ending in .x0 — a rounding-display bug. I checked git blame on the rendering code: nothing in the release touched it, but a library upgrade three releases ago had changed the default decimal handling. We'd been shipping invoices with the wrong amount formatted for two months — caught only because most accounts happened to have non-zero pence.
I documented the reproduction steps, attached screenshots of expected vs actual, and went directly to the engineering lead — not via Slack DM, but in person, because the bug had financial implications. We agreed within 30 minutes to hold the release, audited which customers had been sent malformed invoices (about 800), and looped in finance.
Result: We held the release until the fix was in. Finance issued corrections to affected customers proactively (no customer reported it before we did). I added a regex-level invoice format check to the test suite and a synthetic that ran nightly against three known account shapes. The library upgrade had bypassed our existing tests because the existing tests didn't cover trailing-zero amounts.
What I learned: dependency upgrades deserve their own regression scope, not "it builds fine." I added a checklist item to the test plan for any PR that bumps a major library version.
Why this works: shows methodical investigation (reproducing, checking blame, scope of impact), calm escalation (in-person to the right person, not panic in a public channel), and structural follow-up (test, synthetic, checklist) — all the marks of someone who'll handle real incidents well.
// WHAT INTERVIEWERS LOOK FOR
// COMMON PITFALL
// Related questions
Describe a time when production caught a bug your testing missed — what did you change?
Manual & exploratory
Describe a difficult production incident you investigated. What was your role?
Behavioural
Tell me about a time you missed a bug that reached production. What did you do?
Behavioural
A QA engineer discovers that an API key was committed to the test repository 6 months ago and is still in Git history. What is your remediation plan?
Git