Agent questions are new enough that interviewers are still working out what to ask, which makes them unusually revealing. Most of them reduce to one thing: have you seen an agent fail in a way a demo never does?
The mechanism
An interviewer will usually start by finding out whether you understand what an agent is underneath the framework.
- Describe the agent loop without naming a framework. — If you cannot, you have used a library rather than built a system.
- What decides when an agent stops? — The answer should include a hard step limit, not only the model choosing to finish.
- What happens when a tool throws an exception mid-run? — Testing whether you feed the error back or let the process die.
- How does the model know which tool to call? — Testing whether you understand that tool descriptions are prompt surface.
The failures
This is the section that separates candidates, and it is entirely about things that do not happen in a tutorial.
- Your agent calls the same tool with the same arguments five times. What is happening? — Usually the tool returned something uninterpretable: an empty list, a stack trace, a page of HTML.
- A search tool finds nothing and returns an empty array. What does the model do with that? — It reasons confidently from nothing. The fix is distinguishing "empty" from "failed" in the tool result.
- Your agent works on short tasks and dies on long ones. Why? — Context growth. Every turn appends, cost is roughly quadratic in turns, and a long tool result tips it over.
- How do you stop an agent doing something irreversible when it is wrong? — The answer is a permission boundary, not a better prompt.
Multi-agent, and the answer interviewers are listening for
Asked when a multi-agent architecture is the right choice, the answer that impresses is usually the sceptical one. Splitting one agent into five multiplies cost, adds a handoff where context is lost at every boundary, and frequently produces worse answers than one agent with the same tools.
The defensible reasons to split are narrow: genuine parallelism where wall-clock time matters, hard isolation where one part must not have another's tools or data, and critique where a second pass with fresh context demonstrably catches errors. "It feels more organised" is not one, and saying so out loud reads as experience rather than contrarianism.
Frameworks, and the question behind the question
You will be asked which framework you use, and the question is rarely about the framework. The interviewer is finding out whether you chose it or inherited it, and whether you know what it does for you.
A good answer names what the framework provides — durable state across restarts, branching control flow, tracing — and when you would not bother. A twenty-line loop is easier to debug than a graph abstraction when the task is three sequential steps, and saying so demonstrates that you understand the trade rather than following a tutorial.
The follow-up is usually about what you hit that the framework did not solve. Everybody who has shipped has an answer; nobody who has only completed a tutorial does, and the silence is obvious.
- What does your framework give you that a plain loop does not? — Testing whether the choice was deliberate.
- When would you not use one? — Testing whether you can see the cost as well as the benefit.
- What did you have to work around? — The question that separates shipping from following along.
Cost, which almost nobody prepares for
Agent cost is unbounded by construction: a loop that decides its own length, over a context that grows each turn, at a price per token. Interviewers at companies running agents in production know this and ask about it; candidates almost never have an answer ready.
The components worth being able to name are the per-run token ceiling enforced by stopping rather than warning, routing mechanical work to a cheaper model while reasoning stays on the expensive one, caching the stable prefix of tool schemas and system prompts, and clipping tool results at the boundary because most of a large HTML page is navigation.
If you have measured cost per run on anything you built, say the number. It is a small detail that marks out people who have operated a system from people who have written one.
Evaluation, again
As with GenAI interviews generally, the question most candidates cannot answer is how you know an agent got better. Agent output is not one string you can diff against an expected one, so the answer has to separate the trajectory from the outcome: did it call the right tools in a sensible order, and separately, was the final answer right?
Trajectory checks are ordinary assertions and cost nothing to run. Outcome checks need a rubric and usually a model as grader — and the honest version of that answer includes validating the grader against cases you labelled by hand, because otherwise you have moved the trust problem somewhere less visible.
Key takeaways
- 1.Being able to describe the agent loop without a framework is the fastest signal that you have built rather than assembled.
- 2.The failure questions are the interview. Silent tool failures and context growth are the two that come up most.
- 3.Scepticism about multi-agent architectures reads as experience, because the cost and handoff losses are real.
- 4.Separating trajectory evaluation from outcome evaluation is the answer most candidates do not have.
Do it now, free
AI Interview Answer Builder
It will not hand you a script to memorise, because a memorised answer is audible. It shows you what the question is testing, the shape a strong answer takes, and how to build yours from what you have actually done.
No sign-up. The internship is free to join too, with real project briefs and reviewed submissions.