Why this is a bigger deal than Meta's change
Meta moved first, in October 2025, and the industry followed. But Meta's round is still a build: you get a small repo, fix a bug, implement a feature, optimize it. The assistant makes you faster at producing code. Google's round starts from a different premise. The code already exists. Your job is to understand it well enough to say what is wrong with it.
That premise matches what Google's engineers actually do all day. A week before the pilot leaked, Sundar Pichai wrote that 75% of new code at Google is now generated by AI and approved by engineers, up from 50% the previous fall. When three quarters of the code is written by a model, the job of the human is reading, judging and catching mistakes. An interview that tests whether you can produce a merge-sort from memory measures the quarter of the job that is shrinking. Google's VP of recruiting put the motive plainly:
"We're always evolving our interview processes to ensure we're recruiting and hiring the best talent, and we're rolling out a pilot for software engineering interviews to be more reflective of how our teams are operating in the AI era."Brian Ong, VP of Recruiting, Google, to Business Insider, May 2026
Our take: this is the version of the AI-assisted interview that will age best. Build rounds get easier every time the models improve, so the bar has to keep moving. Reading an unfamiliar codebase and deciding what is actually broken does not get easier with a better model, because the model will happily explain code it has misread with total confidence. The candidate who can tell the difference is the one Google wants.
What is confirmed, and what is fan fiction
Most of what you will read about this round online is invented. The confirmed facts come from the internal document Business Insider reported on and Google's statement about it:
- It is called the code comprehension round. Candidates review an existing codebase, identify issues, debug and suggest improvements. Gemini is available as part of the process.
- Interviewers evaluate AI fluency, which Google spells out as prompt engineering, output validation and debugging. The internal framing is "human-led, AI-assisted".
- It is a pilot, launched for junior and mid-level roles on select US teams, starting with Google Cloud and Platforms and Devices. It replaces one traditional coding round.
- Two more changes ride along. The Googleyness and Leadership round gains a technical design conversation about the candidate's past work. For early-career candidates, one traditional technical interview becomes an open-ended engineering problem.
One recruiter's description of a senior loop adds some detail. A candidate for an L5 role on YouTube Ads posted it before their interview. In it, round 1 has two parts. The first, "Technical Communication & Collaboration", is a deep discussion of one past project with no slides: design choices, trade-offs, ambiguity, the AI tools used, how the team worked together. That part looks like the Googleyness change. The second is "AI-assisted Code Comprehension" in CoderPad, where you debug, extend and optimize a given codebase with an AI assistant. It is one description of the format, not an account of the interview itself. Still, it places the round in a senior loop, on a team the May report did not name.
Now the fan fiction. "60 minutes, CoderPad, three panels, three phases: bug fix, implementation, optimization." That sentence appears word for word on a dozen prep sites, with no Google source, and it is Meta's format. Part of it is right: the recruiter description above names CoderPad and a debug, extend, optimize arc. Nobody has sourced the timing or the panels. The few candidate reports of the round itself describe something looser: a real codebase with several things wrong in it, an interviewer who wants to hear how you are deciding what to look at, and improvement suggestions that are judged on reasoning more than on completeness. Plan for an hour in CoderPad and for the difficulty to climb from fixing to extending to optimizing. Do not rehearse a script.
What "code comprehension" means when you are in the chair
Strip the branding and the round is three questions asked in sequence about code you have never seen.
What does this code do?
Several modules, some of which call into each other. The first ten minutes decide the interview. Candidates who start at the entry point and follow the calls build a map; candidates who start by asking Gemini "what does this project do" get a plausible summary that is wrong in one important detail, and they do not find out until they have built a fix on top of it. Ask the model for facts you can verify ("where is this value written?"), not for the gist.
What is wrong with it?
The bugs that make good interview material are not typos. They are places where one module assumes something another module does not guarantee: a cache that forgets what its key was supposed to cover, a walk that never cleans up after itself, a check that compares the wrong thing. You find them by reading two files and noticing they disagree. Gemini can read both files for you, but it will not notice the disagreement unless you ask the question that exposes it.
How would you make it better?
Usually performance, sometimes robustness, sometimes a small feature. This is where output validation gets graded hardest. The model will propose an optimization. It will probably be the obvious one. Whether it is correct depends on a property of the codebase you had to read to know about, and the interviewer wants to see you check that property before you accept the patch, not after the tests go red.
What they are grading
- Code reading. Can you orient in a codebase you did not write, fast, and say with confidence which parts matter for the question at hand.
- Debugging. Not whether you found the bug, but how: hypothesis, evidence, narrowing. A candidate who finds the bug by asking Gemini to "fix the failing test" and accepting the result has shown nothing about this competency.
- Prompt engineering. Google lists it first, and we think people misread it. It does not mean clever prompts. It means giving the model tasks that are small, concrete and checkable, because that is what makes its output useful under time pressure.
- Output validation. The one that separates candidates. Every answer from the model is a claim. Did you check it against the code? Did you run something? Did you catch the case where the model was confidently wrong? There will be such a case. Interviewers who design these rounds make sure of it.
How we would prepare
Most advice for this round is recycled LeetCode advice with "and use Gemini" appended. Here is what actually moves the needle.
- Read code every day for the two weeks before. Pick a small open-source project in your language, two to five hundred lines, and make yourself explain how a request flows through it before touching anything. Time yourself. Ten minutes to a correct map of an unfamiliar repo is the skill.
- Practice on codebases with planted bugs, not on problems with empty functions. The failure mode in this round is a fix that passes the visible test and breaks a contract in another file. You only learn to feel that coming by hitting it.
- Direct the model; do not consult it. "Read
digest.pyand tell me every input that goes into the cache key" is a good prompt. "What's wrong with this code" is a bad one, because the answer sounds right whether or not it is. - Build the verification reflex until it is boring.The model proposes, you read, you name the claim, you run the one check that would expose it if it were wrong. Every time. The habit has to survive the clock.
- Practice with Gemini. Google named it for the pilot, and no report names another model. Learn how it quotes code, where it hedges, and how it behaves when you ask for something that is not there.
Nyrion's problems are built for this. Each one is a small multi-file codebase with real bugs in it, an assistant in the editor that implements what you tell it and offers no ideas of its own, tests that gate progression, and interviewer questions after each stage that make you explain what you just did. The Google section of the catalog starts with Incremental Build System: six modules, a shared dependency that gets reported as a cycle, a cache that goes stale for two different reasons in two different files, and an optimization that only works if you understood why the cache went stale. It is the closest thing to this round that you can run at home.
How this round compares with other companies' versions, and what every version grades: the AI coding interview guide.
Frequently asked, briefly answered
Does this apply to me?
Most likely, if you are interviewing for a junior or mid-level software engineering role on a participating US team. That is where the pilot started, with Google Cloud and Platforms and Devices first. It is not limited to those levels. One candidate's recruiter described the round as part of an L5 loop on YouTube Ads. That is a single report, so ask your recruiter what your loop includes. Google has said it will expand the format if the pilot works, and nothing about the pilot reads as tentative.
Can I use my own AI tool?
Not that anyone has reported. Google said Gemini is the assistant candidates use during the pilot. One recruiter's description, from an L5 loop, names no model and says just "an AI assistant", so ask your recruiter which one. If you spend your days in Claude or Cursor, budget a few hours getting used to how Gemini reads code and how it answers when you ask it to find something in a file. The model is not the hard part, but an unfamiliar model on interview day is a self-inflicted handicap.
Is the classic algorithm round gone?
No. The code comprehension round replaces one traditional coding round, not both. You still face a round where it is you, a whiteboard-style problem and no assistant, and the system design round is unchanged. Keep the algorithm practice; just spend less of your time on it.
Is it 60 minutes with three phases in CoderPad?
Partly. Prep blogs say so without a source, and the full claim is Meta's format with the logo swapped. One recruiter's description from an L5 loop does name CoderPad. It says to "debug, extend, and optimize" a given codebase with an AI assistant, which is close to three phases. It is one description, and it says nothing about timing. Google's own statement is broader: candidates review an existing codebase, identify issues, debug and suggest improvements with Gemini available. Plan for about an hour in CoderPad and for the work to escalate from fixing to extending to optimizing, but do not rehearse a script.
Should I use Gemini a lot or a little?
Use it for what it is good at: locating things in code you have not read, explaining an unfamiliar construct, drafting a fix you have already specified. Do not use it to decide what is wrong. Google grades output validation explicitly, which means every answer the model gives you is a claim you are expected to check. A candidate who pastes a Gemini explanation without verifying it has handed the interviewer the exact failure they are looking for.
What about the other two changes?
The Googleyness and Leadership round now includes a technical design conversation about work you have actually done, so be ready to walk through a real decision, the alternatives you rejected and why. One recruiter's description, from an L5 loop, has a part that looks like this change: "Technical Communication & Collaboration", the first half of round 1. It is a deep discussion of one past project with no slides: design choices, trade-offs, ambiguity, the AI tools you used, how you worked with others. For early-career candidates, one traditional technical interview is being swapped for an open-ended engineering problem. Both changes point the same way: Google wants to watch you think, not watch you recall.
Practice problems tagged for Google
Browse the catalog and open the Google section. No login required to look; sign in when you want to solve one.