Why bug-fix rounds show up
Most of the code a working engineer touches already exists. You are reading a function someone else wrote, figuring out why it broke, and changing it without breaking something else. A bug-fix round tests that directly instead of asking you to write an algorithm from a blank file.
You get a codebase you have never seen, a failing test, and a description of what should happen. The job is to find the cause, explain it, and fix it while the interviewer watches.
A framework for the round
Do not start changing code the moment you spot the bug. Work through it in order.
- Reproduce it first. Run the code and trigger the bug yourself before you touch anything. Say out loud what you expected to happen and what actually happened.
- State your hypothesis before you go looking. "The array is coming back undefined, so I think the index is going out of bounds somewhere in this loop." A wrong hypothesis said out loud still counts as progress. A silent guess does not.
- Trace it, don't guess. Add a print statement or step through with a debugger and watch the actual values change. If you are editing code and rerunning it without a clear idea of what you are testing, stop and go back to tracing.
- Fix it, then check what else it touches. Make the smallest change that addresses the root cause, rerun the full test suite, and say which edge cases you checked before you call it done.
How to practice it
Grinding more algorithm problems does not train this skill, because there is no unfamiliar codebase to get lost in. You need a project you did not write, a failing test, and something at stake if you fix the wrong thing.
CodeSparring's debugging rounds drop you into a real codebase with a failing test and score how you diagnose and fix it, not just whether the test goes green afterward. See how a full round runs before you start one.