The AI Interview Collapse: Engineering Hiring Has Lost Its Signal

The signal is gone. In a recent audit of 19,368 technical interviews, 38.5% of candidates were flagged for AI-assisted cheating, with technical roles hitting 48% and junior candidates cheating at nearly double the rate of senior ones. More damning: 61% of detected cheaters scored above the passing threshold. Without the detection layer, they would have advanced. The interview, as an instrument, is no longer measuring what it was designed to measure.

This is not a moral panic about kids these days. It is a mechanical failure of the instrument. The technical interview was calibrated for a world in which a candidate, under time pressure, in an unfamiliar environment, had to produce correct code from memory and first principles. That constraint — the thing that made the signal legible — has been dissolved by a free-tier chat window running on a second device. Every company that still runs a LeetCode-style screen is now paying to sort candidates on a test the test-taker can trivially outsource.

The teams that have taken this seriously have reacted in one of two directions. Either they have accepted that the candidate has a model in the loop and redesigned the interview around that fact, or they have doubled down on detection and proctoring and discovered that the arms race is lost before it starts. Both paths are instructive. The first is harder, slower, and produces better hires. The second produces interview theater that is hostile to honest candidates and transparent to dishonest ones.

The old signal was an accident, and it is gone

The reason LeetCode worked for a decade is not that it measured engineering ability. It measured something correlated with engineering ability under a specific set of constraints: the ability to produce a working solution, in real time, to a problem the candidate had not seen, without external help. The correlation was always weaker than interviewers pretended, but it was cheap to administer and hard to game, and "hard to game" carried most of the load.

Strip away the anti-gaming constraint and the correlation collapses. Run a medium LeetCode problem through any frontier model today and you get a working solution before you finish pasting the prompt. Cluely and Interview Coder run invisible overlays on a second screen and feed answers by transcribing the interviewer's audio. Voice-mode ChatGPT will whisper an approach into the candidate's ear while they "think out loud" about whether to use a hash map. The candidate does not need to be sophisticated. The tools have abstracted the sophistication.

The giveaway is that detection rates and tool adoption are both climbing, not converging. Adoption of dedicated cheating tools doubled in the last six months of 2025, from 15% to 35% of candidates. The defenders are running as fast as they can and falling behind. If your interview's validity depends on a detection vendor's win rate against a moving target, your interview is a service-level agreement with a cheating tool provider, not a hiring process.

Detection-first is a losing war

A full class of startups now sells AI-cheating detection — gaze tracking, keystroke cadence, response latency analysis, screen-share forensics. The pitch is plausible, the metrics they report are genuine, and none of it fixes the underlying problem.

The first failure mode is false positives. Strong candidates who reason genuinely often produce less polished answers than someone reading from a script. They pause. They backtrack. They rephrase the question mid-solve. A detector trained on "suspicious hesitation patterns" flags exactly these candidates at a higher rate. You end up filtering out the people you wanted and passing through the people who had the fluency to paste the model's output without tripping the pattern matcher.

The second failure mode is cultural. The moment interviewers are told to "watch for cheating signals," the interview stops being a collaborative problem-solving conversation and becomes an adversarial observation exercise. Candidates feel it. Interviewers become worse at asking follow-up questions because every follow-up now sounds like an accusation. The honest candidate has a worse interview experience than the dishonest one, because the dishonest one is reading from a script that anticipates the common follow-ups.

The third failure mode is the one that kills the strategy entirely: the detection bar moves every quarter. Anthropic publicly documented this loop. Their take-home test worked in early 2024. Claude Opus 4 matched most human applicants. Claude Opus 4.5 matched the top ones. The team redesigns the test, ships it, and the next model release invalidates the redesign. The company that builds the model cannot build an assessment that the model cannot pass. What are the rest of us doing pretending ours will hold?

"No AI allowed" policies are unenforceable and quietly unfair

The most common reaction from hiring leaders is a policy line at the top of the interview invite: "No AI tools permitted during this assessment." Some go further and require candidates to share their full screen, disable other devices, and sit in a camera-on-face-visible setup for an hour.

The problem with these policies is not that they fail to stop cheating. The problem is that they mostly stop honest cheating. A candidate who is willing to violate the policy runs the cheating tool on a second laptop or a phone off-camera, and their gaze pattern looks indistinguishable from a candidate reading the interviewer's question on the screen. A candidate who respects the policy sits in front of an empty terminal and tries to reconstruct a two-pointer sliding window from memory while the stakes tick. You are running two different interviews under the same label, and the one that produces a passing score is the one you did not want to evaluate.

This is the quiet fairness problem underneath the collapse. "No AI allowed" is not a neutral rule. It is a rule that selectively advantages candidates who will ignore it, and the disadvantaged class is the candidates the company would most want to hire. Every hiring pipeline that still runs a no-AI coding screen is systematically lowering the rank of its honest applicants. The leaders who internalized this have stopped pretending the policy is enforceable and moved the interview instead.

