“Tell me about a project you built.” The candidate talks for six minutes. Every library gets named, in the order they were installed. The interviewer writes one line in their notes: “lots of tools, unclear what they decided.”
The behavioral round is often thought of as the soft one. In an AI loop it is where a reviewer tests whether you can explain a decision, own a failure and tell the truth about a number. This is Part 5 of the AI Engineer Interview Prep series, following the portfolio lesson. That lesson built the evidence. This one shows how to say it out loud.
- You have one project with a number and a failure log, such as the one from the portfolio lesson.
- You can say what the project does in one sentence.
What three things must each layer of a portfolio project have? Something that runs, one measured number, and one failure. This lesson reuses all three as the spine of your answers.
- Open with the problem, not the stack. The libraries are details; the decision is the story.
- Use six steps and about two minutes for any “walk me through a project” question.
- Keep a story bank of four or five stories and reframe them, instead of memorising twenty answers.
- Say what you did, not what the team did. Be honest about what was personal work.
- A failure told plainly is a strength. Blame and vagueness are the weaknesses.
Present a project in two minutes using six steps, prepare four stories that cover the common behavioral questions, and answer failure and trade-off questions without blaming or hiding.
What does the behavioral round actually test?#
It tests judgment and honesty under questions that have no single correct answer. Four things are worth preparing for: whether you own outcomes, whether you can explain a trade-off, whether you learn from data, and whether you can talk to people who are not engineers.
AI work raises the stakes on all four. Models are non-deterministic, so the same input can give different results. Anthropic’s team notes that agents make dynamic decisions and are non-deterministic between runs even with identical prompts. That makes “how do you know it works?” a people question as much as a technical one.
| What they probe | Junior answer that passes | Senior answer that passes |
|---|---|---|
| Ownership | Describes the task they were given | Says what they chose and what they were accountable for |
| Trade-offs | Names a pro and a con | States what they gave up and why it was worth it |
| Failure | Admits a bug | Explains the cause, the cost and the change that stuck |
| Communication | Uses the right terms | Explains it so a non-engineer can decide |
The two-minute walkthrough#
For “tell me about a project”, use six steps. The times are a rehearsal target, not a rule. They add up to 120 seconds.
Step two is where many candidates lose points by overbuilding. Anthropic recommends finding “the simplest solution possible” and adding complexity only when needed. Saying that you started simple, and what made you add each part, sounds like experience.
Step three is the number from your portfolio project, with its setup and what it does not show. Step four is the failure from your log.
The running example#
Use the support assistant from the portfolio lesson: it answers questions from help documents and can issue small refunds. In the model answers below, square brackets mark facts only you can fill in. Do not copy a number you did not measure.
Behavioral questions: weak vs strong answers#
Tell me about a project you built#
“I built a RAG chatbot with LangChain, Chroma and the OpenAI API, and then I added an agent and deployed it.”
“Support teams were answering the same questions from a help center, so I built an assistant that answers from the docs and can issue small refunds. I started with plain retrieval and only added an agent when the refund step needed tools. On [N] real questions the hit rate moved from [x] to [y] after I changed how the documents were split. The worst bug was a double refund, which I fixed with an idempotency key and a step cap.”
The follow-up: “Why not just a workflow?” The strong answer already says it: the refund step varied enough to need a tool, and the rest stayed simple.
Tell me about a time an AI feature gave a wrong answer#
“The model hallucinated sometimes, so we told it to be more careful in the prompt.”
“A test question about annual refunds returned the monthly policy. I read the full trace and saw the right document never came back, so it was retrieval, not the model. I split the documents on headings, re-ran my [N] questions, and the hit rate went from [x] to [y]. I added that question to the regression set so it cannot return quietly.”
The follow-up: “How did you find the cause?” By reading the trace. Anthropic’s team reports that full production tracing let them diagnose why agents failed and fix problems systematically.
Blaming a teammate, the tool or the data without saying what you did. Interviewers are checking whether you take ownership, and “the model did it” is not an action.
Tell me about a disagreement over a technical trade-off#
“My teammate wanted a bigger model. I thought it was a bad idea, and eventually they agreed.”
“A teammate wanted a larger model for every request. I proposed measuring first: I ran our [N] real questions on both and compared score, cost per run and delay. The larger model gained [x] points and cost [y] times more, so we used it only for the hard cases. We kept the cheaper one as the default.”
The follow-up: “What if the data had favoured them?” Then you switch and say so. Changing your mind because of data is a strength worth showing.
How do you work when the requirements are unclear?#
“I ask questions until it is clear, then I build it.”
“I write down what ‘good’ means before building: a few example questions with the right answers. That gives the team something to agree on and gives me a test. For the support bot, nobody could say what an acceptable answer was, so I collected [N] real tickets and we argued over those instead. Then I built the smallest version and measured it.”
The follow-up: “What if they will not agree on the examples?” Ship the narrowest version both sides accept and treat the disagreement as the next experiment.
Tell me about a time data changed your mind#
“I thought a bigger chunk size would help, and it did.”
“I expected larger chunks to help retrieval. The hit rate on my [N] questions dropped from [x] to [y], because longer chunks mixed topics. I went back to smaller chunks with overlap and kept the measurement in the repo so the next change gets compared against it.”
The follow-up: “What would have convinced you earlier?” A small test before the change. This is the point of the evals lesson in this series.
How do you explain model limits to a non-technical stakeholder?#
“I explain how the model works so they understand why it makes mistakes.”
“I skip the mechanism and talk about decisions. ‘It answers correctly about [x] of 10 on questions like these. It is weakest on [kind], so for those it hands off to a person. We can raise the number if we add [thing], at this cost.’ That gives them something to approve instead of a lecture.”
The follow-up: “They want perfect accuracy.” Say plainly that no measured system is perfect, show where the errors go, and agree on what happens when it is wrong.
What would you do differently?#
“Nothing major. It worked well.”
“I would build the golden set on day one. I added it late, so early changes were judged by feel. I would also log every tool call from the start, because I lost time rebuilding what happened in one bad run.”
The follow-up: “What did that cost you?” Give the honest cost in time. A real regret with a real cost is more believable than a polished answer. Anthropic makes a related point about evals: you will not know whether graders work unless you read transcripts.
Build a story bank, not twenty answers#
You do not need an answer for every question. You need four or five stories, and the skill to start each from a different angle.
A good bank for an AI role:
- A failure you diagnosed and fixed, with the number before and after.
- A trade-off you decided with data, such as cost against quality.
- Unclear requirements you turned into examples and a test.
- A change of mind forced by a measurement.
- An explanation you gave to someone non-technical, and what they decided.
Each story gets the same four facts: the situation, what you did personally, the number, and what changed afterwards. That is the STAR method (situation, task, action, result) used as a checklist.
How to deliver it#
Say the answer, then stop. A tight answer invites a follow-up, which is where you want to be, because you prepared for those.
- Use “I” for what you did and “we” for what the team did, and be exact.
- Give one number and its setup, then move on.
- Say “I do not know” and what you would check. It is more credible than a guess.
- Time yourself. Most first drafts run long.
Record yourself answering “tell me about a project” on your phone, then listen once. Count how many seconds pass before you say what the problem was. Cut everything before it, and record again the next day.
Fill this in for your own project, then time yourself reading it aloud:
Problem:
Simplest design:
Number:
Failure + fix:
Decision + trade-off:
Next:Aim for 120 seconds. If you run over, cut the design details first.
Hint
Expected output
The shape to aim for:
Problem: support teams
re-answer the same docs.
Design: plain retrieval,
agent only for refunds.
Number: hit rate [x]->[y]
on [N] real questions.
Failure: double refund;
fixed with a key + cap.
Next: grow the golden set.1.Name the six steps of the two-minute walkthrough.
Problem, simplest design, one number, a failure, a decision and its trade-off, and what comes next.
2.An interviewer asks about a time you failed. Your best story is about a bug in your project. Which facts do you include?
What broke, how you found the cause (the trace), what it cost in time, what you changed, and the number or check that proves it stays fixed.
3.You are asked about a disagreement and you have no team experience. What do you do?
Use a decision you made against your own first idea, backed by a measurement. Say it was a personal project and that you would involve others earlier at team scale.
4.Why prepare four or five stories instead of twenty answers?
Most questions are the same stories seen from a different angle. A small bank is easier to remember and easier to tell honestly.
In one picture#
Open problem first, then stack
Steps problem, design, number,
failure, decision, next
Bank 4-5 stories, reframed
Rule say what you did, plainly- Portfolio projects that get interviews: the evidence behind your stories.
- AI agent interview questions: the technical version of the failure questions.
- LLM evaluation interview questions: how to prove a change helped.
- The AI engineer interview hub: all the rounds in one map.
Next in the course: a two to four week plan that schedules the practice for all five tracks.
