Should candidates be allowed to use AI in an interview?

The question usually arrives as a binary, and both answers are wrong. Ban the assistant and you get a clean, comparable exercise that measures a working style almost nobody has used since the tools became good. Leave it unmonitored and you get a session in which you cannot tell what the candidate did from what the model did.

There is a third option, and it is less a compromise than a different exercise: put the assistant inside the task, record the session, and assess how the candidate directs it.

Why banning it is a fiction

An interview is a sample of work under observation. If the observation changes the work enough, you are no longer sampling the job. You are sampling a variant of the job that exists only in interviews.

Consider what a ban actually enforces. It enforces that a candidate can produce working code for an hour, from memory, with someone watching, without looking anything up. That is a real skill — a genuinely useful one for people who work without a network or who maintain systems where every dependency is a liability. It is also nothing like the normal condition of most engineering jobs, where the reality is a large unfamiliar codebase, an unclear requirement, and a capable assistant in the next pane.

So you hire on the basis of a skill the job will not use, and reject people who are good at the thing the job is actually made of. That is not rigour. It is nostalgia with a rubric attached.

There is a fairness argument too, and it cuts both ways. A ban is easy to state and nearly impossible to enforce: the candidate is on a video call, in their own home, with a second window. Candidates who follow the rule are disadvantaged against candidates who quietly do not, and the ones who quietly do not are not necessarily the less scrupulous engineers — they may simply be the ones who assumed everyone was doing it. A rule nobody can verify does not produce fairness. It produces a lottery with a story attached.

Why allowing it untracked is worse

If you permit the assistant but do not record the session, you have removed the constraint and kept the measurement. The output might be excellent, and you will have no idea why.

You cannot tell whether the candidate understood the solution or received it. You cannot tell whether they checked it. You cannot tell whether the plausible-looking bug in it was theirs or the model's. And you cannot tell, when they describe the work afterwards, whether they are describing something they did or something they read a minute earlier.

The strangest version of this is the take-home task, where the candidate has days and no supervision at all. Whatever you are measuring there, it is not the candidate's unaided ability, and pretending otherwise wastes everybody's time.

Make the assistant part of the exercise

Treat the assistant as an instrument the candidate is expected to use, and make its use visible. In practice that means three things.

• A task the assistant helps with but cannot finishIf the model can produce the entire answer from the brief alone, you are measuring the model. Choose something with a constraint the assistant cannot see: an existing pattern in the codebase, a requirement that conflicts with another requirement, a failure that only appears on one path.
• A recorded session, assistant conversation includedThe candidate's messages, the replies, the order, the timestamps. This is the evidence. Without it, everything else in the exercise is decoration.
• A candidate who knows the record will be readNot to make them nervous, but because someone who expects their transcript to be read uses the tool differently — more deliberately, with more checking — which is closer to how a careful person works anyway.

What you are actually looking at

Four things, and none of them require you to know the stack.

• What they ask forNarrow, specific questions suggest someone driving a tool. A single instruction to write the whole thing suggests someone hoping to be driven by it.
• What they verifyWhether they run the code, read it line by line, test the boundary the assistant ignored, or paste it and move on. Verification is the whole difference between using an assistant and being used by one.
• Whether they catch it being wrongAssistants assert invented functions with total confidence. A candidate who stops, checks the documentation, and says “that method does not exist in this version” has just shown you the thing you actually wanted to know.
• What they do when it failsThe assistant gets stuck, contradicts itself, or loops. The response to that moment is arguably the most informative part of the session: do they narrow the question, change approach, go to the documentation, or rephrase the same request and hope for a different answer?

These are judgements about method rather than about syntax, and method is what transfers between projects. A candidate who works this way on an unfamiliar problem will work this way on yours.

What this cannot tell you

It is worth being blunt about the limits, because the fastest way for a method to lose credibility is to claim more than it can carry.

It cannot measure years of experience. A well-run session tells you how someone works on a bounded problem. It does not tell you whether they have spent years on production systems that fail at three in the morning, or whether they have carried a technical decision through two quarters of consequences. Experience leaves marks, but the marks are not always visible in an hour, and a fluent session is not the same thing as a long one.

One short task does not settle seniority. Seniority is a claim about scope, ambiguity, and the size of the blast radius a person can be trusted with. A short task can show how someone handles a small ambiguity. It cannot show how they handle a quarter-long one, or whether they will tell you the project is going badly while there is still time to change course.

It is a sample, and it should be described as one. The honest framing is: here is how this person worked on this problem, on this day, with this tool. That is more than an interview gives you and less than a probation period. It is also enough to change a decision that would otherwise have been made on a feeling.

None of that is an argument against the method. It is the difference between a report you can rely on and a report that overstates itself, and the second kind is how hiring processes acquire a reputation for confidence they have not earned.

What to do with the answer

The point of allowing the assistant, and recording what happens, is not to catch people out. It is to see the thing you actually care about: whether someone can take a difficult, half-specified problem, use every tool available to them, and end up with something they understand well enough to defend.

That is a testable skill. It is also much closer to the job than anything you can ask across a table in thirty minutes.