Picture your last technical interview. A candidate, a shared editor, a problem to solve from scratch, and an unspoken rule: no AI. Now picture that same person on their first Monday in the job - opening an agent, describing the task, and reviewing what comes back.
You measured one thing and hired for another. That gap has always existed a little; in 2026 it has become the main event.
I wrote here before about team-based interviews as an alternative to the code-challenge ritual. This is the follow-up the AI era demands - because the ritual is not just uncomfortable anymore. It has started measuring the wrong thing entirely.
What broke
Two parts of the classic loop stopped working, for different reasons.
The take-home test broke first. It was never a great signal, but now it is not even a signal about the candidate: you have no way to know who - or what - did the work. Unsurprisingly, take-homes are declining for technical roles.
The from-scratch algorithm round broke more subtly. It still measures something real (can this person reason about a problem?), but it over-weights a skill the daily job no longer centers on: producing syntax alone, unaided, under observation. As one analysis of the shift put it, over-indexing on how someone performs without AI does not paint an accurate picture of how they will actually work.
And the industry has noticed. Roughly a quarter of employers now explicitly allow AI in technical interviews - a share expected to keep climbing, though the majority still prohibits it. That split is itself informative: most companies know the old format is misaligned and have not yet decided what to replace it with.
Live is more valuable than ever - just not the same live
Here is the counterintuitive part: live interviews got more valuable, not less. When the artifact tells you nothing (anyone can produce good code now), the process becomes the whole signal. Watching someone think, decide, and debug in real time is the only thing that cannot be outsourced.
So keep the live session. Change what happens inside it.
What to assess instead
Five signals that survive contact with AI - each of them, notice, a thing I keep writing about as the actual job:
- Problem decomposition. Give a fuzzy, underspecified goal and watch them break it down. Do they ask what the business actually needs? Do they surface the constraint everyone forgot? This is the skill that turns intent into something executable - by a teammate or an agent.
- Code review. The strongest round I know: hand them real, plausible-looking code with two or three planted flaws - a subtle authorization gap, an edge case that fails, a “clever” abstraction nobody needs. Ask what they would approve. Review is the new bottleneck; test for the bottleneck.
- Judgment between options. Present three architectures - all defensible - and ask which they would choose and why. You are testing whether they can weigh trade-offs against context, not whether they memorized a pattern.
- Specification writing. Ask them to write, in plain language, precisely enough that someone else could build it: intent, constraints, what “correct” means. Precision in prose is the new precision in syntax.
- Collaboration. Do they push back? Ask for context? Change their mind when given new information? All still human, all still decisive.
The bold move: let them use AI - and watch how
If you take one concrete change from this post, make it this one. Let candidates use AI in the interview, on a real task, and pay attention to how they use it. Some companies are formalizing this into a dedicated round - reading, debugging, and optimizing an existing codebase with an AI assistant available - and evaluating what they call AI fluency: prompting, output validation, debugging.
What to watch for:
- How they prompt. Vague wish, or precise intent with constraints? You are watching them specify - the skill from point 4, in the wild.
- What they accept. Do they read the output critically, or paste it and move on?
- What they question. The best candidates argue with the machine. They notice when it is confidently wrong and say so.
- How they verify. Do they run it? Write a test? Check the edge case? Or trust the confident tone?
- When they stop using it. Knowing when the tool is the wrong choice is judgment too.
Then throw a curveball based on what the AI produced - change a requirement, add a constraint. Adaptation reveals understanding in a way no prepared answer can, and it neatly separates “understands the code” from “relays the code”.
Because here is the uncomfortable truth this format finally exposes: blind acceptance of confident nonsense is the new “cannot code.” That, not typing speed, is the red flag worth screening for.
A practical loop
If you want something concrete to adapt:
- Screening (30 min) — experience conversation, honest and human. What did they build, what broke, what would they do differently?
- Code review round (45 min) — real code with planted flaws, AI available. What do they catch, what do they approve, how do they phrase feedback?
- Build round with AI (60 min) — a small, realistic task, tools allowed. Watch the process; then change a requirement mid-flight.
- Design conversation (45 min) — a fuzzy problem, whiteboard-level. Decomposition, trade-offs, questions asked.
- Team session — the part I have always advocated: does this person work well with the humans they will actually work with?
Notice that nobody in that loop is asked to invert a binary tree from memory while a stranger watches.
Hiring drivers, not typists
For decades, part of assessing a professional driver was watching them handle a manual gearbox on a hill start. It was a real skill, it separated the practiced from the nervous, and it was fair to test - because every truck had one.
Then transmissions became automatic. And the interesting question is what a sensible fleet manager did next. The bad ones kept the hill start, because that was how it had always been done, and hired people who were excellent at a task their vehicles no longer required. The good ones asked what actually makes a driver valuable now: reading the road, judging conditions, deciding when not to drive at all, knowing the load and the route and the risk.
The gearbox is our algorithm round. The machine now handles the mechanics beautifully. Keep testing the driving - the judgment, the road-reading, the decision to pull over when something feels wrong.
Those were always the things that made someone worth hiring. We just used to be able to hide the test inside a gearbox.