How do I interview when candidates are using AI?

“I’m rejecting all of those candidates the instant I notice”

That was the first policy of the manager quoted at the top, and it is the wrong fix for three reasons. You lose the good candidates who used AI to prepare and are now nervous and reading their own notes, because from your side of the camera that looks the same. You keep the candidates who are better at hiding it, which is the opposite of the skill you are hiring for. And, as the thread worked out, you do not actually object to the tools: the same manager clarified that it was never about whether someone uses Cursor or Claude at work, and everyone will. The objection is to answers that are not theirs.

So the goal is narrower than “catch AI use.” It is to run an interview where the answers you score could only have come from the person in front of you. That is a change to the questions, not a change to your monitoring.

“Tell me about the project you’re most proud of”, then dig in

The follow-up is the test. An overlay can produce a fluent first answer to almost anything. What it cannot produce, live, is the specific sequence of what one person did on one Tuesday, why they chose it over the alternative, who they called for help, what the number was afterwards, and what they got wrong. Those live in the candidate’s memory or nowhere, and a candidate who is reading answers from a screen has to wait for each one, then gets a plausible generality instead of a fact. By the fourth follow-up the difference is obvious to anyone.

There are seven directions a follow-up can go. Here is the question for each, in words you can use as they are.

You will not use all seven on every answer, and you should not force it. The point is that when the first answer sounds too clean, you know exactly where to go next instead of nodding and moving on. How to ask follow-up questions covers the framework in depth and what each dimension tells you about a competency.

A worked sequence: account executive

The candidate and the deal are invented; the shape of the sequence is the point. Each step gives the question and what to listen for.

1. 1. “Tell me about the deal you are most proud of.”

   The first answer is the one a model can write: a complex enterprise deal, multiple stakeholders, consultative approach, closed above target. Do not score it yet. It is the opening, not the evidence.

2. 2. “Which company was it, what do they sell, and who was your first contact there?”

   A real answer names a company, an industry, and a job title, and does it quickly. An answer that stays at "a mid-sized logistics firm" and "a senior stakeholder" is a flag, not a verdict. Keep going.

3. 3. “What did you do in the week after that first call?”

   You are asking for actions in order. The candidate who did the work says something like: sent a recap, asked for an intro to the operations lead, built a one-page cost estimate. The candidate reading an answer gets a summary of a sales methodology.

4. 4. “Why go to the operations lead instead of staying with your champion?”

   This is the judgment question. A real reason is specific to that deal: the champion could not sign, the budget sat in operations, the champion asked for it. There is no general answer, which is why this one is hard to fake live.

5. 5. “Who else worked on it, and what did they do that you could not?”

   Listen for named help: a solutions engineer who ran the technical review, a manager who approved a discount. A candidate who did everything alone on a complex deal either is exceptional or was not on the deal.

6. 6. “What was the contract worth, and how long did it take from first call to signature?”

   A number and a duration, said without hesitation. If the number moves during the conversation, ask about the move.

7. 7. “What would you do differently, and where have you done it since?”

   The last two dimensions together. A real deal leaves a regret (brought in the operations lead a month too late) and a habit (now asks about budget ownership on the first call). Ask for the next deal where the habit showed up.

Seven questions, maybe twelve minutes. Nowhere in that sequence did you accuse anyone of anything, and nowhere did an overlay have anything useful to offer. A candidate who lived the deal finds the questions easy and rather enjoys them. That is the tell you want: the interview gets easier for the real candidate and harder for the one reading.

The same sequence for an engineer

1. 1. “Tell me about the project you are most proud of.”

   Again, the first answer proves nothing either way. A migration, a rewrite, a system that handled more load. Note it and go in.

2. 2. “What was breaking before you started, and who was feeling it?”

   Situation. A real answer has a symptom (timeouts on the checkout page every Monday morning) and a person who complained about it.

3. 3. “What was the first change you shipped, and why that one first?”

   Actions and reasons together. Ordering is where reading from a prompt falls apart: a model can describe a good architecture, but it cannot tell you why this team did step three before step two.

4. 4. “What did you get wrong along the way, and how did you find out?”

   Every real project has one. Listen for how they found out (an alert, a customer, a colleague in review) and what they did in the hour after.

5. 5. “Who reviewed it, and what did they push back on?”

   Help used. Named reviewers and a specific objection. A project with no pushback is usually a project the candidate watched rather than led.

6. 6. “What were the numbers before and after, and what would you change if you did it again?”

   Results and lessons. Latency, error rate, cost, deploy frequency, whichever one the project was for. Then the regret, and where they have applied it since.

For a customer support lead, an operations manager or a marketer, swap the nouns and keep the order: the state of the queue when they arrived, the first change, why that one, who helped, the number afterwards, the regret, the habit. The framework does not care what the work was, only that the candidate did it.

“How do I stop AI-written applications getting through?”

You mostly do not, and you do not need to. Detecting AI-written text is unreliable in both directions, and a well-written application has never been evidence that someone can do the job. What you change is how much weight the application carries.

Add two or three screening questions to the application form with a fixed answer: a yes/no on a certification the role requires, a multiple-choice on the shift pattern, a number for years in the specific role. A candidate answers them when they apply, and an application that misses the answer you set is marked in your queue so your team sees it at a glance and decides what happens next. That is a plain rule, and it catches the mass-sent application that never read the posting.

Then review the queue against the criteria you wrote for the role, rather than against how well the letter reads. In Yardstick, application review scores each incoming application against the job-related criteria you defined, so you read the likely fits first and spend the interview hours on them. The interview, with the follow-ups above, then does the work the application cannot.

“Do I need proctoring software?”

For a small team, no. Proctoring tools watch a screen for a second window and a face for a wandering gaze, and they produce a probability that you then have to act on. A live conversation about the candidate’s own work, followed along the seven dimensions, with the same questions for every candidate, does what the detector claims to do and produces evidence you can compare instead of a suspicion you cannot. It also works for the roles where there is no screen to watch, which for most companies is most of the roles.

Frequently asked questions