You join the call and there’s no blank editor waiting for you. Instead there’s a few hundred lines of code somebody else wrote, a Gemini panel on the side, and an interviewer asking what this code does and why it’s slow. No array to reverse. No graph to traverse.
That’s close to what Google started piloting in May 2026, and the internet did what it always does. “Google killed LeetCode” was the mood in my feeds for a week. It didn’t, at least not yet. I spent a few days reading the news reports and the prep write-ups, and the real story is smaller than the headlines and, I think, more useful if you have an interview coming.
My view is simple. The new round tests something much closer to the actual job, and it still doesn’t replace anything for most of us. Both halves of that matter, so I’ll go slowly.
What Google actually announced
In early May 2026, reports built on an internal Google document said the company was piloting a software engineering interview where candidates can use an AI assistant. A Google spokesperson confirmed that the assistant is Gemini, the company’s own model. Brian Ong, Google’s vice president of recruiting, told Business Insider that Google is piloting changes to its interview process, including a check for AI fluency, so interviews look more like how teams work today. NewsBytes reported that Google calls the approach “human-led, AI-assisted.”
The scope is narrow. It’s for junior and mid-level candidates on select teams in the US, and prep sites say it began with Google Cloud and the platforms and devices unit. Juniors reportedly also get more open-ended problems, and the Googleyness and Leadership round now has you talk through designs from your past projects. I didn’t find anything saying candidates outside the US are in the pilot.
The round itself is called code comprehension. You get an existing codebase, and you read it and debug it, then you’re expected to make it faster, with Gemini available the whole time. Final Round AI and AceRound, two interview-prep sites, describe a 60-minute session in CoderPad with a codebase of roughly 200 to 500 lines. I’d treat those details as soft. They come from prep blogs and candidate posts, and Google hasn’t published a format sheet that I could find.
The sources disagree on one thing. Some write-ups say the new round replaces one of the two traditional coding interviews. AceRound says it adds a round and takes nothing away. I couldn’t settle this from public information, and I doubt anyone outside Google can right now.
And it’s still moving. Tekedia and Tech Times both published pieces this week, citing internal documents, saying the new formats have spread beyond the first test groups, though Google still calls it a pilot. The same reports say Google now treats AI fluency as a requirement for every software engineering role, and that it’s testing Gemini to transcribe interviews and take notes in Google Meet. So whatever I describe here may already look a bit different by the time you read it.
What the round actually tests
Final Round AI says the round scores code reading and debugging, plus something it calls AI fluency. Code reading means following the flow of execution through code you’ve never seen. Debugging is the old skill, finding out why something behaves wrong. AI fluency is how you use the assistant while you do both.
Code reading is the one that catches LeetCode-heavy people. When you grind LeetCode you always write the solution yourself, so you always know where everything is. Dropping into a codebase where somebody else named things their own way and hid a side effect three calls deep is a different muscle. I still lose close to an hour on any new repo before I know where a request even enters.
I’m making up the next example, so don’t treat it as a real Google question. Say the codebase is a small order service with a cache sitting in front of the database, and customers are complaining that sometimes they see old prices. The bug itself is small. A weak candidate pastes the whole file into Gemini and types “what’s wrong with this code?” Gemini comes back with five points, three of them style complaints, and the candidate reads them out one by one. The interviewer asks which of the five causes the old prices, and the candidate has no idea, because they never formed their own picture of the code. A stronger candidate spends the first ten minutes just reading, finds the line that builds the cache key, and notices the currency isn’t part of it. Then they ask Gemini one narrow question, something like whether any other caller writes to that key. They read the answer, and then they check it by tracing the call sites themselves. When Gemini gets one detail wrong, which it sometimes will, they catch it and say so out loud. That’s more or less the whole round, and it’s less about the bug than about how you behave around an answer you didn’t write.
The interviewer is watching small things. Do you read first or ask first? Is your question to Gemini specific or lazy? Do you run the code to confirm what it told you? Can you explain the fix in your own words without looking at the panel?
The follow-up questions are the real test.
One writer on Medium, who goes by codegrey, says the candidates who do well are the ones who slow down at the start, and the ones who leaned on suggestions they half understood fell apart when the interviewer pushed. That matches what I’d expect, but it’s one person’s observation and not data, so hold it loosely.
But new grads aren’t expected to read like seniors. Final Round AI says L3 candidates aren’t held to the code-reading depth of someone with five years in production, so the bar moves with your level.
Nobody has published the scoring sheet, so this next part is my guess. I’d expect four boxes. Did the candidate build a correct mental picture of the code before touching anything? Did they find the root cause and not just a symptom? Did they check what the AI told them? And could they explain all of it clearly while someone watched? A person can be strong on three and weak on one, and the fourth box, the explaining, is probably where most DSA-trained people lose marks, because a LeetCode round never asked them to talk this much.
Why I think it beats DSA
Start with what the job looks like now. At Google Cloud Next 2026, Sundar Pichai said about 75% of all new code at Google is AI-generated and then reviewed by engineers. I got that number through Fahim ul Haq’s Medium post and haven’t watched the original talk, so take it as reported. But if it’s even roughly right, typing code from scratch isn’t the slow part anymore. Judging code is. A DSA round tests the part that’s shrinking, and a code comprehension round tests the part that’s growing.
Small tangent. In my second year we memorised the knapsack DP table the night before an exam, every row, every column. I could have redone it in my sleep that week. Today I’d need an hour and a YouTube video. That’s what a lot of DSA rounds measure, how recently you practiced that exact pattern.
People say DSA shows how you think. Mostly it shows whether you’ve seen the pattern before. That’s a bit unfair, though, because a few good DSA questions really do force you to reason from nothing. They’re rare, and the popular ones are explained on YouTube in every language.
Then there’s the work itself. Most backend work is moving data between a database and an API, and the hard part is working out why last Tuesday’s deploy changed a response. Nobody has asked me to balance a tree on the job.They’ve asked me why the report shows yesterday’s numbers.
There’s one more benefit I like. A round where AI is allowed and visible lets the company see how you treat a tool that’s wrong some of the time. Do you trust it blindly or do you check? Every team I know of needs people in the second group, and a LeetCode round can’t tell you which group someone is in.
DSA does have one real point in its favour. Anyone with a phone and free evenings can grind it, and a lot of people from small colleges in my part of the world got into good companies that way. Reading code well takes longer to build, and there’s no leaderboard telling you how you’re doing. I don’t have a fix for that, and it makes me less certain than I sound above.
Where I’m not convinced
I’m not ready to call this a clear win, and I have five doubts. I’ll be honest, a couple of them might be me being old-fashioned.
First, size. Two hundred to five hundred lines is small. The hard part of a real repo is that it’s huge, and you have to find the right three files out of three thousand. A single 300-line file can’t test that skill, and I think it’s the one that matters most for the job.
Second, scoring. I couldn’t find a public rubric for “AI fluency.” Two interviewers could watch the same candidate and score them differently, and nobody outside Google would ever know. DSA has plenty of flaws, but a solution at least passes the tests or fails them.
Third, the Gemini-only rule. Meta’s version of this round, according to a career-center guide from the University of Miami, lets candidates pick from several models, while Google’s pilot requires Gemini. If you use another assistant every day, your habits don’t carry over, and you’re learning a tool under pressure.
The fourth one worries me most. Assistants don’t give the same answer twice. Last month I asked one to explain a function in a repo I was reading, and it summarised the comment above the function and not what the code did. It took me twenty minutes to notice they disagreed. Now put that in an interview. One candidate asks a question and gets a clean answer, and another asks the same thing and gets a confident wrong one. Is the interviewer scoring skill or luck? You could argue catching the wrong answer is the whole point, and partly it is. But the candidate who got the clean answer never had to prove they could catch anything.
Last, the pilot is for junior and mid-level roles. Senior loops, with their system design rounds, aren’t what’s being described, so the people with the most experience reading code aren’t the ones being tested on it.
Which is probably why Google keeps calling it a pilot.
The cheating problem
This is the part people ask me about most.
DSA interviews are the easiest ones to cheat right now. A LeetCode medium that took a human hours to learn takes an AI a few seconds, and a remote round gives you a second screen or a friend typing off camera. Tools like Cluely, if I remember right, were sold around exactly this idea. When the answer is a known problem with a known solution, an interview partly becomes a test of how well you can hide a tool.
Code comprehension changes the game. The AI is allowed, it’s the interviewer’s own approved model, and the interviewer can see how you use it. There’s nothing to hide, so the thing being graded has moved from “did you produce the answer” to “do you understand the answer.” That second thing is hard to fake live. You have to talk through your reasoning, answer a follow-up you didn’t see coming, and change course when the interviewer says the fix breaks another case. Somebody whispering the answers to you will always be a few seconds behind.
It doesn’t end cheating, to be fair. A remote candidate could still run a second assistant on another device and ask it to explain the code. But then they’d have to relay that explanation in natural speech while the interviewer asks new questions, and I suspect that falls apart fast. I haven’t verified whether Google has changed anything about in-person versus remote rounds, so I won’t say anything about that.
Can we finally drop DSA?
Not soon.
The pilot is limited, one source says it adds a round and doesn’t replace one, and Final Round AI says candidates still need strong DSA fundamentals alongside code reading in the current format. Google isn’t telling anyone to stop practicing algorithms. It’s saying that algorithms alone stopped being enough.
Outside Google, the picture is even slower. From what I see in India, campus drives and most service companies still run on an online DSA test, and a pilot for US juniors at Google won’t change a TCS screening round next semester. Meta started its own AI-enabled interview pilot in 2025, and AceRound says Canva, Shopify and Rippling have moved toward AI-allowed technical rounds too. So the direction is clear. The speed is not.
My guess is that DSA as the only filter is on its way out, and DSA as a basic check will stay for a long time because it’s cheap to run at scale. A company screening ten thousand applicants can’t give each one an hour with a repo.
If I had an interview in three months, I’d keep one DSA problem a day and add a new habit on top. Pick a mid-size open-source repo you’ve never touched. Set a 60-minute timer and trace one request from where it enters to where it hits the database. Before you ask Gemini anything, write your own guess on paper, then ask it and compare. Tracing one request will only take ten minutes once you know where to look, and the first few times you won’t, which is exactly why you should practice now. And say your reasoning out loud while you do it, even if you’re alone, because the explaining is half of what’s being scored.
So practice the narrow question too. “Explain this repo” gets you a brochure. “Which functions write to this map, and can any of them run at the same time?” gets you something you can check in two minutes. That one habit is probably worth more than another week of dynamic programming problems.
One practical thing for candidates here in India: ask your recruiter which format your loop uses. The pilot is described as US-only for now, so you may still get the old rounds, and you don’t want to find that out on the day.
What I still don’t know is how any of this gets graded. Nobody has posted a full rubric, and until somebody does, I’d prepare for both kinds of round and complain about it later.