Extending Codebases
This module covers practical coding interviews where you're expected to extend a working codebase you haven't seen before. You may need to add a feature, improve performance, or finish an incomplete implementation. This format reflects how much engineering work begins with code someone else wrote, and Meta and many other companies use some version of it.
Usually you'll work on a toy project in a shared editor. Some startups use their production repository. In either case, spend time reading before you write.
How these rounds are evaluated
Meta publishes the dimensions its AI-enabled round is graded against, and they generalize well beyond Meta:
- Problem solving. Clarifying what's actually being asked and breaking it into pieces before writing anything.
- Code development and understanding. Navigating an unfamiliar structure and producing working code inside it.
- Technical communication. Explaining your reasoning as you go and collaborating with the interviewer rather than performing at them.
A fourth dimension is verification and debugging: using tests, handling edge cases, and catching regressions. See the debugging module for more.
You do not need to write the most code or arrive knowing the framework. You need to orient yourself in an unfamiliar system, make a scoped change, and show that the existing behavior still works.
Parsing the codebase is part of the test
When you receive the codebase, first work out what it already does. Treat this like your first week on a new team: identify the entry points, trace the relevant behavior, and learn where the project puts its business logic.
Start by separating boilerplate from the code that matters to the task. Most repositories contain plenty of setup and only a few relevant files. Find the data models and schemas, locate the business logic, and look for shared utilities you're expected to reuse or extend.
If AI is allowed, use it to map the repository, then confirm its claims against the code. Ask how a module works and check the named functions and files yourself. You still need to read the critical paths, because a confident but incorrect summary can send the rest of your implementation in the wrong direction.
Follow the patterns you find
If the stack is unfamiliar, follow the patterns already in the repository. Stripe's integration interview, for example, asks candidates to solve issues and implement features in a realistic codebase. Look for existing examples of API handlers, data access, error handling, and component structure, then mirror them in your change.
You do not need prior experience with every framework. Say what you can infer: "I haven't used this framework before, but this looks like the routing layer, so I'd expect the handler to live here."
How to use AI effectively
The course introduction described three levels of AI usage: research-only, limited context, and full use. Here's how to work within each one during an extension task.
Research prompts. You can look things up, but the codebase stays out of the chat. Ask about the framework's conventions rather than your specific task, and ask for tradeoffs so you get a decision to make rather than an answer to copy.
PseudocodeI'm working in a Django REST Framework codebase. What's the conventional place to put request validation — the serializer, the view, or middleware? Give me the tradeoffs rather than just the most common answer.
Limited context prompts. You can share code and get help, but you drive and you verify. The highest-value use here is comprehension, and the trick is to ask for the evidence alongside the summary so checking it is cheap.
PseudocodeHere are the files I think matter. In under 10 lines, tell me where an incoming order is validated, where it's persisted, and which file I'd change to add a new order type. Quote the specific function names you're basing that on so I can verify each one.
Full agentic prompts. When you're expected to delegate execution, use AI to research the repository, agree on a scoped plan, and implement the specification in steps you can review.
For large changes, break up the work into smaller steps that are easier to validate, and review changes using git diff directly or by having the agent explain the changes it is making.
PseudocodeAdd support for persisting user message drafts, following the exact pattern the existing pattern for API route handling in {filename}. Make the backend and frontend changes separately, and review the changes you're making with me at each step before moving on. Don't refactor anything outside of this scope.
Regression testing
An extension can work and still break an existing behavior. Before you edit anything, establish a baseline so you can recognize that regression.
Run the existing test suite if the harness is reliable, or create a smaller baseline check if it is not. Then make one small change, validate it, and repeat.
If you're using an AI agent, tell it to work in incremental steps, test as it goes, and check in with you between changes so you can validate each one. An agent that refactors half the repo in one shot is likely to introduce regressions or unintended changes.
Practice problems in this module
Each problem is a downloadable, multi-file codebase with a working harness, a candidate prompt, and tests.
Add per-client rate limiting and 429 responses to a running JSON API without changing the endpoints that already work.
Extend a working in-memory key-value store so keys expire, then bound it with least-recently-used eviction.
Add a similar-movies endpoint to an existing Django and React application, ranked by a specified similarity score.
As you work through them, distinguish boilerplate from critical code, confirm your mental model, and make small, validated changes. These are the same habits you'll need in the interview.