This question is not really about the bug. The interviewer is trying to find out how you behave when you do not yet know the answer — which is most of the job.
Most people answer it as a summary: "we had a caching bug, it was a race condition, I fixed it." That is the shape of a Jira ticket, not a story, and it tells the interviewer almost nothing about how you think.
The five beats that actually work
1. The symptom, as reported. Start with what someone noticed, in their words, not yours.
"Support flagged that a handful of customers were seeing yesterday's invoice totals. Not all of them. Not consistently."
That opening already says something useful: the bug was intermittent and partial, which is the hard kind.
2. Your first theory — and say that it was wrong. This is the beat people skip, and it is the most valuable one.
"My first assumption was a stale cache key. We had a Redis layer in front of Postgres, so that was the obvious candidate. I spent about half a day there and found nothing wrong with the invalidation logic."
Admitting a dead end is not a weakness. It shows you form hypotheses and abandon them on evidence, which is exactly the trait being tested.
3. What changed your mind. The pivot is the centre of the story. What observation broke your theory?
"What changed it was noticing the affected accounts were all in one timezone bucket. That had nothing to do with caching, so I stopped looking at Redis."
4. The actual cause, stated plainly. One or two sentences. Resist the urge to over-explain the internals — if they want depth, they will ask.
"The invalidation was firing correctly, but the job that recomputed totals used local time while the cache key used UTC. For a few hours each day they disagreed about which day it was."
5. What you changed so it could not recur. Not just the patch — the systemic bit.
"The fix itself was one line. What mattered more was that we added a test that runs the job at several simulated clock offsets, because the bug was invisible if you only ever tested at midday."
Why the wrong theory matters so much
Almost every candidate presents debugging as a straight line from symptom to cause. Real debugging is not a straight line, and interviewers know this. A story with no dead ends reads as either rehearsed or shallow.
Including the pivot makes the story more credible and demonstrates the actual skill. You are showing that you can hold a theory loosely and drop it when the evidence stops supporting it.
Keep the numbers, drop the acronyms
Say "about a week", "a handful of customers", "one line". Concrete quantities make a story land as real.
Internal service names do the opposite. "The bug was in Atlas talking to Peregrine" means nothing to someone outside your company. Translate to the generic: "the billing service", "our job scheduler".
A note on choosing which bug
Pick one where the cause was genuinely non-obvious but the explanation is short. A bug that takes six minutes to set up is a bad interview story regardless of how impressive it was.
Avoid the one where the answer was "someone else's library had a bug". Those stories have no decision in them, and decisions are what is being assessed.
Two or three of these, practised out loud, cover most of the behavioural round. You are not memorising a script — you are making sure the beats are somewhere you can reach them under pressure.