Interviews by company · Google

Google's new round is not about writing code.
It is about reading it.

In May 2026 Google started piloting a "code comprehension" interview: an existing codebase, Gemini in the side panel, and an hour to find what is wrong and make it better. It is the first big-company round built around the skill engineers use most and interviews have never measured. Here is what is confirmed, what is guesswork dressed up as fact, and how we would prepare.

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 for junior and mid-level roles on select US teams, starting with Google Cloud and Platforms and Devices, replacing 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.

Now the fan fiction. "60 minutes, CoderPad, three panels, three phases: bug fix, implementation, optimization." That sentence appears on a dozen prep sites, word for word, and it is Meta's format. Nobody has cited a Google source for it, and the few candidate reports that exist so far 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 and for the difficulty to climb. Do not rehearse three acts.

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. "Readdigest.py and 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.
  • Use Gemini specifically. It is the only model in the room. 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?

In the pilot, only if you are interviewing for a junior or mid-level software engineering role on one of the participating US teams, starting with Google Cloud and Platforms and Devices. Everyone else gets the classic loop for now. 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. 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?

Every prep blog says so, and none of them cite a source. Those details are Meta's format with the logo swapped. What Google has actually said is that candidates review an existing codebase, identify issues, debug and suggest improvements with Gemini available. Plan for about an hour and for the work to escalate, but do not rehearse a script of three phases.

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. 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.