The Interview Spine · Chapter 12 of 13
AI in the interview, and what the cheating data shows
Three published positions rather than two, a controlled experiment on whether cheating is detectable, and the question construction that actually changed.
This is the fastest-moving part of hiring and the part where circulating advice is most often wrong. The evidence below is unusually good: published company policies on one side, and a controlled experiment with a control group on the other.
What the controlled experiment found
An interview platform ran an experiment: candidates were instructed to cheat with a chatbot, and were selected for motivation and familiarity with the tools. Thirty-two usable interviews, with a non-cheating platform baseline as the control.
| Question type | Pass rate |
|---|---|
| Verbatim from a public problem set | 73% |
| The same problem, lightly modified | 67% — not statistically different from verbatim |
| Fully custom, with genuinely novel inputs and outputs | 25% |
| Honest control group | 53% |
Three findings, each of which contradicts a piece of common advice.
“Add a twist to a public question” does not work. Verbatim and modified were statistically indistinguishable. Only a genuinely novel problem moved the number — and it moved it below the honest baseline, meaning a truly custom question is harder with a chatbot than a public one is honestly.
Interviewers did not notice. Not one of the thirty-two interviewers raised a concern about cheating, despite being prompted several times to flag problems — and they rated themselves confident in about 72% of their decisions.
The candidates knew they were safe. Around 81% of them reported no worry about being caught.
So “an experienced interviewer can tell” is not supported, and it is worth retiring. In a practitioner survey of interviewers, only about one in nine said their employer used any detection tooling at all.
What actually changed in the questions
A survey of interviewers, most of them at large technology companies, found: about a third had caught someone; four in five suspect AI use; roughly three in five had changed the kind of question they ask; and about a third changed how they ask — more follow-ups, more ‘why’, re-asking an earlier question differently, probing ‘what does this line do’.
And a finding that contradicts the loudest claim in this space: not one respondent at a large technology company said their employer had moved away from algorithmic questions. The algorithmic interview is not dead. What changed is how the questions are built:
- Custom, not modified — genuinely novel inputs and outputs, not a reskinned public problem.
- Longer, multi-part and more ambiguous, with several sub-parts. Interviewers describe questions that are problem-solving heavy rather than coding heavy, and deliberately use terminology and abstractions the models have seen less of.
- Comprehension over production. This is the clearest convergence across companies: reading and debugging an existing multi-file codebase rather than writing a function from a blank editor. The rationale one employer publishes is simply that engineering work involves far more code reading than code writing.
- And companies that never went puzzle-heavy did not have to change anything — pair programming and production-code rounds already assessed the right things.
What an AI-assisted round actually scores
Canva publishes its rubric in full — the only employer that does — and it is worth knowing because the dimensions are not the obvious ones. Three axes:
Engineering problem-solving — decomposing ambiguous requirements, making scope calls, handling edge cases, keeping business context in view.
Technical depth and ownership — stated as a question: do you understand and own the code in your solution? Producing code you cannot explain is the failure, not a virtue.
AI collaboration effectiveness — accelerating the right tasks while keeping technical control, and critically evaluating what comes back.
Their named failure modes are the useful part. The showcase, performing prompt mastery instead of solving the problem. The marathon, accepting output quickly to maximise features. And hands-off, delegating wholesale.
And the counterintuitive result: candidates with minimal AI experience often struggled — not because they could not code, but because they lacked the judgement to guide the model or to notice when a suggestion was poor. Where AI is expected, never having worked this way is now the disadvantage.
On take-homes: what died is the algorithmic take-home, which a model solves instantly. Project-based take-homes are alive and are published as a formal stage by several employers. Notably, two-thirds of startup interviewers reported AI had meaningfully changed their process against essentially none at the largest companies — so ‘the industry has changed’ is really ‘startups changed’.
And on in-person interviews, which are widely over-reported as a return: Google states it is selectively reintroducing them for some roles, as final rounds after virtual screens — with a pilot that included Bangalore in its first wave. Microsoft's own page states plainly that its process is entirely virtual. OpenAI is virtual by default with onsite as the candidate's option. “Everyone is going back in person” is not supported by what companies actually publish.
Check yourself