August 3, 2026·4 min read
You open the interview to AI tools. The candidate uses Claude throughout. They submit working code.
And you still do not know if you should hire them.
That is a design problem, not an AI problem.
Prompt speed. The candidate who types fast, iterates fast, and submits fast looks good on the surface. But the thing you are hiring for - judgment about what to build, what to question, what to skip - never surfaces.
The output is not the interview. The decisions behind the output are.
Poison one step. Design the task so that Claude's obvious answer is wrong for a reason the model cannot know: a security assumption, a performance constraint specific to the codebase, a style rule the team enforces. A candidate with judgment catches it. One without ships the bug and does not notice.
Ask for the rejection. After the session, ask: "Was there anything Claude suggested that you did not use? Why?" A strong candidate has a specific answer. A candidate who accepted everything without question does not know how to answer that.
Force verification. Include a step where the correct answer requires actually running something: a test, a curl, a log check. Claude can suggest the command. It cannot interpret what comes back. Watch whether the candidate does.
Add a choice Claude cannot make. Include a decision point where two approaches are both technically valid but one fits the codebase better. That requires reading existing code, not prompting. AI fluency does not help here. Engineering judgment does.
The cleanest way to measure how much a candidate contributes on top of AI is to run the same task in two separate sessions: one with Claude available, one without.
You are not trying to catch AI use. You are trying to understand the gap. If the results are similar, the candidate brings real skill. If the AI-closed session is dramatically weaker, that is the skill floor you are actually hiring.
EasyEnv lets you set up both sessions under the same role. A senior reviewer can compare the recordings in fifteen minutes and see exactly where Claude was doing the thinking versus where the candidate was.
What would your current interview reveal if Claude was in the room the whole time?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Two engineers interview the same candidate and reach opposite verdicts. That disagreement is usually a measurement problem, not a candidate problem. Here is where scoring drift comes from and how shared rubrics and recorded sessions calibrate a panel.
A backend engineer's real job is mostly reading and changing code they did not write. So test that. Drop a candidate into an unfamiliar repo with a bug ticket and watch how they navigate. Here is what good looks like and how to score it.
Read more
A security trivia quiz cannot tell a real practitioner from a certificate collector. Give a candidate a real, vulnerable box and watch them find and fix the weakness. Here is how to scope it safely and what to score.
Read more
