Courses › AI-Assisted Coding › Round Types

Working in an Unfamiliar Codebase

A 10-minute orientation routine and using the assistant as a guide you verify.

The most common AI-assisted format is "here's a repo you've never seen; add this feature." The assistant can read files faster than you can, but your grade depends on whether *you* understand the codebase well enough to change it safely. This lesson is a 10-minute orientation routine, plus a way to use the assistant as a guide without handing it the steering wheel.

Minutes 0–3: establish a baseline

Before reading any code:

  • Read the task twice and write down the requirements and open questions.
  • Run the tests (and the app, if there is one). Now you know what "working" looks like, and whether anything was already failing before you started.
  • Look at the top level: the README, the dependency file (package.json, pyproject.toml), the folder layout and the entry points.

[!INTERVIEW] Say what you're doing "Before changing anything, I'm running the test suite to get a baseline. 23 pass and 1 is skipped, so if anything breaks later, I'll know it was me." It's a small step, and it signals real-world experience.

Minutes 3–10: build a mental map, with the assistant

Ask the assistant specific orientation questions, then check the answers yourself by opening the files it points to:

- "Give me a map of this repo: entry points, main modules, and how a request flows from the CLI to storage. Cite file paths."
- "Where is the closest existing feature to <the task>? List the files it touches."
- "How are errors handled and how are tests structured here? Show one representative example of each."

The second prompt is the most valuable. The best guide to adding a feature is the most similar feature that already exists. Trace it end to end: the entry point, validation, business logic, storage, tests. Your change will likely touch the same layers.

[!WARNING] Summaries can be confidently wrong Assistants sometimes describe files they haven't read, or mix up similar names. Treat a summary as a set of hypotheses. Open the two or three files that matter and confirm them yourself. Interviewers notice whether you check.

Note the conventions

Write down what your change has to match:

  • Naming, file layout, and where new code should go
  • Error handling: exceptions or return values, custom error types
  • Patterns for validation, logging and configuration
  • Test style: fixtures, the naming of test cases, how much is mocked

Then put those conventions into your prompts: "Follow the pattern in commands/add.py. Raise ValidationError from errors.py for bad input."

Plan the change

Write a short plan that lists the files you expect to touch and the order you'll change them in, starting with the data model and core logic. Share it with the interviewer before you write any code. If the assistant later proposes changes outside the plan, that's a cue to stop and think.

Make the change in thin slices

  • Start with a failing test that describes the new behavior, written by you or generated and then reviewed.
  • Make the smallest change that passes it, following the existing pattern.
  • Run the whole test suite to catch regressions.
  • Repeat for the next slice.

See A Winning Workflow for the full loop and Reviewing AI Code for what to check in each diff.

Watch for the codebase's traps

Interview repos often hide deliberate traps: a helper that's subtly different from the one you'd expect, a second place that also needs updating (a serializer, a registry, a migration), or a test that only passes because of shared state. Ask the assistant "what else references this function or field?" before changing a signature, and then check the answer with your own search.

[!TIP] Practice Extend an Unfamiliar Codebase with AI