The debugging round
Not every interview round starts from a blank editor. Some hand you an existing codebase with a failing test and ask you to find out why. You are debugging, not building from scratch: reading code you did not write, forming a hypothesis, and checking it before you touch anything.
It is a round that is hard to fake, and hard to practice with a plain problem set, since those start from nothing. CodeSparring's debugging rounds start from a real, broken codebase with a failing test, and a verified pack runs your code against the actual test suite, not a guess at whether your fix looks right.
What the round tests
- Reading unfamiliar code: how fast you can orient yourself in a file you did not write.
- Forming a hypothesis: stating what you think is wrong before you start changing things.
- Verifying it: running the failing test and checking your fix against the real suite, not assuming it worked.
- Not breaking the rest: a fix that passes the one test you were shown but breaks another is not a fix.
How a session runs
You get an editor with a real, multi-file project and a test that is failing. An AI interviewer, playing the role of a teammate, asks what you think is going on before you start editing. Code execution happens in your browser: Python runs on Pyodide, JavaScript and TypeScript run sandboxed, and you see the actual stack trace when a test fails.
State your hypothesis before you touch the code, something like: "the pagination logic looks off by one, I want to log the index here to check." Say it out loud or type it, then verify it by running the test. See both the bug-fix and case lab formats on the rounds page, or go deeper with case labs, longer engineering scenarios modeled on real company work.