The round opens with about five minutes of orientation: reading the instructions, the tests and the code before you change anything. Then, if your round has a bug to fix, you find and fix the reported bug.
Getting oriented#
Spend the first ~5 minutes on orientation, and in this order.
1. Read the instructions fully#
Note the inputs, outputs, constraints, and exactly what the bug report says is wrong. The wording of the bug report usually points at the area to read first.
2. Run the tests once#
This gives you a baseline: which tests fail, which pass, and how the runner reports results. It's cheap, it tells you what's broken, and it gets the tooling sorted before you need it.
3. Read the code in a specific order#
Read the files in this order, not top to bottom.
- Tests first. They're the most honest spec you have. They show expected behavior, how the code is meant to be called, and which cases the author cared about.
- Data models next. Look at the classes and structures, what fields they hold, and what has to always be true about them (for example, "this list stays sorted" or "IDs are unique").
- The main flow. Follow one input from the entry point through the functions it passes through. Don't read every file top to bottom. Trace one path.
- Helpers last. Skim them, and only go deep on the ones the bug report or main flow touches.
4. Say your mental model out loud#
Describe what you've read in a few sentences, for example:
"There are three files. The model defines X, the solver does Y using Z, and the tests check W. The existing approach is a DFS, roughly O(V + E)."
Then ask the interviewer, "Does that match your understanding?" They'll often confirm or correct you, which saves you time and gives them early evidence that you can read code.
5. Note suspicious spots, but don't fix anything yet#
If something looks off while you're reading, jot it down and keep going. You don't know the full picture yet, and a fix made too early can be wrong.
How to use the AI during orientation#
Asking it to describe structure is fine. Something like:
"Summarize what each file does and how they call each other. Don't evaluate correctness."
Then skim the code to confirm what it said, because summaries can be wrong. Don't ask "where's the bug?" A restricted assistant may refuse, and finding the bug yourself is the signal the interviewer is looking for.
Common mistakes during orientation#
Three habits waste the opening minutes.
- Editing in the first minute. You don't understand the code yet.
- Reading every line of every file. You run out of time, and most of it isn't relevant.
- Trusting the AI summary without checking. You build on a wrong mental model.
The debugging method#
Work in five steps, and say each one out loud as you go.
1. Reproduce#
Find the failing test, or build the smallest input that shows the problem. Read the failure closely, because how the expected and actual results differ is your first clue.
| Symptom | Likely causes |
|---|---|
| Off by one value or count | Loop bounds, < vs <=, wrong starting index |
| Duplicates, endless loop, timeout on a small input | Missing visited set, state not reset, a loop condition that never ends |
| Right items, wrong order | Sort key, comparator, tie-breaking |
| Fails only on certain inputs | Edge cases: empty, a single element, ties, negatives, duplicates |
TypeError, None-related crash |
A wrong type or cast, a missing return, an unhandled None |
| First call right, second call wrong | Shared or mutable state, a stale cache, a mutable default argument |
2. Form a hypothesis#
Name one or two likely causes before you touch the code. For example: "Expected 4, got 5, one extra, so I suspect a boundary." This keeps you from making random changes, and it shows the interviewer you're reasoning instead of guessing.
3. Trace#
Follow the failing input through the code until you find the line. Use a print statement or work a tiny input by hand. If the path is long, narrow it down like a binary search: check an intermediate value halfway through. If it's already wrong there, the bug is earlier; if it's right, the bug is later.
4. Make the minimal fix#
Change the smallest thing that addresses the cause, and don't refactor. Explain why that line caused the symptom, not just that the test passes now. A fix you can't explain might only be hiding the bug.
5. Verify#
Don't stop at the one test going green.
- Rerun the failing test.
- Rerun the full suite, to confirm you didn't break anything else.
- Add a regression test if the case wasn't already covered.
- Check for the same mistake elsewhere. If one loop had the off-by-one, look at similar loops nearby.
How to use the AI while debugging#
Good questions are things like:
- "What does this function return for input X?"
- "What does this library call do with an empty list?"
- "Write a test for the case where Y."
Avoid "Find the bug." If you're stuck for more than ~5 minutes, ask a focused question built on your hypothesis:
"I think the problem is in
update_state. Walk me through what happens tovisitedwhen it backtracks."
That's still you driving, and the interviewer can see that in the chat.
Narration#
Narration sounds like:
"The test expects 4 and gets 5. One extra, so I'm checking the loop bounds… the range includes the end index, and that's the extra iteration."