After AI Can Code, What Should a Technical Interview Actually Test?

June 30, 2026 · 11 min read · by the interviewco.ai team

Two candidates sit down for the same remote algorithm round. One spent six months grinding eight hundred LeetCode problems. The other did not. Both of them now have access, one window away, to a model that solves the question in under a minute — quite possibly the same model that wrote a meaningful share of the hiring company's own production code this week. Whatever that round used to measure, it is fair to ask what it measures today.

The debate about this has split into two camps that mostly talk past each other. One camp says the LeetCode interview is dead: AI solves it trivially, the format never resembled the job, and remote rounds no longer tell you whose answer you are grading. The other camp says fundamentals matter more than ever: someone has to read, verify, and correct all that AI-generated code, and you cannot do that on vibes. Both camps are holding a real piece of the truth — and the companies actually redesigning their interview loops are quietly acting on both pieces at once.

Here is the position this post will defend: the LeetCode ritual — grind the patterns, recall them on demand — is the part AI made pointless, because instant recall is now a commodity. But the three signals that ritual was always a crude proxy for — is this person smart, is their technical foundation real, do they think in structures — matter more than ever, because directing and verifying AI is built on exactly those three things. The task is not to abolish the technical interview. It is to test the signals directly instead of through a memorization filter.

What the algorithm round was always a proxy for

Nobody ever seriously claimed that inverting a binary tree on demand is the job. The algorithm round survived for two decades because it was a cheap, scalable, roughly comparable proxy for three signals every engineering team genuinely wants:

• Smart. Given a problem you have not seen before, can you make real progress on it — form a hypothesis, test it, adapt when it breaks?
• Solid. Are the fundamentals actually there — complexity, data structures, what the machine is doing under your code — or is the knowledge decorative?
• Structured. Can you decompose a fuzzy problem into named parts, sequence them, and keep your reasoning legible to another person while you work?

The format won on logistics, not validity: forty-five minutes, one interviewer, scores you can compare across hundreds of candidates, and a question bank that any trained engineer can administer consistently. That is a real achievement — most interview formats cannot do comparable-at-scale — and it worked about as well as a proxy can work, for as long as solving the puzzle in front of you required the three signals to be present.

The decoupling started before AI arrived. An entire preparation industry grew up around the insight that you do not need to be unusually smart, solid, or structured to pass — you need to have seen the pattern before. Grinding five hundred problems converts a reasoning test into a recall test. AI just finished the job: now the recall is available to everyone, instantly, whether or not they did the grinding.

The steelman: the case for keeping it

It would be easy to write the clickbait version of this post and declare the whole format dead. But the people defending the traditional interview have serious arguments, and several of them survive contact with 2026 intact:

• You cannot verify what you do not understand. The strongest defense is that AI makes fundamentals more valuable, not less. When a model writes most of the first draft, the engineer's remaining job is judgment: is this correct, is it efficient, what did it silently get wrong? That judgment is built out of exactly the material algorithm rounds claim to test. Notice, though, that this is an argument about the signal, not the format — a point we will come back to.
• Objectivity and fairness. Long before AI, Eli Bendersky argued that live coding is one of the least-biased instruments hiring has: unstructured conversational interviews activate demographic bias, and take-home projects quietly favor candidates with free evenings — or the money to pay someone else to do the work. A standardized live exercise is hard to outsource and comparatively fair. Any replacement format has to clear this bar, and many do not.
• Scale. No comparably cheap, comparably objective method exists for screening thousands of candidates. Work-sample formats are richer but expensive to build, run, and grade consistently.
• It was always partly a communication test. The thinking-out-loud that candidates resent is a real signal: can you make your reasoning legible to a colleague under pressure? That skill transfers directly to the job, and it is precisely what a model cannot perform for you in person.
• Verification pressure is bringing whiteboards back. As NeetCode's Navdeep Singh noted on the Pragmatic Engineer podcast, Google restarted in-person onsite interviews in part because synchronous, same-room observation is now the only way to be confident about who is doing the work. The traditional format did not die from the integrity crisis — parts of it got more traditional.

The case that it is broken

The critics' arguments are just as concrete:

• The remote version has lost its signal. In a survey of Big Tech interviewers run by The Pragmatic Engineer with interviewing.io, 81% said they had suspected candidates of using AI tools to cheat during interviews, and 31% had caught it outright. A score you cannot attribute to the person on the call is not a signal; it is noise with a confidence interval you cannot state.
• AI trivializes the thing being graded. As DistantJob puts it, when a model solves the problem in seconds, testing a human on it no longer measures the ability to build software — it measures the ability to memorize, or to prompt.
• The format never resembled the job, and the gap is widening. Real engineering work is overwhelmingly brownfield: reading existing code, debugging production, integrating systems, paying down tech debt. Canva's engineering team made this explicit when redesigning their interviews: engineers spend far more time reading, reviewing, and iterating on code — increasingly AI-generated code — than writing algorithms from scratch.
• Even its administrators never fully trusted it. The quiet consensus among many hiring managers has long been that the format scaled because it was standardizable, not because it strongly predicted performance — and that agency and motivation predict more than pattern recall ever did. The same NeetCode conversation is refreshingly blunt about this from someone who built a career on interview prep.

