Show the Error You Caught, Not the Output You Shipped

Collect the Cases, Starting Now

Start a running note today and put the next caught error in it. What an interviewer can actually rate is a specific case: what the model asserted, how you found out it was wrong, and what would have happened if you had not caught it. "Always fact-check the model" is advice everyone has already heard, and repeating it produces a claim rather than evidence.

Any of these counts. A wrong citation a model invented with real-sounding detail. A confident assumption that did not hold for your specific situation. A number that looked plausible and was off. Each entry needs three things: what was claimed, what you checked it against, and what changed because you checked. Two or three of these, kept over a few months, is more than most candidates bring to the question, because most people notice the error and move on without writing it down.

The note does not need polish. A single line per case is enough at the time: what you asked for, what came back, what looked off, and what you found when you looked. You can shape it into a full story later, once you know which case you are telling and to whom. What you cannot do later is reconstruct a detail you never wrote down, which is the usual reason a good case gets told vaguely months after the fact.

This works even with no employment history behind you. A class project, a volunteer task, something you built for yourself: the source of the work matters less than whether you can describe the check in specifics. A caught error from a school assignment, told with the same three parts, is real evidence, because the skill it demonstrates does not care where the task came from. Keep the note somewhere you will actually reopen it, a single running document works, rather than trusting yourself to remember the detail six months later when a recruiter finally asks.

Why This Is the Actual Test

Some employers now test this directly, with an exercise built for it. How do you test whether a candidate notices AI errors? describes the shape: a real task from the candidate's own field, with one error planted in the source material and an assistant that will repeat it with total confidence.

The only way to pass a test built like that is to have genuinely checked something, which is why the habit and the interview performance are not two things to prepare separately.

The stakes behind that design are real. In a 2023 Harvard Business School field experiment, consultants using GPT-4 on one task chosen to sit outside the model's capability were 19 percentage points less likely to reach the correct answer than a control group working without it. ¹ The task looked like the ones the model handles well, which is the entire danger: nothing in the answer marked it as the one to check.

Employers describe the same difficulty from their side. In Greenhouse's 2026 vendor survey of 373 hiring managers in the UK, Ireland and Germany, 37% named detecting AI-generated or heavily AI-assisted applications among their top hiring challenges. ² It is a survey by an applicant-tracking vendor, in three countries, so read it as a stated difficulty rather than a measurement of employers everywhere. Your record answers that difficulty directly: it does not ask an employer to judge a document, it hands them a specific account of a check you ran yourself.

A finished document cannot show the checking that happened before it was finished. That is why the account has to come from you, in the settings where the work is visible while it happens: a conversation about the case, a live exercise, a debrief about what you rejected and why.

Turn One Case Into an Answer

For an interview, pick your strongest case and tell it in the order an interviewer will want it: what you were doing, what the model told you, what made you doubt it, what you checked, and what the correction changed. Skip the parts about the tool being impressive or unimpressive. The interviewer is not asking about the tool.

For a resume, the same case compresses to one line: name the task, the error, and the check, in language your field already uses. Using the tool at all is ordinary rather than remarkable: in a nationally representative US survey from late 2024, 23% of employed people said they had used generative AI for work at least once in the previous week, and 9% used it every work day. ³ So the differentiator is not that you used it, it is that you can point to the one time it mattered that you checked. Say what you fixed, not what the model wrote walks through building that same story into a full interview answer, including the follow-up questions to expect once you tell it.

The one line looks like this: checked a drafted vendor comparison against each vendor's own published pricing page, found two of four figures out of date, corrected them before the document went out. Task, error, check, in that order, with nothing claimed beyond what happened. A reviewer who cares about this has a reason to ask, and you already know the longer answer.

A case that clearly cost something, hours redone, a wrong figure caught before it reached a client, a decision that would have gone differently, is worth more than three vague ones. Pick the one with the sharpest consequence you can point to honestly, even if the stakes were modest.

Do not inflate the stakes to make the story land better. An interviewer who has heard a hundred versions of this question can tell an exaggerated near-miss from a real one, and the exaggeration costs more credibility than a modest true story would have. Tell the case at the size it actually was, and let the specificity of the check do the work.

See how it works >