Debugging Interviews: How to Show Your Process When the Bug Isn't Yours

More companies now replace or supplement algorithm puzzles with debugging rounds. You get an unfamiliar codebase, a failing test or a bug report, and 45 minutes. These rounds reward a calm, methodical process far more than raw speed, which is good news if you prepare for them deliberately. Read before you touch anything Start by reading the bug report or failing test aloud and restating expected versus actual behaviour. Then skim the project structure: entry point, main modules, test folder. Tell the interviewer what you are doing: "I want a rough map before I dive in." This shows you work like an engineer joining a new team, not someone guessing. Reproduce first Run the failing test or reproduce the bug manually. If you cannot reproduce it, nothing else matters. Note the exact error, stack trace and inputs. Interviewers often score whether you confirmed the problem before attempting a fix. Form a hypothesis and say it "The total is off by one item, so I suspect the loop boundary in calculate_total or the filter that removes inactive items." Stating a hypothesis keeps you focused and gives the interviewer a chance to nudge you if you are far off. Narrow down with cheap experiments Add a print statement or breakpoint, check an intermediate value, or comment out a suspicious branch. Prefer quick, reversible experiments. Bisecting the problem space is faster than reading every line. Fix the cause, not the symptom When you find the issue, explain why it happened and whether it could appear elsewhere. A one-character fix plus "this same pattern exists in the refund path, so I'd check that too" is a strong signal. Add or update a test Finish by writing a test that would have caught the bug. Even a single assertion demonstrates that you think about regressions. Communicate when stuck If you hit a wall, summarise what you've ruled out. "It's not the parser, because the parsed object looks right; the issue appears after the discount step." That summary often unlocks the next idea. How to practise Clone a small open-source project, break something on purpose (or ask a friend to), and fix it under a timer while narrating. Some candidates also use Linkjob AI (https://linkjob.ai), which offers real-time help during live job interviews and technical interviews, to stay organised under pressure. The habit that matters most, though, is the loop: reproduce, hypothesise, test, fix, verify.