The coding interview is dead — and if you're still running one, you're selecting for the wrong thing. What predicted performance on a software team in 2022 now predicts proficiency at prompting an AI. That's not nothing, but it's not what you're hiring for.
An Anthropic engineering manager said it plainly last week: he's stopped using traditional coding tests. Not because candidates are cheating. Because the test no longer measures what he needs it to measure. If someone can quickly define a problem and find an elegant solution — with AI helping — that's actually the job. The interview was supposed to proxy the job. It doesn't anymore.
This isn't an AI scare story. It's a clarification. The hiring tools that survive this shift are the ones that were measuring real signal to begin with. Most weren't.
What a coding test was actually measuring
Strip away the mythology and a coding interview was measuring three things: whether you'd done the prep work (LeetCode), how you think under artificial time pressure, and whether you could hold a data structure in your head without documentation.
None of those are core to building software at speed in 2026. The prep-to-performance correlation was always weak. Anxiety under timed conditions is a personality trait, not a skill indicator. And memorization has been obsolete since Stack Overflow.
The test survived because it was cheap to administer, it felt rigorous, and no one had a better answer. "Whiteboard until they crack" at least produced a consistent failure mode you could point to. Consistency isn't quality.
The AI problem isn't cheating — it's that the test tells you less
There's a lot of noise about candidates using AI to pass coding tests. The actual problem is worse: even if a candidate passes without AI, you've learned almost nothing. The test measured a narrow capability that is no longer the bottleneck on any engineering team.
Xobin just launched an AI Interview Auditor — an AI agent that reviews AI-conducted interviews for evaluation inconsistencies. That's not a solution to a broken methodology. That's a more expensive version of the same broken methodology. More process around bad signal is still bad signal.
The teams doing well at hiring right now aren't trying to block AI from the interview. They're asking what the interview was supposed to measure and going back to that directly.
What structured, context-enriched evaluation actually looks like
Greenhouse's approach is worth looking at not because the product is the answer, but because the method is right: define weighted criteria tied to the actual role, then evaluate candidates against those criteria with inspectable evidence. Their AI matching is reviewable. Recruiters can see which skills matched, which were missing, and why a score landed where it did.
That's the shape of what works: evidence against role-specific criteria, with the reasoning visible.
For a founder or a small hiring team, this means three things in practice:
One: The brief has to be specific. "Strong communicator" doesn't help you evaluate anyone. "Can explain a technical tradeoff to a non-technical stakeholder without losing precision" is a criterion you can actually test. The more the brief describes real situations the person will face, the better every subsequent step gets.
Two: Evaluate work product, not performance under pressure. Ask for a short piece of work — a design doc, a debugging writeup, a short analysis — that mirrors the actual job. Not a timed puzzle. A take-home that lets someone show you how they actually think. Yes, they'll use AI. So will they on the job.
Three: The interview tests judgment, not recall. Ask about specific past decisions: what they chose, what they considered, what they'd do differently. Structured behavioral questions at this level are AI-resistant because they're about lived experience, not generic patterns.
The signal that's been there the whole time
Hiring teams are receiving more applications than ever and finding fewer of them usable. That gap is going to keep growing as AI lowers the floor on sending applications. The sorting problem gets worse before it gets better.
The answer isn't a better filter on the front end. It's a clearer definition of what you're actually looking for — and then matching against that with context that goes beyond a resume. What the role actually needs, what the candidate actually did, and the evidence that connects those two things.
Umamy's Dynamic Fit Score works exactly this way: context enrichment on the role and the candidate, self-calibrating against what the hiring team responds to, with every decision reviewable. No black-box score. No test that an AI can ace better than a human can.
1 in 2 people contacted through Umamy replies. That's not a trick of the funnel — it's what happens when outreach is specific enough to be relevant.
Frequently asked questions
Is AI use in interviews a form of cheating?
Not inherently. The question is whether the interview was measuring something real to begin with. If the task is AI-aidable and the job is also AI-aidable, the candidate who uses AI well is demonstrating job-relevant skill. The problem is when the interview was measuring something that's now been decoupled from job performance entirely — like memorizing algorithm implementations.
What types of interviews still hold up under AI?
Behavioral interviews tied to specific past work: decisions the candidate made, the context they operated in, what they considered and chose. Case studies that require synthesis of ambiguous information, not application of a known pattern. Work samples that mirror the actual job. These are harder to game with AI because they require real experience.
How should founders think about the coding test question?
If you're a technical founder hiring engineers: drop the LeetCode. Run a short take-home (2 hours max) on a problem that resembles your actual codebase and priorities. Interview around the take-home — what they did, what they cut, what they'd improve. That conversation tells you more than any whiteboard session ever did.
