The Live Debugging Round: How to Prep for the Interview Everyone Forgets

You expected to write an algorithm from scratch. Instead, the interviewer hands you a small app that's already written - and broken. "It's supposed to do X, but it's doing Y. Find the bug and fix it."

This is the live debugging round, and it's spreading fast because it's the interview that looks most like the actual job. You almost never write greenfield code from a blank file at work. You almost always debug code that exists. Companies figured this out, and now they test for it - while candidates still spend 100% of their prep on LeetCode and 0% on debugging.

That gap is your opportunity.

Why Debugging Is Its Own Skill

Writing code and fixing code are different muscles. Writing is generative; debugging is investigative. It rewards a systematic process, not a flash of cleverness - which is good news, because process is learnable.

Interviewers use this round to see things a from-scratch problem hides:

• Can you read and understand code you didn't write?
• Do you debug systematically, or flail randomly changing things?
• Can you form a hypothesis and test it, rather than guessing?
• How do you handle the frustration of a bug that won't reveal itself?
• Do you verify your fix, or declare victory and move on?

The candidate who calmly narrates a method beats the genius who randomly mutates lines until the test goes green.

The Systematic Method

The whole game is having a process and visibly following it. Here's one that works under pressure.

1. Reproduce the bug.
Before anything, see it fail with your own eyes. Run the code, trigger the broken behavior, observe the actual vs expected output. You can't fix what you can't reproduce. Narrate: "First I want to reproduce this - let me run it and see the failure."

2. Read and understand the relevant code.
Don't dive into edits. Trace the path the broken behavior takes through the code. Build a mental model of how it's supposed to work. Often the bug becomes obvious just from reading carefully.

3. Form a hypothesis.
Based on the symptom, where could the cause be? State it out loud: "The output is off by one, which makes me suspect a loop boundary or an index. Let me check the loop in this function." A hypothesis turns random poking into a targeted search.

4. Test the hypothesis - narrow it down.
Confirm or kill your guess. Add a print/log, set a breakpoint, inspect a variable, or use binary search - comment out half, see if the bug persists, narrow the region. This is the core loop: hypothesize, test, narrow, repeat. Each cycle shrinks the search space.

5. Fix the root cause, not the symptom.
When you find it, fix the actual cause - not a band-aid that hides it. If a value is null, don't just add a null check; ask why it's null. Interviewers notice the difference between patching a symptom and fixing the root.

6. Verify the fix.
Re-run. Confirm the bug is gone and you didn't break anything else. Check the edge cases around the fix. "Let me re-run the failing case, and also the cases nearby to make sure I didn't regress anything." Verification is part of the grade - declaring victory without re-running is a classic miss.

Think Out Loud - It's Half the Grade

Like every modern coding round, this is a thinking-out-loud exercise. The interviewer is grading your method, and they can only see it if you narrate it.

Say what you're doing and why at each step:

• "The symptom is X, so my first guess is the bug lives around Y."
• "Let me add a log here to confirm the value at this point."
• "That's not it - the value's correct here, so the problem is downstream. Moving on."
• "Found it - this comparison uses = where it should be ==. Let me fix and re-run."

Silent debugging, even successful debugging, scores poorly. They want to hire someone who can debug with a team, which means out loud.

Use the Tools - You're Allowed To

In a real debugging round, you usually have a real environment. Use it like you would at work:

• Run the code constantly - debugging blind is slower
• Use a debugger or print statements - whichever you're fluent in; fluency itself is a signal
• Read the error messages and stack traces carefully - they often point straight at the bug, and ignoring them is a tell
• Check the docs if an unfamiliar API is involved

Pretending you can spot every bug by staring is not the flex. Methodically using your tools is.

The Bugs You'll Probably See

Debugging-round bugs cluster into recognizable types. Knowing the catalog speeds up your hypothesis step:

• Off-by-one errors - loop bounds, array indices, the classic
• Null / undefined handling - missing checks, unexpected empties
• Logic errors - wrong operator (&& vs ||), inverted condition, wrong comparison
• State / mutation bugs - shared mutable state, stale closures, mutating while iterating
• Async / race conditions - missing await, unhandled promise, ordering assumptions
• Type coercion - especially in JavaScript (== vs ===, "1" + 1)
• Edge cases - empty input, single element, boundaries the code didn't handle
• Integration bugs - wrong argument order, mismatched API contract

When you see the symptom, map it to the likely category. "Off by one in the output" → boundary/index. "Works sometimes, fails sometimes" → race condition or shared state.

When You Can't Find It

Sometimes the bug hides. How you handle being stuck is itself graded - composure here is a strong signal.

• Don't flail. Randomly changing lines until something works reads as panic. Stay systematic.
• Narrow harder. Binary-search the code. Isolate the smallest failing case. Add more observability.
• Question your assumptions. "I assumed this function returns sorted data - let me verify that." Wrong assumptions hide most stubborn bugs.
• Talk through it. "I've ruled out A and B, the value's correct until here, so it has to be in this region." This both helps you and shows the interviewer your reasoning - and they may nudge you.

How to Practice

This round is easy to prep for precisely because so few people do:

• Fix real bugs in open source. Grab a "good first issue," reproduce it, fix it. This is the exact skill.
• Debug your own old code intentionally - introduce bugs into a small project and hunt them under a timer.
• Learn your debugger cold - breakpoints, watch expressions, stepping. Fluency saves real time.
• Practice narrating - debug out loud, even alone, until the running commentary is natural.

A few hours of deliberate debugging practice puts you ahead of nearly every candidate, because nearly every candidate skips it entirely.

The live debugging round is the interview closest to the actual job, and the one with the least competition for prep. Reproduce, read, hypothesize, narrow, fix the root cause, verify - out loud the whole way. Master the method and broken code becomes the round you want to draw.

Want reps debugging real, broken code in a live environment with feedback on your method? gitGood's coding challenges and AI mock interviews let you practice the systematic, think-out-loud debugging that this round grades - so when they hand you a bug, you reach for a process instead of panic.