“AI can hallucinate.”
That tells the interviewer you know the word. It does not tell them what you do when a plausible answer lands in your work.
To answer “Tell me about a time AI was wrong,” explain the observation that made you pause, the independent check you used, and the correction you owned. The useful part is your judgment, not the mistake's dramatic potential.
Why this is a useful story to prepare
ICIMS' September 2026 workforce analysis describes a gap between candidates' confidence with AI and the depth of their skills. Its August survey covered 1,000 US adults. The report's concern is distinguishing familiarity with a tool from capability in the work.
That does not prove every employer asks this question. It gives us a useful preparation task: choose a story that shows how you decide whether an AI output is fit to use.
Our AI tools interview guide covers explaining your broader workflow. This exercise goes deeper into one moment when the output needed a check.
Start with the reason you questioned it
“I always verify everything” sounds thorough. It leaves the method unclear.
What made you stop in this example? A date did not match a source. A summary merged two different requirements. A calculation disagreed with a known total. A recommendation assumed a permission you did not have.
Name the observation before explaining the correction. It helps another person understand your reasoning rather than taking your claim of diligence on trust.
Then explain the check. Asking the same tool whether it is sure is different from comparing the output with a source you can inspect. You might use a published document, an agreed requirement, or a check you can perform yourself. Describe why that check addressed the uncertainty in your example.
A fictional example from communication work
Question: “Tell me about a time you caught a mistake in AI-generated work.”
“I used an approved AI tool to draft a short internal summary from public product announcements. The draft said two features became available on the same date. I remembered one being announced earlier, so I checked the linked release notes rather than asking the tool to confirm its answer. One note described a preview; the other described general availability. The draft had treated those as the same event. I corrected the dates and wording, then asked the colleague reviewing the summary to check that distinction. We shared the corrected version. For later summaries, I added a source and release stage beside each date before drafting the prose.”
This is a fictional exercise. The candidate identifies the task, the signal that prompted a check, and the difference the check revealed. The result is a corrected summary with a reviewed distinction. There is no invented claim that the correction saved a customer relationship or prevented a launch failure.
The interesting sentence is not “the AI was wrong.” It is “one note described a preview; the other described general availability.” That is the piece of reasoning the candidate can explain.
What makes the answer stronger
A weak answer says the tool was unreliable and someone fixed it.
A credible answer identifies the unsupported output, the independent check, and the candidate's correction.
A stronger answer also explains the consequence for the workflow. In the fictional example, the candidate began separating date and release stage before drafting. That is a specific adjustment another person could understand and inspect. It does not amount to a claim that the tool will never make another mistake.
This is Revarta's editorial rubric for explaining an experience. It is not a claim about a particular employer's scoring system.
Include the limits of what you know
If the work was never published, say that. If a colleague caught the error, credit them and explain what you did next. If you cannot establish why the model produced it, do not invent an explanation of its internals.
You can describe a failure in the output without diagnosing the model: “The summary merged those two dates. I don't know why it did that. Here is how I checked and corrected it.”
Use the same care with the outcome. The results-without-metrics guide helps you keep an observable correction separate from a hypothetical benefit.
Practice one check, not a list of warnings
Use the mistake interview question. If the prompt asks about your mistake, include your own responsibility: what you accepted, missed, or changed. Do not make the tool the only actor in the story.
Say the answer aloud, then answer two follow-ups: “Why was that check sufficient?” and “What would you do if the source were unclear?” A useful response can include asking the responsible colleague rather than forcing an answer from incomplete information.
Common questions
How do I answer an interview question about a time AI was wrong?
Choose a real example. Explain what you asked the tool to do, what made you question its output, which independent check you used, and how you corrected the work. Finish with a specific change to your workflow and an outcome you can support.
What if I caught the AI mistake before anyone used the output?
Explain the check that caught it and what you corrected before use. That is a valid example of verification. Do not turn an unpublished error into an invented claim about money saved, incidents prevented, or customers protected.
Can I use a study or personal-project example of an AI mistake?
Yes, if you identify the context accurately and explain your own contribution. Show what you checked against a reliable source or known requirement. A modest example you understand is more useful than an invented workplace incident.
The story should leave the listener able to explain how you checked the work. Naming the tool is the easy part.