The ritual dies; the signals matter more

Put the two lists side by side and the synthesis almost writes itself. Everything broken about the traditional interview is about the ritual: pattern recall, an artificial problem format, an unproctored remote setting that can no longer attribute the work. Everything still standing is about the signals: fundamentals you need in order to verify AI, fairness and comparability, legible reasoning under pressure. The ritual was only ever a proxy for the signals — and AI broke the proxy, not the signals.

The most useful evidence is what companies are doing rather than what commentators are writing. None of the majors abolished the technical interview. All of them are moving the test closer to the signal:

• Meta began rolling out an AI-enabled coding round in October 2025: candidates work in an environment with a built-in AI assistant and a choice of models (GPT, Claude, Gemini, Llama), and are graded on how well they direct the model, test its output, and explain the resulting code — an internal description framed it as more representative of the real developer environment, and as making covert AI use less relevant because AI use is simply part of the exercise.
• Canva titled its engineering post “Yes, You Can Use AI in Our Interviews. In fact, we insist” and replaced its computer-science-fundamentals screening with an AI-assisted coding round that grades judgment: when to lean on the tool, how to break down ambiguous requirements, and whether you can find and fix the issues in what the model wrote.
• Google is piloting a code-comprehension round in which candidates read, debug, and optimize an existing multi-file codebase with Gemini available as an assistant — while simultaneously bringing back in-person interviews for the classic rounds it keeps.
• Shopify expects candidates to lean on AI for most of the work in its AI-enabled rounds — its engineering leadership has put the number at 90–95% — with the evaluation resting on the part the model cannot do: knowing what to tell it, and knowing when it is wrong. One line from their interviewers sums up the whole shift: they do not want the AI working for you; they want to watch you tell it what to do.

Different companies, one pattern: stop testing the proxy, start testing the signals.

How to test smart, solid, and structured — directly

If you accept the three-signal framing, the new formats stop looking like a grab bag and start looking like a mapping. Each one tests a signal the algorithm round only reached by proxy.

Testing “smart”: ambiguous problems, not memorized ones

Raw problem-solving shows most clearly on problems that cannot be pre-ground. Two formats do this well. Structured decomposition of an ambiguous problem — a prompt that is deliberately underspecified, graded on the clarifying questions asked, the way the problem gets cut into parts, and the order the parts get attacked. And the AI-assisted real-world task, where the interesting evaluation is not the typing but the direction: what the candidate asks the model for, what they refuse to accept from it, and how they recover when it confidently produces something wrong. In both, the intelligence being measured is the kind that operates on novelty — which is the kind the job actually uses.

Testing “solid”: reading code, not reciting it

Fundamentals used to be tested by asking you to produce code from a blank page. They show at least as clearly — and are much harder to fake — when you have to understand code you did not write. Google's code-comprehension pilot is the flagship example: symptom, hypothesis, fix, verify, on a codebase you have never seen. The cheaper cousin is code review of AI output — hand the candidate a model-generated solution and ask what is wrong with it; the missing edge case and the quietly quadratic loop are exactly what production judgment looks like. And the past-project deep dive tests the same signal from the other side: real depth on work you genuinely did survives an hour of follow-up questions, while borrowed depth does not survive three.

Testing “structured”: design and collaboration

Structured thinking is best observed at length. System design has quietly become the most durable round in the loop — trade-off reasoning at scale is exactly the skill AI assistance raises the value of, and the round increasingly includes AI components themselves: when to put a model in the architecture, what it costs, how to evaluate it. Pair programming tests the same signal socially: can you keep your reasoning legible to another person, absorb feedback mid-stream, and change course without losing the thread? Neither round can be answered by recall, which is precisely why both predate the AI era and will outlast it.

What this means if you are the candidate

The preparation that pays off is shifting. Less of it looks like grinding problem #501, and more of it looks like four practicable skills: explaining your own work crisply (the deep dive rewards structured recall of things you actually did), decomposing out loud (every new format grades the narration, not just the result), reading and reviewing code (comprehension rounds and AI-output review), and directing AI well (asking for the right thing, then verifying it like a skeptical reviewer).

One honest caveat: these new formats are better tests, but they are still performances. A comprehension round with an interviewer watching is still a high-pressure verbal exam, and pressure still hides real competence — that is a fairness problem the format change does not fix, and it is the problem we care about at interviewco.ai. Our mock interviews are built from your own résumé and the job you are targeting, which happens to be exactly the practice the new loop rewards: explaining your own projects under adaptive follow-up questions, out loud, round after round, with feedback on where the structure broke. The competence is yours either way; practice is what keeps the format from hiding it.

Start with a free mock interview →

FAQ