An analysis of 19,368 interviews conducted between July 2025 and January 2026 flagged 38.5% of candidates for AI-assisted cheating behaviour, rising to roughly 48% in purely technical roles — and 61% of those flagged scored above the pass threshold and would have advanced undetected. If you run a five-person startup, the useful reading of that number is not that candidates have become dishonest. It is that the standard coding screen stopped measuring anything. The fix is not better proctoring. It is a test that assumes the tools are present and grades the judgement they cannot supply.
Key takeaways
- Detection is a losing arms race: 61% of flagged candidates still passed on score alone.
- AI already writes about 42% of committed code, so the reviewable skill is verification, not typing.
- The frustration developers report most — 66% cite answers that are almost right — is exactly the failure mode an interview should probe.
- A short paid trial on a real ticket survives AI assistance intact, because the artefact is a reviewed pull request rather than a puzzle solution.
Detection is the wrong investment
The instinct is to buy proctoring. Consider the economics before you do: the same interview analysis found junior candidates with under five years of experience showing flagged behaviour at nearly double the rate of seniors, and cheating rates roughly tripling in late 2025 as invisible-overlay tooling spread. You would be committing a small engineering team to an adversarial spending race against a fast-moving consumer software category, with a false-positive cost paid entirely by honest candidates in a time zone you cannot observe. Meanwhile the ability being defended — writing a known algorithm unaided under time pressure — corresponds to less and less of the working day. We made the related case about résumés in our piece on screening developers in the AI résumé flood: when a filter can be passed by a machine for free, the filter has stopped being information.
What the working day now actually contains
Sonar’s January 2026 survey of over 1,100 professional developers found that AI now accounts for about 42% of committed code, expected to reach 65% by 2027, while 96% of developers do not fully trust that AI output is functionally correct and only 48% always verify it before committing. Thirty-eight per cent say reviewing AI-generated code takes more effort than reviewing a colleague’s. Stack Overflow’s 2025 survey points at the same seam from the other side: 66% of developers name “AI solutions that are almost right, but not quite” as their top frustration, with 45% citing the time cost of debugging generated code, and more developers now actively distrust AI accuracy than trust it.
Read those together and the job description writes itself. The scarce skill is not producing a plausible function — that is now free and abundant. It is noticing, quickly, that a plausible function is wrong. There is even evidence that the speed dividend is not automatic: METR’s randomised trial of 16 experienced open-source developers across 246 tasks found they took 19% longer when allowed to use early-2025 AI tools, while believing afterwards that the tools had made them 20% faster. METR is explicit that the result reflects the tools and workflows of that period rather than today’s. But the direction of the error is the durable finding, and it is the exact quality your interview should be measuring: whether a candidate can tell what is actually happening from what appears to be happening.
Four questions generated code cannot answer for a candidate
Predict the failure. Change one line of their submission in front of them and ask what breaks, before anything runs. Understanding predicts; recall does not. Name the road not taken. Ask which approach they considered and discarded, and why. A real decision has a rejected alternative attached to it; a pasted one does not. Review someone else’s diff. Hand them a forty-line pull request containing one subtle defect and ask what they would say in review. This is the single most transferable exercise available in 2026, because it is precisely the task their week will consist of. Explain the blast radius. Ask what else in the system this change could touch. Scope awareness is the thing that distinguishes an engineer from an output stream, and it is unbluffable in a five-minute conversation.
The interview loop, rebuilt
- Say the tools are allowed, in writing. One line in the invitation removes the incentive to conceal and converts the whole exercise from an integrity test into a skills test.
- Screen on artefacts, not scores. One merged pull request with its review conversation, one live project, 200 words of their writing. Twenty minutes, and none of it is generatable on demand.
- Replace the algorithm puzzle with a code-review exercise. Your own repository, a real diff, one planted defect. Grade the questions they ask as heavily as the defect they find.
- Run a paid trial on a real ticket. A scoped issue from your backlog, roughly a week, paid at the rate you set. Our six-week work trial guide covers the structure; even a single ticket outperforms any interview loop.
- Judge the pull request the way you judge your team’s. Commit hygiene, tests, how they responded to review comments, whether they flagged something outside the ticket rather than silently changing it.
- Ask what the AI got wrong. Directly: where did the assistant mislead you and how did you catch it? Candidates with real verification habits answer this immediately and with specifics.
- Verify identity separately from ability. Institute email confirmation linked to the GitHub account closes the impersonation gap that remote hiring across borders otherwise leaves open.
Where Tierones fits
Every step above depends on having artefacts to read before you spend engineering hours. That is what Tierones assembles: an invite-only network of students at IITs, NITs and IIITs, verified through their institute email, where Tier Rank converts commits, code reviews and shipped projects into a signal that survives the AI flood precisely because it is built from work that was reviewed by other people over time. A generated résumé takes seconds; a year of merged pull requests in repositories other people depend on does not. For a small US team, that is the difference between reviewing ten real candidates and filtering four thousand plausible ones.
FAQ
Should we ban AI tools in a technical interview?
Banning is an enforcement problem you will lose. Across 19,368 interviews, 38.5% of candidates showed signs of AI use — about 48% in purely technical roles — and 61% of those flagged passed on score anyway. A ban mostly filters for willingness to comply, which is not the trait you were testing. Allow the tools openly and change what the exercise measures.
How do we tell whether a candidate understands the code they submitted?
Interrogate the code rather than the candidate. Ask them to walk through one decision and name the alternative they rejected, break a behaviour deliberately and ask them to predict the failure before running anything, or hand them a diff and ask what is wrong with it. Understanding survives those questions; unread generated code does not.
Does this mean take-home assignments are dead?
The unsupervised puzzle-style take-home is, because it can be completed in minutes and tells you nothing. What replaces it is a short paid trial on a real ticket in your own repository, judged on the pull request, the review conversation and the questions asked along the way — the same signal your team is judged on every day, and equally readable for a remote candidate abroad.
Hiring remote engineering help this quarter? Tell us what you need — we’ll show you the right 40, not the loudest 4,000.