"Read this codebase you've never seen"

New in Google's 2026 loop. Spreading to mid-cap. You're dropped into an unfamiliar repo (50–500 files, often an OSS slice) and asked to: explain what it does, find where X happens, modify Y safely. Tests whether you can navigate code you didn't write — the day-1-on-the-job skill LeetCode never measured.

What the round actually is, term by term

It's worth slowing down and naming every piece, because the words get thrown around as if they're obvious. The code comprehension round is an interview where the artifact already exists — you don't write much, you read. The interviewer drops you into a repository you have never opened and gives you tasks of three flavors: a describe task ("what does this service do?"), a locate task ("where does rate-limiting happen?"), and a modify task ("make deleted users return a 410 instead of a 404"). The thing being graded is not whether you memorized an algorithm; it's whether you can build an accurate mental model of unfamiliar code quickly and act on it without breaking things.

A few load-bearing terms, defined inline so the page stands on its own:

• Entry point — the line(s) where execution begins. For a web server it's wherever the app object is created and routes get registered (app.py, main.go, index.ts); for a CLI it's the main() the OS calls first. Everything else fans out from here, so it is the correct place to start a trace.
• Data flow — the path a piece of data travels as the program runs: where it enters (a request body, a CLI arg, a file), how it is transformed (validated, mapped, computed on), and where it finally lands (a database row, an HTTP response, a log line). Following the data, not the file names, is what reveals the real structure.
• Side effect — anything a function does besides returning a value: writing to a database, sending an email, mutating a shared variable, printing, calling another service. Side effects are where bugs and surprises live, so spotting them is half of comprehension.
• Mental model — your internal map of how the system is laid out and how the pieces talk to each other ("requests hit routes, routes call services, services call repos, repos touch the DB"). A correct mental model lets you predict where code should be before you go looking for it.
• Invariant — a rule the code assumes is always true ("a user always has an id," "the list is already sorted," "this is only called after auth"). Existing code is built on invariants; if your change quietly violates one, you create a bug that tests on your line might not catch. Reading for invariants is how you change code safely.
• Reading strategy: entry point → data flow → side effects. The whole method compresses to this arrow. Find where execution starts, follow how the data moves through it, and note what it touches on the way out. Do that for one path and you understand the system far better than someone who read ten files at random.

Why this round exists now — the AI angle

For two decades the gatekeeper was "can you produce code from scratch?" — LeetCode measured generation. But the daily job was never mostly generation; it was mostly reading: figuring out what the last engineer (or the last five) built before you dare touch it. The interview format lagged the job. Two forces finally closed the gap.

Put bluntly: in 2026 a huge share of the code you'll be responsible for will be machine-drafted, and your job is to understand it well enough to take ownership. This round is companies checking for exactly that. Treating AI as a teammate whose work you must read and vouch for — rather than an oracle whose word you take — is the mindset the round rewards.

The reason this order works is that each step shrinks the search space for the next. The README and config file (the package.json / pyproject.toml that lists dependencies, scripts, and the start command) tell you the technology and the entry point, so you no longer have to guess which file boots the app. The folder names tell you roughly where each responsibility lives, so when you trace one path you already half-expect where it goes next. The single end-to-end trace turns that rough guess into a concrete, verified mental model. Tests confirm the invariants — the behaviors the team promised to keep — and grep is your escape hatch the moment a name appears that the map didn't predict. Going inner-to-outer (opening a random deep file first) reverses this and leaves you with no frame to hang anything on.

Walkthrough: reading an unfamiliar function out loud

The micro-skill under all of this is reading one function you've never seen and being able to say three things about it: what it does, why it exists, and what edge cases it handles or misses. Here's a function you might hit in a "locate / modify" task. Read it the way an interviewer wants to hear you read it.

def resolve_account(user_id, *, allow_archived=False):
    account = db.accounts.find_one(user_id)   # side effect: hits the DB
    if account is None:
        raise NotFound(f"no account for {user_id}")
    if account.archived and not allow_archived:
        raise Gone(f"account {user_id} is archived")
    return account

Now the narration, in the exact order the reading strategy prescribes:

• Entry point / inputs first. "It takes a user_id and a keyword-only flag allow_archived that defaults to False. The * forces callers to pass that flag by name, so a stray positional argument can't accidentally flip it on." Already I know the shape of the contract.
• Data flow. "It looks the account up by id, then returns it. So this is a lookup-with-guards: id in, account object out." That's the what.
• Side effects. "The one side effect is the DB read on line 2 — no writes, no email, no mutation. Calling it twice is harmless." Knowing it's read-only tells me a lot about whether it's safe to call from where I'm working.
• Why it exists. "It centralizes two policies in one place: missing accounts become a NotFound, and archived accounts become a Gone unless the caller explicitly opts in. So every route that needs an account gets consistent error behavior for free." That's the why — it's the rule-enforcer, not just a fetch.
• Edge cases. "It handles two: the not-found case and the archived case. The allow_archived escape hatch exists precisely so admin or restore flows can still reach archived accounts. What it does not do is validate that user_id is well-formed — a malformed id just becomes a miss and a NotFound." Naming what it skips is what separates a real read from a hand-wave.

Notice the invariant this function establishes for everyone downstream: if resolve_account returns, the account exists and is usable. That's why a "modify" task like "deleted users should 410 instead of 404" almost certainly belongs here — and you can locate the right spot in one read, without grepping the whole app, because you understood the function's job rather than just its lines. Before you'd reach for AI at all, you'd confirm by grepping resolve_account's call sites: if every route funnels through it, you change one place; if some routes hit the DB directly, you've just learned the codebase is inconsistent and you should ask which path is canonical.

What interviewers look for — and the pitfalls that sink people

The grader isn't tallying how many files you opened. They're listening for evidence that you build an accurate model and act on it carefully. Concretely, strong candidates do these things, and weak ones fall into the matching traps: