Codebase Orientation

Most AI-enabled coding interviews drop you into a multi-file project with existing classes, data models, and logic already in place. Understanding what you're looking at before you touch anything is the single most important thing you can do in the first few minutes. If you're in an open-ended interview starting from scratch, most of this doesn't apply — but the underlying skill of reading unfamiliar code quickly is worth developing regardless.

Why orientation comes first

Candidates who skip orientation and start prompting immediately make worse decisions for the rest of the interview. They ask the AI to implement something that conflicts with an existing pattern. They miss a helper class that already does what they're trying to build. They waste time debugging because they didn't understand the data model.

Interviewers notice. Jumping straight to prompting without reading signals that you'd do the same on a real team — start changing code you don't understand. That's not the impression you want to leave.

Understanding the project structure

Start with the big picture and work your way in. Build a mental map of how the pieces fit together, focusing on structure and relationships rather than line-by-line detail.

At a real company, a colleague helping you get up to speed will give you code pointers: specific files or functions that unlock how the whole system fits together. In an interview nobody gives you those — your job is to find them yourself. There are usually just a few key spots that, once understood, make everything else click.

Entry points

The first thing to find is where execution starts. If it's a web app, where do requests come in? If it's a CLI tool, where's the main function? Once you've found that, you can trace the flow of data through the system, and the rest of the codebase organizes itself in your head — which classes get instantiated, which methods get called, how pieces hand off work.

Key functions

Most codebases have a hard core: the complex function or method everything else is built around. Understanding how it's called, what it takes, and what it returns often teaches you more than reading a dozen simpler files. Look for the function that does the real work.

Class hierarchy and data models

From the entry point, map the class hierarchy and the data models. What are the core objects, and how do they relate? If there's a Game class that holds a Board containing Cell objects, understanding that hierarchy tells you a lot before you read a single method body.

Architectural patterns

Before reading individual files, list the whole tree — find . -type f — or browse the directory structure. A flat list of filenames tells you a surprising amount. An MVC app keeps models, views, and controllers in separate folders; a layered one splits presentation from business logic from data access; a modular one groups files by feature.

Notice whether there's clear separation of concerns. If the codebase keeps all database access behind a repository layer, you know not to scatter database calls directly in the controller — even when the AI suggests it. Working with the existing patterns rather than against them is one of the clearest signals of a strong candidate.

Public interfaces and encapsulation

Scan for what's public versus private on the key classes. If a Deck has a getCards() method, the AI needs to know to use it — not reach directly into the internal cards array. Don't assume the AI has the whole codebase in context. Knowing the interfaces across the classes and pointing the AI at them is your job.

Helpers on the data layer

Read the model files themselves, not just the shapes they declare. Data models frequently carry query helpers — findByUser, followersOf, a create wrapper that fills in defaults — and those helpers are the intended way to reach the data.

This matters because it's the most common way to lose a debugging problem. You write a raw query that looks equivalent, and it diverges in some small way the helper handled: normalizing a name before matching, populating a relation the caller expects, applying a default sort. Now you're debugging a problem you introduced, on top of the one you were sent to fix.

The AI will not find these for you. Asked to write a controller, it invents plausible database calls from the endpoint name — because it has never seen your models unless you pasted them in. Whatever abstraction the repo already has, treat it as the API.

State management

Where is state stored, and how does it change? Is there a single source of truth, or is state spread across multiple objects? Understanding this tells you where side effects happen and where bugs are most likely to hide.

Existing tests

If there are test files, read them. Tests are often the clearest documentation of what the code is supposed to do, and they give you a way to verify your understanding. Run them. If they all pass, the existing code works as expected. If any fail, that might be part of the problem you're supposed to solve. If the environment supports it, get a debugger running early — stepping through code is faster than reading it cold, and it instantly shows you the real data shapes.

Constraints and assumptions

Scan for comments or config files that hint at performance requirements or known limitations. A comment that says "this works for inputs up to 10,000" is a preview of the phase that asks you to handle a million.

Using AI to help you orient

AI is genuinely useful here — but the goal is to accelerate your understanding, not outsource it.

One of the best moves is to ask the AI to add detailed comments to each class and method in the codebase. This keeps you in the code rather than bouncing back and forth to a chat window. You read through the files naturally, with the explanations inline, and build your mental model as you go. It's faster than one-question-at-a-time chat, and it helps you notice connections between components.

Targeted questions also work well.

What does the GameBoard class do, and how does data flow from the API handler to the database? Answer briefly, referencing the actual class and method names.

Use the AI to explain syntax or patterns you don't recognize — decorators, generics, framework idioms. There's no shame in asking. The interviewer would rather see you use the AI to quickly understand unfamiliar syntax than watch you stare at it confused for two minutes.

Don't let anyone rush you

There's a natural pressure to start coding immediately. Resist it. Five to ten minutes spent reading the codebase will more than pay for itself during implementation, when your prompts reference actual class names and methods instead of vague descriptions. Interviewers expect it — jumping straight to prompting is one of the clearest failure signals they watch for.

Narrate what you're learning as you go. "I see the Board uses a 2D grid of Cell objects, and each cell tracks its own state and neighbors" is exactly the kind of thing that makes orientation feel productive rather than like dead air. And if you feel the pressure, it's completely fine to say:

I want to make sure I understand the codebase before I start making changes.