The “Fix This Codebase” Round: How to Prep for Repository Debugging Interviews

(updated on 10.15.2026)

You open the interview link expecting a blank editor and a classic array problem. Instead, the interviewer shares a repo. Twelve files. A failing test. A short note: “Users say the checkout total is sometimes wrong. Can you find out why and fix it?” Your stomach drops a little. Where do you even start?

Fear not. The “fix this codebase” round sounds scary, but it’s actually one of the fairest formats out there, because it looks a lot like a normal Tuesday at work. And it’s getting more common. AI coding assistants now write a big chunk of first-draft code, so more hiring teams care less about whether you can type a function from memory and more about whether you can read, question, and safely repair code you didn’t write. CoderPad’s State of Tech Hiring 2026 survey found that 21% of teams include code review tasks and 19% include debugging exercises in their technical tests or live coding interviews. Algorithmic questions are still the most common format (43%), so LeetCode isn’t dead. But the repo round is very real, and it rewards a different set of muscles.

In this guide we’ll cover what these rounds look like, what interviewers are actually scoring, a step-by-step way to navigate an unfamiliar repo, how to narrate your bug hunt out loud, how to write a fix that won’t scare a reviewer, and a two-week practice plan. Let’s dive in!

What a “Fix This Codebase” Round Actually Looks Like

The names vary: “practical coding,” “debugging round,” “code review exercise,” “working in an existing codebase.” The shape is usually similar:

A small but realistic repo. A tiny API service, data pipeline, React app, or CLI tool, with multiple files and real imports.
A bug report or failing test. Sometimes precise (“test_discount_applies_once fails”), sometimes vague (“totals are sometimes off”).
A time box. Usually 45 to 90 minutes, live with an interviewer, or occasionally async.
Follow-ups. “How would you test this?” “What else could break?” “Would you ship this on a Friday?”

Some versions flip it into a code review round: you get a pull request and leave review comments instead. Same skills, different seat.

If the company allows AI tools in the round, you’ll want to pair this post with our guide to AI-allowed coding interviews. Here we focus on what stays the same either way: you, a repo, and a bug.

What Interviewers Are Really Scoring

Here’s the good news: almost nobody expects you to find the bug in five minutes. What they’re watching is your process. Most rubrics boil down to these five signals:

Orientation. Can you get your bearings in a codebase you’ve never seen without panicking or reading every line?
Hypothesis-driven debugging. Do you form a guess, test it, and update, or do you poke randomly and hope?
Communication. Can the interviewer follow your thinking without asking “what are you doing right now?”
Fix quality. Is your change small, targeted, and safe, or did you rewrite half a module because you didn’t like the style?
Verification. Do you prove the fix works with a test, and think about what else it could break?

Notice what’s not on the list: memorizing obscure algorithms. Plenty of candidates who freeze on LeetCode shine here.

Step 1: Get Oriented in the First 10 Minutes

Resist the urge to scroll the biggest file top to bottom. Build a quick mental map instead:

Read the README. How do you run the app and the tests?
Run the tests before touching anything. You want a baseline. Which tests fail? Which pass? Is the failure even reproducible?
Scan the folder structure. Where’s the entry point? Where are the models, the handlers, the utilities? Say it out loud: “Looks like requests come in here, business logic lives in services/, and the data layer is in repo/.”
Find the code path for the bug. Start from the symptom (the failing test, the endpoint, the UI action) and trace inward. Use search: function names, error strings, the field that’s wrong.
Ignore what doesn’t matter. Out loud: “I’m going to skip the auth middleware for now, it doesn’t seem related to totals.”

That last one is underrated. Choosing what not to read is exactly what senior engineers do.

Step 2: Reproduce, Then Hypothesize

The single most common mistake in debugging rounds? Jumping straight to a fix before confirming the bug. Don’t. Reproduce it first, then narrow it down.

Reproduce. Run the failing test, or write a tiny one that shows the bug. “I can reproduce it: with two discount codes, the total drops twice.”
Hypothesize. Name one or two specific guesses. “My guess is the discount is applied both in cart.py and again in checkout.py.”
Test the hypothesis cheaply. Add a print or log, set a breakpoint, or check a single value. One experiment, one answer.
Update out loud. “Nope, it’s only applied once. So it’s not double-application. Let me check rounding next.”

Being wrong on your first guess is fine. Being wrong silently is what hurts.

Step 3: Narrate the Bug Hunt (Without Rambling)

Narration is half the score in a live repo round, and it’s a skill you can practice. You’re aiming for the voice of a calm teammate on a pairing call, not a nervous play-by-play. Here’s what that sounds like:

“I’ll start by running the test suite so I know what’s failing. Okay, one failure: test_total_with_two_discounts. Expected 80, got 72. That’s a difference of 8, which is suspiciously close to 10% of 80. So my first hypothesis is that a percentage discount is being applied to an already-discounted total instead of the original subtotal. Let me open pricing.py and check the order of operations…”

Yaay! Clear, specific, easy to follow. Habits that help:

