Reading a codebase you did not write

The defining skill of the AI-era engineer is building an accurate mental model of a codebase you've never seen — fast, and without reading every line. Whether you're joining a team, fixing a bug in an unfamiliar service, or reviewing code an AI generated, your speed and safety depend on comprehension, not typing. This is exactly what code-comprehension interviews measure: dropped into a real repo, can you orient and make a correct, surgical change?

Why this appears in interviews

Modern rounds hand you a substantial, unfamiliar codebase and a task ("this feature is broken — fix it") with a time limit. They're not testing whether you can memorize the repo; they're testing your method for navigating one you don't know: where you start, how you trace behavior, and how you avoid the trap of reading everything or rewriting blindly. A strong, repeatable approach is the differentiator.

The mindset: comprehend top-down, not line-by-line

Beginners open a random file and read from the top, trying to understand everything. Experts build a map first, then zoom in only where needed. You don't need to understand the whole system — you need to understand the slice relevant to your task well enough to change it safely. Reading is hypothesis-driven: "the bug is in how the response is parsed → find the parsing → confirm."

A method for orienting fast

1. Find the entry points. Where does execution start for the behavior you care about — the route/handler, the CLI command, the job, the UI event? main, the router, or the API layer is your door in.
2. Trace one real request end to end. Pick a single concrete flow ("what happens when a user asks a question?") and follow it: handler → service → the LLM/DB/external call → response. This one trace teaches you the architecture faster than reading ten files.
3. Map the boundaries. Identify where the code talks to the outside world — the database, the model API, third-party services, the queue. Bugs and the behavior you need to change usually live at these seams.
4. Read the data shapes. Types, schemas, and interfaces are the skeleton. Knowing the shape of the request, the config, and the response tells you more than the procedural glue between them.
5. Use the tools, don't just eyeball.
   • Search (grep/IDE) for a symbol, an error string, or a config key to jump straight to relevant code.
   • Types and "go to definition" to follow the real call graph instead of guessing.
   • The tests — they're executable documentation of intended behavior; a test for the broken feature often points at the bug.
   • Run it — logs, a breakpoint, or a print at the boundary reveal actual behavior faster than reading.
   • Git history / blame — "what changed recently near here?" is often the fastest path to a regression.
6. Form and confirm a hypothesis. State where you think the relevant logic is and verify by reading that, rather than drifting through unrelated files.

Using AI to read code (critically)

An AI assistant is a genuine accelerant here — if you direct and verify it:

• Ask for a map — "explain what this module does and how a request flows through it" gives you a fast orientation to confirm against the code.
• Ask targeted questions — "where is the model response parsed?" beats reading everything.
• Have it summarize a gnarly function, then check the summary against the source.

But validate: AI explanations of unfamiliar code can be confidently wrong, especially about edge cases and why something is done. Use it to generate hypotheses; confirm them in the actual code. Shipping a fix based on an unverified AI explanation is the classic trap.

Reading AI-powered code specifically

When the unfamiliar code contains an LLM feature, look for the AI-specific seams first, because that's where AI-era bugs hide: the prompt construction, the model/config (model name, temperature), the retrieval/embeddingEmbeddingNumerical representation of text capturing semantic meaning. Similar texts produce similar vectors, enabling similarity search.Learn more → step, the output parsing/validation, and the error/retry handling. A feature that "looks correct" often breaks at one of these — a bad prompt, a mismatched embeddingEmbeddingNumerical representation of text capturing semantic meaning. Similar texts produce similar vectors, enabling similarity search.Learn more → model, an unhandled malformed response.

A worked example

You're told a support assistant "returns irrelevant answers." Rather than read the whole repo: find the request handler (entry point) → trace to the retrieval call and the model call (boundaries) → check the data shapes (what's actually sent to the model) → hypothesis: "retrieval is returning bad chunks" → confirm by logging the retrieved chunks for a failing query. In minutes you've localized it to retrieval vs generation without reading unrelated code — and you can now fix the real cause.

Common interview mistakes

Mistake 1: Reading top-to-bottom. Trying to understand everything instead of tracing the one relevant flow.

Mistake 2: Not using search/tests/run. Eyeballing when a grep, a test, or a print would localize the code in seconds.

Mistake 3: Trusting an AI explanation unverified. Acting on a plausible summary without confirming it in the source.

Mistake 4: Rewriting instead of understanding. Reaching to rebuild an unfamiliar system rather than making a surgical, correct change.

Key vocabulary

• Entry point — Where execution begins for a behavior (route/handler/CLI/job); your door into an unfamiliar codebase.
• Tracing a request — Following one concrete flow end to end to learn the architecture fast.
• Boundaries / seams — Where code meets the DB, model API, and external services; where bugs and changes concentrate.
• Hypothesis-driven reading — Predicting where the relevant logic is and verifying, instead of reading everything.
• Executable documentation — Tests as the clearest statement of intended behavior.