AI didn't kill technical screening. It killed the artifacts screening was built on. For years, hiring an engineer meant trusting a résumé, a take-home, and a whiteboard round of algorithm trivia. All three assumed producing correct-looking code was hard, and that watching someone do it under constraint predicted how they'd perform on the job. That assumption is gone. Every serious candidate now has an AI pair that can draft a keyword-matched résumé, close out a leetcode problem, or turn a spec into a working diff faster than a human can type. The question isn't whether to let candidates use AI — they already are, whether you notice or not. The question is what you test once the artifact stops being proof of anything.
This isn't a call to panic, and it isn't a call to ban the tools. It's a design problem. If the deliverable is now trivially producible, you have to stop scoring the deliverable and start scoring the process that produced it.
The artifacts you trusted are now noise
A résumé was never a great signal, but it used to correlate with something: the discipline to describe your own work clearly. Now a candidate pastes your job posting into an assistant and gets a résumé rewritten to mirror your keywords in thirty seconds. The signal-to-noise ratio was already low. It's now close to zero.
Take-homes fare worse. A well-specified take-home — build a small service, add a feature, fix a bug — is exactly the kind of bounded, clearly-described task current coding assistants are best at. A candidate who understands nothing about the codebase can hand the prompt to an assistant, get a plausible diff back, tidy up the variable names, and submit something that clears your rubric. At that point you're not evaluating the candidate. You're evaluating the assistant, plus a light editing pass.
Leetcode-style algorithm rounds are the oldest artifact, and the first to fall. These are closed, well-specified problems with solutions written all over the public internet — precisely the shape a model handles best. A closed-book round under a timer no longer tests problem-solving. It tests whether the candidate memorized which shortcuts read as "natural" to an interviewer, or quietly rehearsed typing out AI-generated solutions until they looked like their own.
None of these tools are broken. They're measuring a skill — producing a correct-looking artifact from a spec — that a machine now does for free. Ranking candidates on that axis tells you who has the best AI. It doesn't tell you who's the best engineer.
Stop testing recall, start testing direction
The skill that didn't get automated sits one level up: deciding what to build, catching when the tool is wrong, and knowing when to override it. Call it direction. It's the difference between a candidate who accepts the first thing an assistant offers and one who reads it, tests an edge case in their head, and says, "no — that breaks under concurrent writes."
Direction is durable precisely because it isn't a knowledge task. It's a judgment task, and judgment doesn't get easier to fake just because artifact generation got easier. A candidate can have an assistant write a caching layer in ten seconds. Whether it's safe for your system's actual access pattern is a decision only the candidate can make, by understanding the system well enough to interrogate what the model handed them.
This reframes what a first-round screen is for. You're not checking whether a candidate can produce two hundred working lines of code — assume they can, with help. You're checking whether they can tell code that's correct from code that merely looks correct, under real constraints, in real time. That's a different exercise with a different rubric, and most companies haven't rebuilt their process to test it.
Three signals that still separate people
Once you stop measuring artifacts, three signals reliably separate strong engineers from weak ones — and none of them require banning the tools.
The first is whether a candidate catches a plausible-but-wrong answer. Give them a task and an AI pair, and at some point the assistant will produce something that compiles, passes the obvious case, and is subtly broken — a race condition, an off-by-one, a cache that never invalidates. Strong candidates catch it, usually before running it, because they're reading the logic, not just the output. Weak candidates ship it.
The second is whether they can explain why. Catching a bug is necessary but not sufficient — plenty of people can flag that "something feels off" without saying what. Candidates worth hiring can walk you through the actual failure mode: here's the interleaving that breaks, here's the input that trips the boundary. That explanation is the real engineering skill. The code is just its byproduct.
The third is divergence: whether the candidate's stated reasoning matches the artifact they produced. This one doubles as an integrity check. If someone narrates a coherent decision process that lines up with what's on screen, that's real signal. If the code is polished but the explanation is generic, thin, or doesn't track what's actually there, you've found a mismatch worth probing — usually because the tool did the thinking and the candidate is narrating it after the fact.
Design the screen around real work
None of this works bolted onto your existing process. You can't add "explain your reasoning" as one extra question at the end of a leetcode round and call it fixed. The format itself is the problem, not just what you're failing to ask inside it.
Rebuild the screen around three ingredients. First, a task that resembles the job: a small, real codebase with a legitimate feature or bug, not an isolated algorithm puzzle. Second, an AI assistant present throughout — because that's how the job is actually done now, and because you need something for the candidate to interrogate in front of you. Third, a short defense at the end: five or ten minutes where the candidate walks through the choices they made, including the ones the assistant suggested that they rejected.
This is a genuinely different exercise from a take-home or a closed-book round — see our comparison of take-homes and live screens if you're weighing formats — and it deserves a first-class redesign, not a patch. The goal isn't to make the screen harder. It's to make it measure something that still means something. A well-built AI coding assessment does this by construction: a real task, an AI pair in the room, and reasoning scored alongside code.
What to stop doing
Some habits are worth retiring outright, not adjusting.
Stop proctoring candidates for AI use. It signals distrust before day one, it's trivially defeated by anyone motivated to cheat, and it optimizes for compliance theater instead of engineering judgment. You're not trying to catch someone using a tool everyone on your own team already uses in production.
Stop banning AI assistants from the screen entirely. A ban doesn't remove the tool — it only removes your visibility into how the candidate uses it. Candidates willing to cheat will still use AI on a second device; you've just blinded yourself to the ones who use it well.
Stop scoring puzzle trivia — reversing linked lists, counting islands, dynamic-programming party tricks — as if fluency there predicts anything about shipping software. It was always a weak proxy for the job. Now it's actively counterproductive, because it rewards memorized pattern recognition at exactly the moment pattern recognition became the cheapest commodity in software.
Retire these three habits and you free up the time and the goodwill to run a screen that actually measures the job.
A practical first-round rubric
If you're rebuilding your first round, four dimensions cover what matters, and each has a visible version of "good."
Correctness. Does the code work, including the cases nobody stated out loud? Good looks like a candidate handling an edge case that wasn't in the spec, because they reasoned through it before shipping, not because a test happened to catch it.
Judgment and trade-offs. Did they consider more than one approach, and can they say why they picked one? Good sounds like "I chose the simpler invalidation strategy because our traffic pattern makes the fancier one unnecessary" — not "the assistant suggested this and it worked."
AI direction. How did they treat the assistant's output — a draft to interrogate, or a finished answer to paste in? Good looks like editing, rejecting, and redirecting the assistant mid-task, out loud, with a stated reason each time.
Communication. Can they explain a decision to a teammate who wasn't in the room? Good sounds like a defense a non-expert reviewer could follow, and one that actually matches what's on screen.
Score these four, weight them for the role, and you have a rubric that survives the fact that every candidate now has AI in the room — because it was never testing whether they could produce code alone.
None of this requires exotic tooling. A shared repo, an assistant, a real task, and ten minutes of structured follow-up questions get you most of the way there. We built Chiron because most teams don't have the bandwidth to design and re-run a screen like this for every open role — see pricing if you want the packaged version. But the principles above hold whether or not you ever use it.
The engineers worth hiring were never the ones who could produce an artifact fastest. They're the ones who know when to trust what's in front of them and when to push back. That's the only thing left worth screening for — so screen for it directly.