Telling a debugging story in an interview

This is a behavioural question with a technical core. The interviewer wants to know whether you investigate methodically or guess, whether you measure, whether you understand the mechanism you found, and whether you made sure it did not come back. They will interrupt with follow-ups, so every claim in your story should be one you can go one level deeper on.

1. The symptom, concretely: what was slow, how you knew, how big, how often, and why it mattered. "p99 of order acknowledgement handling went from 6 to 40 µs after a release, on busy days only."
2. Measurement first. What you measured to locate it, and what it showed. "Stage timestamps showed the time was in the risk check; off-CPU profiling showed threads blocked in a mutex."
3. A hypothesis with a mechanism. "The new position report took the risk lock and formatted a report under it."
4. A test of the hypothesis, ideally one that predicted a number. "If that was it, lock wait time at the risk call site should match the report's duration and occur only when reports ran. It did."
5. The fix and its trade-off. "We took a snapshot of positions under the lock and formatted outside it. It cost a copy of a few kilobytes per report."
6. Verification: the same measurement that found it, now healthy. "p99 back to 6 µs; wait time at that site near zero."
7. Prevention: what changed so it would not recur. "A test that fails if any lock on the order path is held longer than a threshold, and the hold-time histogram on the dashboard."

Weak: "The system was slow, so I profiled it, found a hot function and optimised it, and it was three times faster." No numbers you can defend, no mechanism, no explanation of why the profile pointed there, and the interviewer's first follow-up ("what made it hot?") has no answer.

Strong stories have a few features in common:

• Numbers with units and percentiles, and how they were measured.
• At least one wrong hypothesis, and how evidence ruled it out. Real investigations have them, and saying so is more credible than a straight line.
• A mechanism at the right level: cache misses because of a layout, contention because of a hold time, faults because of lazy allocation.
• Your role, clearly: what you did versus what the team did.

Use one from anywhere: a slow web service, a batch job, a game, a university project, a benchmark you investigated out of curiosity. The method is what is being tested. A small problem told with real measurements beats a large one told vaguely. If you truly have none, investigate something now: take a program, profile it, find a cause, fix it, and tell that story honestly as a self-directed investigation.

Write the story down in the seven steps, with the numbers. Then list the follow-ups an interviewer could ask at each step and make sure you can answer them: how the tool works, why the mechanism costs what it does, what else you considered, what you would do differently now. Rehearse it aloud to about three minutes, leaving room for questions.