He finished the algorithm problem in eleven minutes. Clean code, correct edge cases, unprompted complexity analysis. Easy hire, I thought.
Then I asked my closer: tell me about a bug you fixed that took more than a day.
Long pause. "Hmm. Nothing comes to mind? I mostly don't write buggy code."
I have asked hundreds of engineers some version of that question. That was the most alarming answer I have ever gotten, and it came from the guy who aced the coding round.
TL;DR
- "Tell me about a bug you fixed" is the highest-signal tech interview question I know, because a real debugging story is nearly impossible to fake and impossible to memorize from a prep site.
- It scores five things at once: observation quality, hypothesis discipline, tooling fluency, whether you found the actual mechanism, and what you changed so it can't recur.
- The strongest tellers are precise about the boring parts: the exact symptom, the wrong guess they chased first, the tool that showed them the truth.
- "I don't really hit bugs" is not a flex. It means you never operated anything at a scale where things break.
- Prep it like system design: three bugs, five beats each. Symptom, wrong hypothesis, instrument, mechanism, guardrail.
What does "tell me about a bug you fixed" actually test?
It tests whether you have ever met production. Anyone can be taught to invert a tree. Nobody can be taught to remember a race condition they never chased at 2am.
A coding round hands you a problem someone else already reduced to a clean statement with a known answer. That is roughly zero percent of the job. The job is the opposite: an ugly symptom, no statement of the problem, no guarantee a bug even exists, and a cause that might be in someone else's code, a library, the network, or the clock.
Debugging is the only interview topic I know where you have to reconstruct a real chain of causation on the spot. You cannot ChatGPT a memory.
Why does a bug story predict on-the-job performance better than LeetCode?
Because the failure mode of a weak engineer at work is almost never "couldn't write the algorithm." It's "made the symptom go away and shipped it."
I have watched a very smart person fix a flaky test with a two-second sleep. I have watched another wrap a request handler in try/except and log the exception at DEBUG. Both would clear a medium coding screen without breaking a sweat. Neither ever found out why.
The bug question separates those people from the ones who chase it to the mechanism. That's the entire ballgame: the difference between a fix that holds and a bug that comes back in six weeks wearing a hat.
What separates a great bug story from a bad one?
Five beats. I listen for them in order, and I score each one independently.
1. The symptom, stated precisely. Weak: "the app was slow." Strong: "p99 on one endpoint went from 180ms to 4 seconds, but only between 9 and 10am, and only on two of six hosts." The second one already tells me this person looked at a dashboard and noticed the shape of the thing. Almost nobody fakes that precision well.
2. The wrong hypothesis they chased first. My favorite beat, and the one candidates skip because they think it makes them look bad. It does the opposite. "I was sure it was the database, spent half a day in query plans, and the plans were fine" tells me you form falsifiable guesses and let evidence kill them. A straight line from symptom to cause means you're either lying or you got lucky, and both are worth knowing.
3. The instrument. What did you actually look at? A flamegraph, a packet capture, strace, a heap dump, git bisect, one log line in exactly the right place, or a script that reproduced it 1 in 50 runs. Engineers who debug well have tools they reach for by reflex.
4. The mechanism. Can you explain the causal chain end to end, well enough that I could predict the bug's behavior in a case you didn't see? "The retry wrapper retried on 504, the payment endpoint wasn't idempotent, and the gateway returned 504 on a timeout after the charge succeeded, so slow charges got double-billed" is a mechanism. "It was a race condition" is a genre.
5. The guardrail. What did you change so this class of bug can't recur silently? An idempotency key, a regression test that fails without the fix, an alert on the metric that would have caught it a week earlier. This beat separates senior from mid. Mid fixes the bug. Senior closes the hole it came through.
Hit all five and I don't need much else. I've just watched you do the job.
What do weak answers sound like?
Four failure modes, in ascending order of concern.
The tourist. Tells a story about a bug someone else fixed, going vague exactly where it gets interesting. "And then the platform team figured out it was a DNS thing." Fine, but I learned nothing about you.
The symptom-killer. Reached a fix but never a cause. "I bumped the timeout to 30 seconds and it stopped happening." Sometimes that's the right call under pressure, and saying so is fine. Presenting it as the resolution tells me you'll leave landmines all over my codebase.
The pointer. The bug is always in the library, the framework, or the other team. Bugs genuinely do live in dependencies. But a candidate whose entire debugging autobiography is other people's fault will not survive their first incident review.
The blank. "I can't think of one." That's what got the eleven-minute LeetCode guy a no-hire. Not because he was lying, but because both readings are bad: he's never owned anything that broke, or he doesn't retain what breakage teaches. Debugging is the fastest way engineers get better. Someone with no bug memories has a career made of first drafts.
How should I answer "tell me about a bug you fixed" in an interview?
Prepare three bugs, not one. Interviewers steer, so you want coverage: one concurrency or timing bug, one data or state corruption bug, one performance or resource bug. If your work is mostly frontend, a cache-invalidation nightmare counts.
For each, write the five beats down and rehearse them out loud in ninety seconds. Symptom, wrong hypothesis, instrument, mechanism, guardrail. Then stop talking and let them ask.
Some specifics that pay off:
- Lead with the symptom, not the architecture. Nobody needs eight minutes on your service topology. Open with the weird observation.
- Keep the numbers. Latency figures, error rates, how many users, how long it took. Real numbers are the fingerprint of a real memory.
- Say the dumb thing you believed. "I blamed the network for a full day." It buys enormous credibility and it's the part interviewers remember.
- Don't sand off the mess. Bugs found by luck are normal. Say it was luck, then say what you changed so luck isn't required next time.
- Have an unfinished one. A bug you never fully root-caused, with your best theory and what you'd instrument next, shows how you think when the story has no ending.
One thing nobody tells candidates: a bug from a side project counts, as long as it's yours and you can explain the mechanism. I have given strong scores for a race condition in a Discord bot. Depth beats prestige.
Does this question still work now that candidates use AI?
Better than ever, honestly. An AI can write you a beautiful generic bug story in four seconds, and it will die on the second follow-up.
The follow-ups are trivial to ask and brutal to fake: What did the stack trace look like? Why didn't your tests catch it? What did you rule out before that? Why didn't it happen on staging?
Manufactured stories collapse there because they have no interior. Real ones have infinite detail, because you lived inside them for two days and you were annoyed the whole time. And plenty of debugging now happens with an AI assistant in the loop, which is fine to say out loud. "I pasted the trace in, it gave me three causes, two were wrong, the third pointed at the connection pool" is a legitimate answer. The tool changed. The reasoning I'm scoring didn't.
So what's the best tech interview question?
"Tell me about a bug you fixed" is the best tech interview question because it forces you to reconstruct real causal reasoning about a system you actually operated, and it can't be memorized, generated, or bluffed past two follow-ups. Great answers hit five beats: a precisely stated symptom, a wrong hypothesis abandoned when evidence killed it, the tool that revealed the truth, the full mechanism, and the guardrail that keeps the bug class from returning silently. Weak answers stop at making the symptom disappear. If you're interviewing soon, prepare three bug stories in that shape and rehearse each in ninety seconds. If you're the one asking, ask it last, then ask "what did you try before that?" three times and watch what happens.
Top comments (0)