Imagine walking into a Google coding interview and being handed the one tool you were always told to hide: an AI assistant, right there in the editor, ready to write the whole solution for you. Feels like a gift. It’s actually the screen.
For as long as any of us have been interviewing, the rule was simple: no AI, no Googling, just you and a blank editor. Then, in May 2026, Google quietly flipped it. In a new “code comprehension” round it’s piloting for L3 and L4 engineers — starting on teams like Google Cloud and Platforms & Devices — candidates now get Gemini as an assistant and are asked to read, debug, and optimize a multi-file codebase they’ve never seen before. Meta got there first. Since October 2025, one of its two coding rounds drops an AI assistant into the editor and even lets you pick your model — GPT, Claude, Gemini, Llama.
Every candidate I mentor has the same first reaction: Finally. This will be easier.
Here’s what I keep having to tell them: it’s the opposite. Let me pull back the curtain on why.
Think about what “you can use AI now” actually does to the problems they can ask.
The old rule — no help — capped difficulty. The problem had to be something a nervous human could think and type from scratch in 35 minutes. The moment you hand candidates an assistant, that ceiling disappears. So the problems climb to meet it. Google’s round runs a full hour and moves through three phases — find and fix the bugs, add a feature inside an architecture you didn’t design, then make it faster. Analysts tracking the pilot expect the difficulty to land where “Hard” and “Hard+” used to live.
You’re not being asked to do less. You’re being asked to do more, faster, on code you didn’t write. The AI just closes the gap that used to make that impossible.
Read Google’s own scoring criteria and the shift is unmistakable. Interviewers are told to evaluate prompt engineering, output validation, and debugging AI’s suggestions — not whether you can produce a clever solution alone.
That is a completely different skill. Writing code is generative. Catching bad code is adversarial — you have to distrust something fluent and confident and be right about why. The interview flipped from “can you produce a solution?” to “can you judge one?” And judging is harder, because the AI’s wrong answers don’t look wrong. They compile. They read beautifully. They’re just subtly incorrect in the one place you didn’t check.
Because interviews are expensive and risky to change, and companies only touch them when the interview stops predicting the job. This one had.
Google’s own numbers say it out loud. On April 22, 2026, Sundar Pichai said 75% of new code at the company is now generated by AI and approved by engineers — up from about half the previous fall. Sit with that. Three of every four lines a Google engineer ships, they didn’t write. They reviewed, corrected, and took responsibility for.
If that’s the job, the old interview was measuring the wrong thing entirely. Watching someone invert a binary tree by hand tells you nothing about whether they can catch the plausible-looking bug an agent slipped into 400 lines at 6 p.m. The new round isn’t Google going soft on rigor. It’s Google finally testing the job as it actually exists in 2026. That’s the whole answer to the title: harder, because the real work got harder. The people who bomb the new round almost all fail the same way: they treat the AI as an oracle. They prompt, get code that runs, and move on — without reading it. And the interviewer is watching for exactly that.
I’ll implicate myself here, because it’s the same reflex. On a big diff, late in the day, when the AI’s output passes the tests, I have absolutely rubber-stamped a pull request I didn’t read line by line. That instinct is human. In the interview, it’s disqualifying — because the entire signal they want is what you do in the ten seconds after the machine hands you something that looks right.
If I were prepping for one of these today, I’d stop grinding fresh LeetCode in a vacuum and start training the muscle they’re now scoring: Read code you didn’t write. Open a mid-size open-source repo, find a real bug, fix it. Unfamiliar-codebase reading is the new whiteboard, and almost nobody practices it.
Keep your fundamentals sharp enough to smell a wrong answer. You cannot validate the AI’s complexity claim if you don’t know Big-O Notation. DSA didn’t die in the AI era — it became your lie detector.
Treat the AI like a junior engineer on your team. Prompt clearly, then review like you’re accountable for every line.
Narrate your judgment. Say out loud why you accept or reject each suggestion. The score lives in your reasoning, not in the final code.
The interview stopped asking “Can you write it?” It started asking “Can you catch it when the machine writes it wrong?”
So back to that assistant they slide across the table. It was never a gift. It’s a mirror — and it shows the interviewer exactly how you’d behave on the real job the first time the AI is confidently, beautifully wrong.
Now I’m genuinely curious what you think: does putting AI inside the interview finally test engineering as it really is now — or does it just reward people who are good at sounding right while the model does the work? And be honest — if Gemini showed up in your next interview, is it a weapon, or is it exposure?
I’ll be in the comments.
Why Google's New AI Coding Interview Is Harder, Not Easier was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.