Say what you’re about to do, then do it. “Next I’ll check where apply_discount is called.”
Summarize every few minutes. “So far: not a data issue, not double-application, likely ordering.”
Ask real clarifying questions. “Is the expected behavior that discounts stack on the original price, or compound?” That’s not stalling; it’s exactly the question you’d ask a product manager.
Narrate decisions, not keystrokes.

If you’ve read our post on how interviewers spot AI-polished behavioral answers, the same principle applies here: real thinking sounds a little messy and specific. Scripted lines sound smooth and empty. Practice until your narration feels natural, not memorized.

Step 4: Write a Safe Fix

You found it. Now slow down, because how you fix it matters as much as finding it.

Keep the change minimal. Fix the root cause in the smallest reasonable diff. If you see other ugly code, mention it (“I’d flag this function for a later cleanup”) but don’t refactor it now.
Match the codebase’s style. If the repo uses a certain error-handling pattern or naming convention, follow it, even if you’d do it differently at home.
Fix the cause, not the symptom. Hard-coding the expected value to make the test pass is the fastest way to fail the round. Interviewers check for this.
Write or update a test. Add a test that would have caught this bug. Then run the full suite to make sure you didn’t break anything else.
Talk about the blast radius. “This function is also called from the refunds flow, so I checked that path too, and the refund tests still pass.”

Thinking about who else depends on the code you just changed is a senior-level habit, and interviewers notice it.

Step 5: Close Strong With a Mini Wrap-Up

When you’re done (or when time is nearly up), give a 30-second summary like you’d write in a pull request description:

“The bug was in pricing.py: the percentage discount was calculated on the running total instead of the original subtotal, so stacked discounts compounded. I changed it to use the subtotal, added a test for two stacked discounts, and the full suite passes. With more time, I’d check whether tax has the same pattern.”

Didn’t finish? Don’t panic. A clear wrap-up of where you got to, what you ruled out, and what you’d try next is still a solid signal.

The Code Review Variant: How to Leave Comments That Impress

If you get a pull request instead of a bug, strong review comments are:

Prioritized. Lead with correctness and security issues, then performance, then readability. Don’t bury a real bug under ten naming nitpicks.
Specific. “This query runs inside the loop, so it’s N+1 for large carts. Could we batch it?” beats “performance could be better.”
Kind and collaborative. Phrase things as questions or suggestions.
Test-aware. Point out missing edge-case tests. Easy win, often skipped.

This variant shows up a lot in AI-heavy loops, because reviewing generated code is now a daily task. Our breakdown of Microsoft’s Copilot-assisted coding round goes deeper on catching bad suggestions, which is basically code review at speed.

How This Fits With Take-Homes and Onsites

Some companies send the repo as an async task instead of a live round. If that’s your situation, the rules about tools and documentation matter a lot, so check our guide on take-home assignments and when AI help is fair game. Leave a short README note on your reasoning; you’ll likely walk through it later.

If part of your loop is in person, the debugging conversation may happen on a laptop in a room instead of a shared screen. Our post on prepping when a round is onsite again has practical tips for that.

Pro Tip: Ask your recruiter directly: “Will any round involve working in an existing codebase or reviewing code? Which language and tools should I expect?” Knowing the format changes how you practice.

A Two-Week Practice Plan

You can’t memorize your way into this round, but you can train for it:

Week 1: Build Your Orientation Muscle

Days 1–2: Clone two or three small open-source projects in your interview language. For each, give yourself 15 minutes to answer: How do I run it? How do I run the tests? Where does a request or command flow?
Days 3–4: Pick “good first issue” bugs from those repos. Just practice reproducing and locating the bug, out loud, with a timer.
Days 5–7: Practice the narration loop: hypothesis, experiment, update. Record yourself once; you’ll instantly hear where you go silent or ramble.

Week 2: Simulate the Real Thing

Days 8–9: Ask a friend to plant a bug in one of your own old projects (off-by-one, wrong default value, swapped arguments, a missing await). Find it in under 45 minutes while narrating.
Days 10–11: Do two code review drills. Take a real merged pull request from an open-source project, hide the review comments, and write your own. Then compare.
Days 12–13: Run full 60-minute mock rounds: unfamiliar repo, bug report, fix, test, wrap-up. Get feedback on clarity too.
Day 14: Rest, review your notes, and prepare two or three clarifying questions you’ll ask in the real round.

Keep a few classic algorithm problems in the mix too. Most loops still combine formats.

Bonus Tip: As you know, at Interviewjoy we work with professionals who’ve been through these loops at big tech companies. If you want company-specific question lists, real interview experiences, and sample answers, check out our top-selling Interview Guides. They come with a full refund guarantee if they don’t help you.

Final Thoughts

Today we covered what the “fix this codebase” round looks like, what interviewers score, how to orient, reproduce, fix, and narrate, and a two-week practice plan. The big idea is simple: show them how you think in a real codebase, calmly and out loud, and leave the code safer than you found it.

We hope you enjoyed this article. And if you want to walk into your next loop with company-specific prep, don’t forget to check out our Interview Guides.

See you in the next article! Good luck!