Candidates have always prepared for common interview questions with articles, books, and coaching. Now AI can improve a résumé in minutes, generate stories tailored to a role, suggest answers, and help solve a case.
That is not automatically a problem. I would not treat AI use itself as suspicious. The real problem starts when the tool helps someone present competence they do not actually have.
A Perfect Answer Is Now a Weak Signal
Answers such as “I would gather requirements, prioritize the work, align stakeholders, and measure the outcome” sound sensible. They are also easy to generate for almost any management question.
So I would spend less time judging the quality of the first sentence and more time watching what happens after it.
A good interviewer should be able to break a prepared answer.
Go Deep Into Real Experience
When a candidate tells a successful story, do not immediately move to the next question. Stay inside that story.
What did they personally do? Who disagreed? What other option was considered? What turned out to be harder than expected? Where were they wrong? What had to change a month later?
Real experience is usually uneven. It contains constraints, awkward trade-offs, people with different interests, mistakes, and details that are difficult to invent consistently on the spot.
A generated story often remains smooth until the second and third layer of questions begins.
Change the Constraints During the Conversation
If you give the candidate a case and receive a very neat solution, change one condition.
The budget is cut in half. The deadline becomes three months instead of a year. A key employee leaves. The CEO disagrees. The data quality is poor. The existing system cannot be replaced.
Someone who understands the solution will reshape it. Someone who only received a good answer often keeps defending the original structure even after it no longer fits the problem.
Ask for the Reasoning, Not Just the Result
The correct answer matters less than the path to it.
Why did you start there? Which options did you reject? What information is missing? What is the biggest risk in your proposal? Under what condition would you choose the opposite approach?
Those questions are good at separating understanding from reproduction.
Return to the Same Story from Another Angle
You do not need to turn the interview into a trap. Simply return to the same situation later from a different perspective.
First ask about the project result. Later ask about a conflict in the team. Then ask about a technical or financial trade-off in that same project.
If the story is real, the pieces usually fit together. If it is heavily inflated, strange gaps begin to appear: the candidate's role changes, their level of ownership shifts, or the reasons behind decisions stop matching.
Do Not Confuse Speed with Strength
A short pause before answering a difficult question is normal. Sometimes it is more useful than instant confidence.
If someone immediately produces a perfectly structured answer to every unexpected question, I would not automatically assume they are using assistance. But I would definitely test the logic and details more deeply.
The point of the interview is not to detect technical signs of AI use. Those signs are unreliable. The point is to understand who owns the thinking.
Live Coding Is Not a Simple Guarantee Either
For technical roles, live coding used to feel like a straightforward way to verify competence. But the format does not solve the problem if the interviewer only evaluates the final output.
The more useful discussion is around decisions: why this structure, where the risk is, what happens under higher load, how to test a failure, and what changes when a new constraint appears.
A strong engineer can use AI and still understand every line. A weak engineer can write everything manually and still make poor decisions.
Using AI and Cheating Are Not the Same Thing
I would not build a hiring process around banning AI. In real work, we often expect people to use good tools effectively.
If a candidate openly says, “I used AI to prepare the structure, then checked and reworked it,” that can be perfectly reasonable professional behavior.
The boundary is not whether a tool was used. The boundary is whether the person can take responsibility for the result.
Change the Interview Instead of Increasing Surveillance
You can require a second camera, ask candidates to show their desk, and close every application. That quickly turns hiring into a bad exam and still does not guarantee that you are measuring the right competence.
It is more useful to redesign the interview itself: fewer standard questions, more real experience, changing constraints, follow-up questions, and discussion of decisions.
In the AI era, a strong candidate is not someone who answers without tools. It is someone who understands the answer well enough to explain it, change it when conditions change, and take responsibility for the outcome.