What is actually worth measuring now

The hard question is not "how do we prevent AI use" but "what signal are we trying to extract from this hour, given that the candidate will have a model in the loop on the job anyway?" Stated this way, the answer reorganizes the interview.

The companies moving fastest have converged on a small set of formats:

• Paired debugging on a real repository, AI allowed. The candidate is dropped into a checkout of a non-trivial codebase with a failing test or a reproducible bug. Tools are on the table — whatever editor, whatever assistant, whatever they would use at work. The interviewer watches how they form a hypothesis, how they use the model (or don't), when they commit to an answer, and how they recover when the model's first suggestion is wrong. This is closer to the actual job than any algorithm round ever was.
• Architectural discussions on systems the candidate has shipped. Not "design Twitter." Instead: "walk me through the last non-trivial system you built. What did you choose and what would you do differently?" The model cannot substitute for lived context. The interviewer can probe tradeoffs, constraints, and post-hoc regrets in a way that exposes whether the candidate actually owned the decision or inherited it.
• "Explain this PR" against the candidate's own history. Pick a pull request from the candidate's public work or a representative diff they submitted. Ask them to walk through why they did it that way, what they considered and rejected, and what they would change now. The signal is decoupled from the production of code and concentrated on judgment, memory, and the quality of their internal model of their own work.
• AI-aware product challenges. Canva replaced their CS-fundamentals screen with an "AI-assisted coding" round built around realistic, ambiguous product tasks like "build a control system for managing aircraft takeoffs and landings." Candidates are evaluated on how they decompose the problem, which subtasks they delegate to the model, whether they catch bugs in generated code, and whether they produce something that would survive a production review. The ones who fail are not the ones who typed slowly. They are the ones who accepted the model's first output without reading it.

These formats share a common structure. They stop measuring the act of writing code (which models now do instantly) and start measuring the judgment around the code: when to trust, when to verify, what to ship, what to escalate. The candidates who do well are not the fastest typists. They are the ones who have internalized what it feels like to catch a confidently wrong answer.

The leadership question that is now unavoidable

Rewriting the loop is the easy part. The harder part is answering, out loud, what the interview is supposed to measure now. Every hiring leader rolling out a new format quietly discovers they have a taxonomy problem. There are at least three distinct things people mean when they say "engineering ability," and they require different interviews:

1. Raw problem-solving under constraints — the classic signal the old loop was trying to capture. This is still real, still valuable, and still measurable, but it is no longer measurable with a public-web coding problem. It lives in novel, unfamiliar problem domains the model cannot pattern-match against, and it takes longer to set up and grade.
2. Ability to ship correct systems in a real codebase — which includes reading existing code, choosing the right abstraction boundary, noticing where the model is about to make a wrong-shape-right-type change, and verifying end-to-end behavior. This is closer to what most teams actually need and is harder to fake because it unfolds across enough decisions that the mask slips.
3. Collaboration fluency with AI tools as part of the role — the emerging skill that barely existed two years ago: prompting precisely, verifying skeptically, knowing when to abandon a generation and try a different approach, knowing which subtasks to delegate and which to keep in your head. A candidate can be an excellent classical engineer and a bad AI collaborator, or vice versa. Treating these as a single dimension produces bad hiring decisions.

The leadership team that has not named which of these it is hiring for is running a loop that averages across all three, scores every candidate on a blend, and wonders why the offers are inconsistent. Naming the goal is the uncomfortable prerequisite. Every company discovers, when forced to name it, that the answer has shifted since the last time they wrote their rubric.

What to do if your loop is still the old one

The window for pretending this is someone else's problem is closing. A few concrete moves for teams whose interview loops have not been touched since 2023:

• Stop running take-homes as a first-round filter. They were already unpopular; now they are a filter against candidates too honest to outsource them.
• Replace the online-coding round with a paired debugging session on a real internal repo or a faithful open-source analogue. Allow tools explicitly. Watch the process, not the output.
• Audit the anchor interviews in the loop for "could a model pass this in ten seconds." If yes, the round is measuring something other than what it claims. Retire it or reshape it around judgment.
• Rewrite the rubric. The word "algorithm" probably appears too often and the word "verification" probably appears zero times. Fix the ratio.
• Tell candidates explicitly, in the invite, what the AI policy is and why. Clarity is a fairness multiplier; ambiguity advantages the dishonest.

The teams that make these moves in 2026 will end up with a hiring pipeline that produces better engineers and a more humane interview experience on both sides of the table. The teams that delay will keep running a detection arms race they cannot win, filtering out their best honest applicants, and wondering why the hires who pass the bar keep failing once the screen-share is off and the real work starts.