Multi-file debugging under pressure

Different from the snippet-debug round. You get a real repo with a failing test (or a user-reported bug) and 30–45 min. Tests root-cause reasoning across files, not just "find the typo." Common at Stripe, Datadog, Affirm, Anthropic FDE loops, plus most AI-startup trial days.

What this round actually is

Let's pin down the format precisely, because half of doing well is knowing what game you are playing. You are given a working project — often dozens of files, sometimes hundreds — and one concrete complaint: a unit test is red, an endpoint returns the wrong number, the app crashes on a particular input, a user filed a bug report. You did not write this code and you have never seen it before. You have well under an hour, you can usually run the code and run the tests, and you may have an editor, a terminal, and (increasingly) an AI assistant. The deliverable is a correct, minimal fix plus a sentence explaining the root cause — and, ideally, a test that locks it in.

A few terms worth defining up front, since they recur below:

• Repo / repository — the project folder tracked by version control. "Tracked" means every change to every file is recorded with an author, a timestamp, and a message.
• Stack trace — the printout an error produces showing the chain of function calls that led to the crash, innermost (where it blew up) usually at the bottom or top depending on the language, with file names and line numbers. It is a map straight to the scene.
• Reproduce / repro — to trigger the failure yourself, reliably, on demand. A "minimal repro" is the smallest input or command that still triggers it, with everything irrelevant stripped away.
• Root cause — the actual broken assumption, as opposed to the visible symptom. The symptom is where it hurts; the root cause is why.
• Regression test — a test you add that captures this specific bug, so that if anyone reintroduces it later, the test goes red and catches them.
• git blame — a Git command that, for each line of a file, shows the commit and author that last changed it. It answers "who wrote this line, when, and in what change?" — invaluable for understanding why a suspicious line exists.

Navigating a large repo you've never seen

The first instinct of a nervous candidate is to open the biggest file and start reading top to bottom. Do not. You will burn fifteen minutes and learn almost nothing, because a repo is not a novel — you do not need to understand all of it, only the thin slice that touches your bug. The professional move is to navigate by the failure, working backward from the symptom toward the code that produces it. A few orientation moves, in rough order:

• Read the entry points, not everything. Skim the README, the test that's failing, and the directory names. Folder structure (src/, api/, models/, tests/) tells you the shape of the system in thirty seconds.
• Let the error name the file. The stack trace already contains file paths and line numbers. That is the single best starting point in the whole repo — it is the repo telling you where to look.
• Search by symbol, not by reading. Pick a distinctive string from the error, the failing test, or the bug report — a function name, an error message, a field name — and grep for it across the repo. This jumps you straight to the relevant code and to every place that touches it.
• Follow the data, not the control flow. Ask "where does this wrong value come from?" and trace it upstream: who set it, who passed it in, who computed it. You are reverse-engineering a pipeline, one hop at a time.

grep / search strategy

