The new interview format
Google, Meta, and others have redesigned engineering interviews around one question: can you read, debug, and improve code using AI as a tool? — because that's the actual job now. You're handed a codebase you didn't write and asked to understand it, find the bug, and fix it. Comprehension, not from-scratch algorithm puzzles.
How to read code you didn't write
- Start at the entry point / the failing behavior, not line 1. Follow the path that produces the observed output.
- Build a mental model of data flow — where does the input come from, how is it transformed, where does it go. Trace one concrete example through the code.
- Identify the contracts — function signatures, types, and what each piece promises. Types and tests are documentation.
- Read the tests — they show intended behavior and edge cases faster than the code does.
- Ignore what you don't need — you don't have to understand the whole system, just the slice relevant to the task. Zoom in.
- Form a hypothesis about the bug's location from the symptom before reading everything.
Reasoning about AI-era code
Modern code is full of LLM calls, async flows, retries, and state — the bugs live in the seams: a prompt that's assembled wrong, state that isn't persisted, an async race, an embedding computed inconsistently. Reading it well means understanding both the code and the LLM/data behavior it orchestrates (which is why the other courses matter here).
Verify your understanding
Before you change anything, confirm your mental model: can you predict what the code does for a given input? Can you point to the exact line that produces the wrong behavior? If not, you don't understand it yet — reading more (or adding a log/print) beats guessing at a fix.