Technical rounds get most of the preparation time, and then a behavioural question arrives: "Tell me about a time something you built didn't work." You start with the background, add a second background, and two minutes later you haven't said what you did.
This post gives you a behavioural interview AI engineer STAR story kit: a template, six story slots tailored to LLM work, a worked example that is clearly fictional, and a score sheet to grade your own recorded answers. It doesn't quote any company's real questions or any hiring statistics, and I haven't interviewed anyone for this post. The structure is a communication pattern, and the stories have to come from your own work.
If a take-home is part of your process, how to approach an AI take-home pairs with this. For the technical side, use the mock interview script and score sheet. For the project walkthrough specifically, see how to explain a RAG project in an interview.
What is the STAR method, in plain terms?
STAR stands for Situation, Task, Action, Result. It's a way to keep a story answerable: where you were, what you were responsible for, what you did, and what happened. Two additions make it work for AI engineering: put numbers or evidence in the Result, and finish with what you'd change.
| Part | Seconds | Contains | Common mistake |
|---|---|---|---|
| Situation | 15 | Setting, in one or two sentences | A long backstory |
| Task | 10 | Your specific responsibility and the constraint | Describing the team's goal, not yours |
| Action | 60 | 3 or 4 things you did, with the reason for each | "We" throughout |
| Result | 25 | Outcome with a number, or an honest "unclear, here is how I checked" | "It went well" |
| Reflection | 10 | One thing you would change | Skipping it |
Action is the heart of it. A good test: could the interviewer repeat back what you personally decided?
The template to fill in
Write each story in this shape. Keep it in a note, not in your head.
HEADLINE (6 words): ____________________
SITUATION: [Where, what system, who depended on it]
TASK: [What I was responsible for, and the constraint: time, cost, quality]
ACTION:
1. I [decision], because [reason].
2. I [decision], because [reason].
3. I [decision], because [reason].
RESULT: [Measured outcome, how measured, date range]. If not measured: [what I could and could not tell]
REFLECTION: [One thing I would do differently]
NUMBERS I CAN DEFEND: ______ (and how each was obtained)
FOLLOW-UP I FEAR: ______ (and my answer)
The last two lines matter most. Interviewers push on numbers, and the "follow-up I fear" prompt forces you to find the soft spot before they do.
Which six stories should an AI engineer have ready?
Pick one real story for each slot. The same story can cover multiple questions, so don't force six unrelated ones.
| Slot | Typical question wording | What a good story shows | Where to find a story |
|---|---|---|---|
| 1. A failure in a model-backed system | "Tell me about something that didn't work" | Diagnosis, not blame | A retrieval bug, a prompt that regressed, a bad parser |
| 2. A quality disagreement | "A time you disagreed with a stakeholder or teammate" | Using evidence instead of opinion | Eval results vs a manager's impression |
| 3. A trade-off decision | "A difficult technical decision" | Options, criteria, outcome | Model choice, chunk size, build vs buy |
| 4. Ambiguity | "A vague or changing requirement" | Clarifying, scoping, setting a bar | A request like "make it smarter" |
| 5. Cost or speed pressure | "Delivering under constraints" | Measuring, then cutting | Cutting tokens, caching, smaller model |
| 6. Learning something new fast | "Something you had to learn quickly" | A method, not just enthusiasm | Picking up a framework, reading a spec |
If you're early in your career and have no work stories, personal projects and open-source contributions are fine, with honest framing. The project plan for backend developers builds a project designed to produce stories in slots 1, 3 and 5, because week 7 forces a diagnosed failure and week 6 forces a cost and latency measurement.
Worked example (fictional)
The story below is invented to show the shape. The person, company, numbers and events are made up; do not copy them as your own experience. Notice how it would be rejected if the numbers were not defensible, and how the Action section names decisions rather than tools.
Headline: Fixing a support bot that ignored good context
Situation. A fictional support assistant at a small invoicing software company answered questions from help-centre articles. Customers had started reporting confident wrong answers about refund timelines.
Task. I was the engineer responsible for the answer quality of that feature, with two weeks before a planned wider rollout and no budget to change the model provider.
Action.
- I collected the 35 complaint transcripts and labelled each one: was the right article retrieved, and did the answer use it? I did this before changing anything, because I wanted to know whether the fault was retrieval or generation.
- The labels showed that in 21 of 35 cases the correct article was in the retrieved set but the answer contradicted it. So I stopped tuning chunk size, which was my first idea, and looked at the prompt.
- I found the prompt told the model to "be helpful and concise" and never said to prefer the retrieved text over its general knowledge. I rewrote it to require quoting the sentence it relied on and to say "not found" otherwise.
- I added the 35 transcripts plus 15 new questions to a regression set so the fix could not silently undo itself, and agreed the pass bar with the support lead before running it.
Result. On the 50-question set, correct answers rose from 29 to 41, and "not found" was returned on 4 of 5 deliberately unanswerable questions. One regression: answers got longer, and the support lead asked for a length cap, which I added. I'd caution that 50 questions is a small set, so I reported the change as clear but not precise.
Reflection. I'd have built the labelled set in week one instead of after the complaints. It would have caught this before customers did.
Numbers I can defend: 35 transcripts (from the ticket system), 21 of 35 (my labels, a second person checked ten), 29 to 41 of 50 (my harness, one run each at fixed settings).
Follow-up I fear: "How do you know the second labeller agreed?" Answer: I'd report we agreed on 9 of 10 and that I'd widen the check with more time.
Why this works: the Action describes decisions with reasons (why not chunking, why a regression set), the Result includes an honest caveat, and the reflection is specific. Why it could fail: if you can't answer the follow-up, or the numbers were invented, the whole story collapses. That is why the "numbers I can defend" line exists.
How do I turn a messy memory into a clean story?
Use a model as an editor, not an author. It will happily invent details. This is an untested template; I haven't run it against a live model for this post, so check the output line by line.
Below are my raw notes about something I did. Turn them into a STAR
outline using these headings: Situation, Task, Action (3 numbered
decisions with reasons), Result, Reflection.
Rules:
- Use ONLY facts in my notes. If something is missing, write
"[MISSING: what is needed]" instead of guessing.
- Do not add numbers, tools or outcomes I did not state.
- Keep "I" for what I did and name teammates separately.
- Then list the three follow-up questions an interviewer is most
likely to ask about weak spots, based on the notes only.
NOTES:
[paste]
The [MISSING] instruction is what keeps the output honest. If your outline comes back with no missing items, check whether the model quietly filled a gap. Also remove anything confidential before pasting: employer names, customer data, unreleased details. If you are unsure what is safe, what not to paste into ChatGPT is a useful checklist.
Rehearse and self-score
Record yourself answering each story out loud, then score the recording. Use this sheet, 0 to 2 per row.
| Row | 0 | 1 | 2 |
|---|---|---|---|
| Opens with the situation in under 20 seconds | Long backstory | Slightly long | Tight |
| Clear on what I did | "We" throughout | Mixed | Named my decisions |
| Gives a reason for each action | None | Some | Each action |
| Result is checkable | Adjective only | A number, unclear source | Number plus how measured |
| Admits a limit or caveat | None | Vague | Specific |
| Ends with a specific change | None | Generic | Concrete |
| Under 2.5 minutes | Over 3 | 2.5 to 3 | Under 2.5 |
Out of 14. Below 9, rewrite the story. Between 9 and 12, tighten the weak rows. Above 12, stop polishing and practise delivery. The bands are my own rule of thumb.
Then get one human to listen to one story and say where they got lost. A model can score the text, but it can't tell you that your pace doubled when you reached the failure.
Common traps in AI engineering stories
- Tool lists in place of decisions. "We used LangChain, Pinecone and GPT-4" says nothing about your judgment.
- Claiming team results as yours. Name the team, then isolate your part.
- Quality claims with no measurement. "Users liked it" with no evidence invites the question "how did you check?"
- Blaming the model. "The model hallucinated" is a symptom. Say what you found when you inspected the inputs.
- A failure with no fix, or a fix with no verification. The shape to aim for is symptom, diagnosis, fix, check, safeguard.
- Unclear confidentiality. Describe the problem without naming customers or revealing internal data. Ask yourself whether you'd be comfortable if your employer read the transcript.
A short plan for the week before
- Write six stories using the template (about 20 minutes each).
- Record each once, score it, rewrite the two lowest.
- Pair stories with your technical material: your project's failure story can be the same incident as the one in your portfolio README failures section, told with different emphasis.
- Run one full mock with both technical and behavioural questions, then fix the lowest row.
- For tailored question lists from your CV and a job post, the AI interview prep prompts give a starting point.
The goal isn't a script you recite. It's six stories you know so well that you can choose the right one in a few seconds and tell it plainly.