"Grep" is the classic command-line tool for searching text across files; today it usually means any fast project-wide search (grep -rn, ripgrep/rg, or your editor's "search in all files"). It is your fastest way to convert "I have no idea where this lives" into "here are the four files that mention it." The art is choosing a search term that is specific — common words match everywhere and drown you; rare, distinctive strings land you on target.

# Search the whole repo, with line numbers, for a distinctive string
rg -n "User not found"        # the exact error text -> jumps to where it's raised
rg -n "def parse_amount"       # a function definition -> its one source of truth
rg -n "parse_amount"           # the function NAME -> every call site, too
rg -n "discount" src/billing    # scope the search to one folder when you can

Good search targets, in order of usefulness: the literal error message text (it is almost always a unique string in the code), then the failing test's name and any function it calls, then the name of the misbehaving field or variable. Searching the name of a function finds both where it is defined and everywhere it is called — that call-site list is how you map the blast radius of a change before you make it.

Reading the stack trace

A stack trace looks intimidating but it is a gift: it is a recorded path from the outside of your program down to the exact line that failed. Read it like a sentence. The type of error tells you the category of problem; the message tells you the specifics; the frames (each "called from here" line) tell you the route the program took to get there.

Traceback (most recent call last):
  File "app/api.py", line 42, in handle_request
    total = compute_total(cart)
  File "app/billing.py", line 17, in compute_total
    return sum(parse_amount(i) for i in items)
  File "app/billing.py", line 9, in parse_amount
    return float(raw["price"])
KeyError: 'price'          # <- the actual failure: a dict had no "price" key

In Python the bottom-most frame is where it actually blew up; the frames above it are the callers, oldest at the top. (Other languages print it inverted — newest on top — but the idea is identical.) Read three things: the last line (KeyError: 'price' — the what), the deepest frame (billing.py line 9 — the where), and the frame just above it (line 17 — who handed it the bad data). That last point matters: line 9 is the leaf, but the missing price key came from items, which came from cart up in handle_request. The trace is already pointing you up the data path toward the real cause.

Reproduce first — and minimize

This is the step beginners skip and seniors never do. Before you change a single character, get the failure to happen for you, reliably. If there is a failing test, run just that test (most frameworks let you run one by name) so you get a tight, fast feedback loop instead of re-running the whole suite. If it is a user-reported bug with no test, write the smallest script or input that triggers it. Why does this come first? Because a fix you cannot check is not a fix — it is a hope. The repro is the instrument that tells you, in seconds, whether you were right.

Then minimize the repro: strip away everything that is not needed to make it fail. A 200-line failing scenario with one bad value hidden inside is far harder to reason about than the same bug reduced to three lines. Minimizing is itself a debugging act — each thing you remove that doesn't stop the failure is a clue about what is and isn't involved.

# Run ONLY the failing test for a fast loop (pytest example)
pytest tests/test_billing.py::test_total_with_missing_price -x

# If there's no test yet, write the minimal repro by hand:
from app.billing import compute_total
print(compute_total([{"price": "5.00"}, {}]))   # the {} (no "price") is what breaks it

A concrete walkthrough: a bug in a repo you've never seen

Let's run the whole loop end to end on the example above. You are dropped into an unfamiliar billing service. The bug report: "Checkout sometimes crashes with a 500 error." You have never opened this code.

Now the layer question. The crash is at the leaf (parse_amount), but the real story is upstream: the loader started emitting free-gift items with no price, and downstream code never expected that. You name both fixes out loud:

• Symptom layer: make parse_amount treat a missing price as 0.00. Easy, but it silently hides whether a missing price is ever truly a bug.
• Right layer: decide the invariant. If free gifts legitimately cost 0, the loader should set price: "0.00" explicitly (or parse_amount should default to 0 by design, documented). If a missing price is a data error, it should fail loudly with a clear message, not crash with a raw KeyError.

# 5. Fix at the right layer: free gifts are valid and cost 0 by design.
def parse_amount(raw):
    # A missing price means a free item (e.g. a gift); treat as 0.00.
    return float(raw.get("price", "0.00"))

# 6. Lock it with a regression test that was RED before, GREEN after.
def test_total_treats_missing_price_as_free():
    assert compute_total([{"price": "5.00"}, {}]) == 5.00

Finally, verify: run the new test (it passes), re-run the original repro (no crash), and run the surrounding suite to confirm you broke nothing. Then deliver the one-sentence root cause: "A loader change introduced free-gift items with no price field, and parse_amount assumed the key always existed; I made the zero-price case explicit and added a regression test." That sentence is the round.

What interviewers look for

They are grading your process, not your speed. A candidate who narrates a clean loop and runs out of time mid-fix often scores higher than one who silently lands a fix by luck. Specifically, strong signal looks like:

• You reproduce before you touch anything. It is the clearest possible sign you debug by evidence, not by vibes.
• You narrate hypotheses and kill them with checks. "I think it's X — let me verify" followed by a targeted print is exactly the loop they want to hear.
• You name the root cause in one sentence. Pushing past the symptom to the broken assumption — and saying it plainly — is the top-graded moment.
• You fix at the right layer and explain the trade-off. Articulating both the symptom-layer patch and the root-layer fix shows judgment.
• You lock it with a test and scope-control. A red-before/green-after regression test plus "I'll file the unrelated issues as follow-ups" is textbook senior closure.

Pitfalls that sink the round

• Making random edits. Changing lines to "see if it helps" without a hypothesis is the single biggest red flag. Every change should be a test of a stated guess.
• Not reproducing first. Fixing blind means you can't tell whether your change did anything. You may "fix" the wrong thing and never know.
• Reading the whole repo. Trying to understand everything before acting burns the clock. Navigate by the failure; understand only the slice you need.
• Stopping at the symptom. A patch that makes the error disappear without explaining why it happened often just relocates the bug. Keep asking "but why?"
• Scope creep. Refactoring unrelated code or "cleaning up" while you're in there. Fix the bug; note the rest as follow-ups.
• Debugging in silence. The interviewer can't grade reasoning they can't hear. Think out loud, even when you're stuck — "I'm not sure yet, here's what I'd check next" is worth saying.
• Trusting an AI fix you can't explain. If you accept a suggestion you don't understand, you can't defend it or verify the layer. Use the assistant to generate hypotheses, then confirm each one yourself.