Question presented to candidate: "We have a customer-support agent that looks up orders, checks the refund policy and issues refunds through tools. It works in demos and fails unpredictably in staging. How would you evaluate it properly, and when a run goes wrong, how would you find out why?"
What a strong answer should cover:
- Outcome evaluation: a scenario suite with checkable end states (the refund row exists once, with the right amount), graded on the final state rather than on the agent's own claim of success
- Trajectory evaluation: comparing the sequence of tool calls with a reference (strict, unordered, subset, superset matching), plus reference-free process checks such as repeated calls, skipped mandatory steps, invalid arguments and error recovery, and an LLM judge over the trace where rules cannot decide
- Reliability over repeated runs: success rate per scenario across several runs, and the difference between pass@k (at least one of k succeeds) and pass^k (all k succeed), with pass^k the one that matters for production
- Debugging from traces: record every model call, tool call and result; replay failures against recorded tool results; diff a failing run against a passing one to find the first divergent step; group failures into a taxonomy
- Cost, steps and latency as guardrail metrics, and side-effect safety (no duplicate or unauthorised actions) as must-pass checks
Clarifying questions expected:
- Which tools have side effects that cannot be undone, and is there a sandbox or staging copy of them?
- Is there a single correct sequence of steps, or many acceptable ones?
- Does the agent talk to a user over several turns, so we also need a simulated user?
Code / implementation expected: Optional โ scoring recorded trajectories (outcome, match modes, process flags, pass^k) and a first-divergence diff.