How to design an AI interview the person does not experience as an insult

The complaint that keeps coming up about automated interviews is almost never “a machine assessed me”. It is more specific, and fairer: nobody warned them, nobody said how long it would take, the connection dropped and they were left feeling they had lost their shot over something outside their control, and afterwards they never heard back.

None of those four things is a limitation of the technology. All four are product decisions somebody made, or that nobody made, which comes to the same thing. What follows are seven decisions that completely change how the same system is experienced, and a closing section on what none of them fixes.

Say it first, and not in small print

The person has to know they will be talking to a system before they accept, not discover it when the voice answers a little too promptly. And it has to be in the body of the message, in the same size as everything else, not in a footer that exists so somebody can later say they were told.

The disclosure loses its value the moment it is hidden. Someone who finds out halfway through stops answering the question and starts answering the surprise: they test the system instead of responding to it, and what gets recorded is no use for assessing anyone. On what else that moment before has to contain, the April issue works it through in full.

How long it takes and what will be asked

Telling people the scope up front does not make the interview less rigorous: it makes it less frightening. Someone who knows it is twenty minutes and five questions about situations from their own work manages their time, finds somewhere quiet, and arrives willing. Someone who knows nothing assumes the worst and answers with their guard up.

What is worth saying beforehand, and it takes three lines:

• How long it takes, as a number, not as “a few minutes”.
• How many questions there are and what they are about: work situations, not riddles.
• Whether a camera, a microphone, or both are needed.
• What happens if it cuts out: whether it can be resumed, and until when.
• Who will read the answers, and when they will hear back.

Illustrative example: a five-line invitation stating duration, number of questions, technical requirements and a response date produces fewer drop-offs than a two-line one carrying only the link. Not because it persuades better, but because it stops looking like a trap.

Being able to reschedule, and being able to leave

A link that expires in twenty-four hours does not filter for committed candidates: it filters for candidates with a free afternoon. The person who is currently employed — usually the one you want — needs to choose when, and needs to be able to change their mind about the timing without it counting against them.

And they need to be able to leave. An interview you cannot walk out of is an interrogation. If someone decides halfway through that they would rather not continue, the right behaviour is to let them close it, tell them what happens to what has already been recorded, and not penalise them for having tried. A process that only allows finishing collects answers from people who wanted to leave, which are answers of no use to anyone.

No trick questions, and no silence as a technique

There is a school of interviewing that believes in discomfort: the long pause that has to be filled, the question with no right answer, the change of tone mid-conversation. In a human interview those techniques are already arguable. Automated they become something else, because the system applies them every time, to everyone, without reading the room.

The argument is not a soft one, it is about validity. What a trick question measures is tolerance for discomfort, and that was not the competency anyone set out to assess. If the script is after conflict resolution, ask about a real conflict the person resolved; the rest is noise with the air of rigour. How those questions get written is the subject of the October issue.

When the connection fails, the fault belongs to the design

It will drop. There will be a microphone that never gets permission, a network that dies in minute eight, and a browser that decides to update itself. The design question is not how to prevent it, it is whose responsibility it is when it happens, and that question is answered beforehand, not in the complaint email.

The answer that holds the rest of the system up: a technical failure is never the candidate’s. It can be resumed, it is said explicitly that it can be resumed, and whatever was recorded up to that point is not used as a complete interview. A partial record assessed as if it were whole is worse than no record at all, because it looks like information.

They asked for half an hour, it cut out after ten minutes, and the link never opened again. I never found out whether that counted as my interview.

That is what a badly designed experience sounds like, and it does not have to be real to be recognisable. The corrected version fits in one sentence from the system itself: “it cut out, you have until Friday to pick up where you left off, and nothing before that is lost”.

The response time is part of the interview

Automating the first round multiplies the number of people who give half an hour to the process. If the pace of replying stays what it was, what got automated was not the assessment: it was the silence, and at greater scale.

The commitment has to be explicit and short, and it has to be honoured even when the answer is no. It is the only thing that turns a high-volume process into something people are willing to accept again. Someone who answered and found out where they stood within a week can apply again next year; someone who heard nothing will not.

What can be given back to someone who does not advance

Care is needed here, because good intentions break quickly. A system that assesses by competency can indeed give back something better than an empty form, but not everything it could say is worth saying, and not everything said is defensible.

1. Say what was assessed, always. The competencies in the script are not secret, and knowing them helps the person understand what was being looked for.
2. Say where the process found the least evidence. Carefully: less evidence in one interview is not less capability, and the sentence has to say so.
3. Do not return the numeric level or the comparison against other candidates. That is a fact about the internal process, not about the person, and in isolation it reads as a verdict on them.
4. Do not promise explanations that cannot later be supported. If someone asks, a person answers, and that person has to be able to reach the fragment behind each conclusion.

A system that keeps the evidence turn by turn can hold that conversation. One that kept only a score cannot: it will end up answering with a generic paragraph and hoping nobody presses.

What this does not solve

None of these seven decisions makes a person enjoy being interviewed by a system. Some will always prefer a conversation with somebody, and that refusal is legitimate: what can be avoided is their also feeling misled, rushed or ignored.

Nor do they fix a process that does not know what it is looking for. A flawless experience over a badly defined role only ensures more people waste their time with better manners. And they do not replace the duties of disclosure and consent, which are a different matter and are dealt with in the security and data position.