Everyone selling interview software right now is racing to ship the same feature: a detector for AI cheating in coding interviews. Keystroke analysis. Paste detection. Webcam proctoring. Little "perplexity scores" that claim to know whether a human wrote your candidate's code.
I get the instinct. I run an assessment company, and some version of "can you catch cheaters?" comes up in most conversations I have with engineering leaders. But I think detection is a war you lose slowly and expensively. Worse, it's aimed at the wrong target. The useful question isn't "did they use AI." It's "how well do they use it."
If you own hiring for a growing engineering team and your screens have felt off for the last two years, this is my case for changing the question instead of buying a better detector.
The detection arms race you can't win
Detection assumes there's a clean line between the candidate's work and the AI's work. That line is gone. An engineer who writes a prompt, reads three suggestions, rejects two, edits the third and ships it did the job. Which part was the cheating?
Then there's the mechanics of it. Paste detection dies the moment someone retypes instead of pasting. Keystroke analysis flags fast typists and neurodivergent candidates as suspects. Proctoring quietly pushes your best people out of the funnel, because nobody with options wants to be filmed through their webcam for an hour. And every one of these tools gets less reliable each time a new model ships, while the candidates you least want are exactly the ones motivated to route around them.
So you end up paying for a system that accuses people you want and misses people you don't. I wouldn't call that a screen.
Quick disclosure before I go further. I'm building Skillvee, a 60-minute "day at work" simulation that replaces the recruiter phone screen and technical first round. Candidates solve a real challenge, talk to AI peers, and defend their decisions to an AI manager while the screen records. In one assessment you see how a candidate codes, communicates, collaborates, exercises agency, and leverages AI, before any senior engineer spends an interview hour. So yes, I have a horse in this race. The argument should stand on its own, but you deserve to know the horse exists.
What the screen was supposed to tell you
Forget AI for a second. What was the take-home or the coding test ever for?
Not "can this person type an algorithm." You mostly knew that from the resume and the GitHub. The screen was a proxy for one question: will this person be good on my team. And coding tests were always a weak proxy for that, because the things that decide it were never in the test.
Think about your last bad hire. Was the problem the code? Almost never. The problem was the person who went quiet for three days when they got stuck. Or shipped without asking the one clarifying question that was obviously needed. Or waited to be told what to do next, every single time. Those are the post-hire surprises that cost you six months and a backfill, and none of them show up in a coding score, with or without AI in the picture.
AI didn't break your screen. It broke the excuse for your screen. The narrowness was always there. AI just made it impossible to keep pretending otherwise.
The better question: how well do they use AI?
Assume every candidate used AI, the same way you assume they used an IDE and a search engine. Make it allowed. Make it visible. Then measure the thing that actually separates people now: judgment about the machine.
Here's the part that surprised me watching real sessions: AI doesn't compress the range of candidate quality. It stretches it. Give everyone the same model and the gap between your best and worst candidates gets wider, not narrower.
A weak candidate takes the model's first answer and moves on. A strong one treats it like a fast, confident junior engineer who lies occasionally. They prompt with precision, check the output against what was actually asked, catch the plausible-but-wrong suggestion, and can tell you afterward why the final version looks the way it does.
A detector can't see any of that. Actually it's worse: a detector reads the strong candidate as more suspicious, because they used the AI more. The difference only becomes visible when AI is part of the assessment and you can watch the work happen. That's what "AI leverage" means as a hiring signal. I'd take it over a clean-room coding score for any role I'm hiring this year, because it's closer to the actual job.
The six dimensions of pre-onsite signal
If you replace detection with observation, you need to know what you're observing. This is the list we settled on after a lot of arguing about what actually predicts performance. A good pre-onsite screen surfaces all six in one sitting.
| # | Dimension | What it tells you |
|---|---|---|
| 1 | Code quality + technical judgment | What they ship and the trade-offs they make |
| 2 | Communication | How they explain reasoning and ask clarifying questions |
| 3 | Collaboration | How they gather context and work within constraints |
| 4 | Agency | Whether they drive the work or wait to be told |
| 5 | AI leverage | How well they prompt, verify, and correct AI output |
| 6 | Judgment + time management | How they prioritize under realistic pressure |
A coding test measures the first row, and measures it badly now. An onsite covers most of the rows but costs about five senior-engineer hours per candidate. The gap between those two is the whole opportunity: measure all six before the onsite, so the only people who reach your team are worth your team's time.
What this looks like in a real session
Picture two candidates with the same task: extend a small service, any tools they want, an AI peer available for questions, an AI manager reviewing the decision at the end.
Candidate A asks the AI peer for the whole implementation, pastes it, watches the tests pass, submits. Asked why they chose that data structure, they've got nothing. Clean code, no judgment behind it.
Candidate B starts with a scoping question. They notice the generated approach misses a case the brief implied, fix it, and when the manager pushes back, they explain the trade-off in one sentence.
Same tools, same hour, completely different hires. On a detector these two look identical. If anything, B looks worse, since B used the AI more. Watched across six dimensions, the ranking is obvious and correct. That inversion is the whole argument.
How to run an AI-open screen yourself
You don't need us for the principles. If you're rebuilding your first round this quarter:
- Say the quiet part out loud. Tell candidates to use whatever they'd use on the job. Once AI is allowed, hiding it stops making sense, and you finally get to watch real behavior.
- Use a real task. Reversing a linked list tells you nothing about how someone works with AI. A scoped slice of actual work does.
- Record the process, not just the output. The signal lives in how they got there. Grade only the final artifact and you're back to grading the AI.
- Define "good" for the non-code dimensions before the session. Communication, agency, AI use. If you don't write it down up front, you'll score on vibes, and vibes don't calibrate across interviewers.
- Make them defend one decision. A two-minute "why did you do it this way" separates people who understood their work from people who transported it.
Where this gets hard
I'll be honest about the costs, because there are some.
Designing a realistic task takes real effort. A lazy simulation is just a take-home with extra steps, and candidates can tell. The task has to have enough ambiguity that agency and communication actually show up.
Scoring six dimensions consistently is also work. One hiring manager eyeballing a recording will drift. You need either a written rubric your team actually follows, or tooling that scores against one. And if your interviewers won't watch the recordings or read the reports, you've built signal nobody consumes, which is the same as no signal.
None of this changes the direction. It changes the build-vs-buy math, which is a decision you should make with clear eyes about your team's bandwidth.
Do the work, though, and "are they cheating" mostly stops being a question. There's nothing left to cheat. The AI is the expected tool, and you're measuring what was always the point: how this person works.
That's the bet behind how Skillvee works, and it's why our pricing charges by volume instead of per proctored seat. Detection taxes the wrong thing. Watching people work is the product.