AI Can Write the Code. Here's What the AI-Assisted Coding Interview Actually Tests.

The coding interview has a new problem, and it's not LeetCode.

For about two years, candidates have been walking into technical screens with ChatGPT in another tab. Some get caught. Most don't. The output looks like competent code, often more polished than what they'd write under pressure while their hands shake and the clock ticks. Companies noticed. And the industry's response was not to ban AI. It was to restructure what interviews actually test.

Google is bringing back in-person rounds to verify fundamentals. Meta introduced an AI-assisted coding round that hands candidates an AI tool and watches what they do with it. Canva announced in June 2025 that candidates should use Copilot or Claude, and meant it. The surface formats diverged. The underlying signal they're all hunting for is the same: real-time reasoning. You can't fake that.

The Old Floor Just Collapsed

Before ChatGPT, a working solution proved something. You either understood the problem or you didn't. The code was evidence.

That's not true anymore. A correctly implemented BFS doesn't tell you whether the candidate understands why BFS applies here instead of DFS, what happens if the graph has a cycle, or why the visited set needs to be populated before pushing to the queue rather than after. The code could have come from anywhere, and increasingly, it does.

What can't come from anywhere is the candidate saying, out loud, unrehearsed: "I'm noticing the graph might be disconnected, so I need to handle that case. Let me think about where in the traversal that matters." That sentence, spoken live, shows the model in the person's head. Not just the output of their hands.

Take-home assignments broke first. A five-day project with full internet access tells you less every month. Companies that relied on take-homes found they were selecting for prompt engineering skill and willingness to spend a weekend, not engineering judgment. Many dropped them. The ones that kept them added intensive follow-up debriefs: explain every decision, cold, in real time. The take-home became a pretext for the live conversation.

How Google and Meta Actually Run These Rounds

The moves are concrete, and they go in opposite directions on purpose.

Google CEO Sundar Pichai told Lex Fridman: "We are making sure we'll introduce at least one round of in-person interviews for people, just to make sure the fundamentals are there." Google also added a code comprehension round in 2026 where candidates read and debug an existing codebase with Gemini available as an assistant. The question isn't whether you can produce code. It's whether you understand code and can explain your reasoning about it.

Meta went a different direction in format and arrived at the same evaluation. Starting October 2025, they piloted an AI-assisted coding round. Candidates get CoderPad with an AI chat window built in, a multi-file codebase, and 60 minutes. The rubric evaluates problem solving, code quality, verification, and communication. Their explicit guidance to candidates: "Should use AI, but need to show you understand the code. Explain the output. Test before using. Don't prompt your way out of it."

The communication criterion is not soft. It's doing the same work the old code solution used to do. You narrate your process. You explain why you accepted or rejected what the AI suggested. The interviewer is building a model of your understanding from your words, not your code.

Four Things the Interviewer Is Actually Scoring

Whether the format is in-person or AI-assisted, the behaviors being evaluated have converged. Surprise: they're all about what you say out loud.

Decomposition. Can you break an unfamiliar problem into smaller pieces before you know the answer? Most candidates go quiet here, which is the worst possible move. Strong candidates narrate: "The core challenge is X. I'm going to assume Y for now and revisit if that breaks something." That narration is signal.

Tradeoff articulation. When there are two possible approaches, can you explain what each costs? Not just reciting complexities like a Wikipedia article, but reasoning about them in context. "Approach B has worse asymptotic complexity, but the input is bounded at 10,000 and the constant factor matters more at this scale." The ability to reason about constraints, not just execute against them, is what interviewers listen for.

Judgment on AI output. In the new Meta and Google formats, this is now explicit. The model produces something. Do you accept it? Modify it? Reject it and explain why? Blindly accepting whatever the model outputs is the fastest way to fail a 2026 interview. The signal is whether you actually understand what's in front of you, or are just forwarding the output.

Adaptation under questioning. The interviewer changes a constraint. "Now assume the input can have duplicates." Or: "What if the graph can have negative weights?" How you respond to a twist reveals more than how you solved the original problem. It separates people who understood the structure from people who memorized a pattern and got lucky the problem matched it.

Sr front-end dev reads textbook answer during interview; interviewer reacts with silent judgment

When you memorized the answer but the interviewer asks "can you walk me through why?"

You Can't Just Ask ChatGPT to Explain It for You

You can feed a problem to ChatGPT and ask it to explain the reasoning. But in a live interview, you're producing that explanation in real time, in response to a human who is probing for gaps, following up on things you said, and changing the problem as you go.

The interviewer is not listening to your answer. They're listening to your process. A prepared explanation is obvious the moment the first follow-up lands.

There's a practical reason this matters beyond just getting hired. A senior engineer who can't explain technical decisions, who goes quiet when requirements change, who can't articulate tradeoffs to a product manager, is a genuine risk on the team. The interview is selecting for something real. AI just made it harder to fake.

You can see the same dynamic in the posts on how to communicate during a technical interview and what to do when you're stuck in a coding interview. The tactical advice hasn't changed much. The stakes have gone up.

The Fix Is to Actually Talk Out Loud

The skill is learnable. It's just not what most interview prep builds.

Most practice is silent. You sit with LeetCode, think, write code, submit, read the editorial. The verbal layer never happens. So when you're in an interview and expected to narrate, you're doing something you've almost never practiced, under pressure, while also solving the problem. Congratulations. That's three things at once.

The fix is simple. Make narration the default during practice, not something you bolt on after you've already solved it. While you're solving it. Say the subproblems out loud. Say the wrong approach you're considering. Say why you're eliminating it before you eliminate it.

This feels slow at first. It's not. Experienced interviewers consistently report that candidates who talk through their thinking make progress faster, not slower, because they get redirected before going far down the wrong path. Saying "I'm using a set here because I need O(1) lookup" forces you to verify that's actually true for what you're building. Sometimes it's not, and catching that early is the whole game.

Three habits that accelerate this:

Start every practice problem with a 60-second verbal framing before you write any code. What's the input structure? What makes this hard? What's the simplest possible instance of this problem? Say it out loud. Your dog counts as an audience.
Narrate wrong turns explicitly. When you notice your approach isn't working, say it out loud before pivoting. "I was going to try a hash set here but that doesn't give me ordering, and I need ordering because..." This is the highest-value moment to practice because it's the most uncomfortable. It's also what separates good candidates from great ones.
Practice with a human in the loop. The feedback loop of real conversation is not replicable with a timer and LeetCode. Even a peer who doesn't know the answer creates pressure that forces clarity. You explain differently when someone is listening.

If you want to practice the actual thing, SpaceComplexity runs voice-based mock interviews with follow-up questions and rubric-based feedback on communication, not just correctness. The reps that matter are the ones where you're narrating live, not reviewing a solution after the fact.

If you're still building the underlying pattern recognition, how to actually solve problems you haven't seen before covers the structural thinking that makes narration feel natural rather than forced. And the LeetCode difficulty question matters more now than it used to, because shallow familiarity with hard problems is exactly what breaks under live questioning.

The candidates struggling in 2026 mostly aren't failing on knowledge. They're failing on the layer above it: transparent real-time reasoning. AI made that layer visible. It also made it impossible to fake.