The take-home coding test had a reasonable run as an interview format: it let a candidate work without interview-room pressure, and it produced a work sample closer to real conditions than a whiteboard exercise. AI coding assistants have quietly broken the assumption underneath it: a take-home test now measures a candidate's ability to prompt a model competently at least as much as it measures their own coding ability, and there's often no reliable way to tell which one produced the result.
The instinctive fix, banning AI tools during the assessment, solves the wrong problem. Almost every engineering job a candidate is being screened for will have them using AI coding assistance daily once hired. Testing someone's unassisted coding ability in isolation measures a skill that's decreasingly close to the actual job.
What's worth testing instead
The more useful question isn't whether a candidate can produce working code without help. It's whether they can direct, evaluate, and correct AI-assisted output competently, which is closer to what the role will actually require. That points toward interview formats built around reviewing and debugging AI-generated code, explaining why a specific approach was chosen over an alternative the tool also offered, or extending an existing codebase in a live setting where the reasoning is visible in real time, not just the final diff.
The harder part to assess
This shifts real interview weight onto judgment and communication: can the candidate explain their reasoning, catch a subtle bug in output they didn't write themselves, push back on a suggestion that's technically valid but wrong for the context. Those are harder to assess reliably than "did the tests pass," which is exactly why they got under-weighted in interview processes built for a pre-AI-assistant world. They're also, increasingly, the actual differentiator between candidates who look similar on paper.