Agent Engineer Interview Guide

The interviewer draws a box on the whiteboard and says, "Design an agent that handles refund requests." Then they wait.

What they're really checking is whether you can let a model take actions without losing control of what happens next. Can you say what it's allowed to touch? What happens when a tool fails halfway? How would you know it works?

Few employers publish their interview rounds, so the best study guide is the job posting itself. The requirement lines tell you what the rounds will test. This guide reads current postings for those signals, groups them into four areas, and ends with a practice set.

The postings were opened on September 26, 2026. Nothing here describes any specific company's interview process. The practice prompts were written for this guide.

Confirm which job you're interviewing for

Agent engineering jobs come in two kinds. Some build agents for a product or a customer. Others build the platform those agents run on.

The first kind leans on testing and product judgment. The second leans on large-scale systems: storage, servers, what happens when a machine dies.

The comparison of agent, AI and ML engineering roles shows how to tell them apart from the posting. Do that first, because it decides how much weight you give each section below.

The four areas interviews tend to test

These areas come from the requirement lines in current postings. They're a reasonable guess at what gets tested, not anyone's published interview plan.

1. Agent design

Expect a whiteboard question like "design an agent that handles refund requests" or "design the tool set for a research assistant." The postings hint at what the interviewer will listen for.

Harvey's Senior Software Engineer, Agents lists "prompt engineering, model selection, tool design, skill writing, context window management, and eval harness development." Sierra's Agent Runtime posting asks what building blocks make agents "steerable and verifiable, while still conversational and adaptive."

A strong answer walks through each decision and says what enforces it:

1. Scope. What the agent is for, what it must never do, and which steps could just be fixed code.
2. Tools. Each tool's inputs, output, and what its errors look like. Several narrow tools beat one tool that does everything.
3. Authority. Where you check who the user is and what they're allowed to do. The answer is in the application code, not the prompt.
4. State. What gets saved between steps, what survives a crash, and what happens to an action whose result you don't know.
5. Stopping. Step limits, deadlines, and how it hands off to a person when it's unsure.
6. Testing. How you'd know it works, before launch and after.

Interviewers push on the edges. Be ready for a tool that times out after it already changed something. A user who asks for another customer's data using inputs that look perfectly valid. An approval that went out of date while it sat waiting.

OWASP's Excessive Agency entry, part of its 2025 list of risks for LLM applications, makes a good checklist. It names three ways an agent can be given too much: too many functions, too many permissions, and too much freedom to act alone.

2. Testing the agent

Almost every agent posting mentions evaluation, and several make it the center of the job.

Scale AI's Frontier Agents Engineer (Applied AI) asks for evaluation frameworks "using offline benchmarks, online A/B experiments, golden datasets, regression suites, LLM-as-a-Judge, and human evaluation." Cartesia's Software Engineer, Agent Harness wants test suites and tracking "that catch quality and latency regressions before they ship."

Expect to be asked how you'd measure the agent you just designed. Good answers keep three things apart:

• The result. Did the record end up in the right state? Check the actual data, not the agent's summary of what it did.
• The process. Were the tool calls valid, allowed, and not wasteful? The step-by-step logs (traces) answer this.
• The judgment calls. When the agent refused or asked for help, was that the right call? Count these separately from failures.

Be ready to defend using a model as the grader, often called an LLM judge. Say what it scores, what it gets to see, and how you checked that it agrees with people on a sample. A judge that reads the agent's own explanation can be talked into passing a confident wrong answer.

3. Debugging and reliability

The postings describe the failures they expect you to track down. Decagon's Senior Software Engineer, Agent Product wants comfort "digging into system failures within deep technology stacks." Elastic's Agentic AI Engineer builds monitoring to catch "model drift or agent loops" and keep model usage costs in check. Anthropic's Claude Managed Agents posting asks candidates to reason about "durability, consistency, failure modes, and cost."

Expect a scenario round: here's a log, here's a complaint, find the cause.

Work from evidence. First reproduce it with the same inputs and versions. Then find the step that broke: finding documents, the model's choice, the input check, the tool itself, or the write to the database. Finish by saying what you'd add so the next failure is easier to spot.

For platform roles, expect classic systems questions with an agent twist. A long-running session on a server that dies. Two agents editing the same record. A retry against an outside service that can't recognize a repeated request.

4. Coding, often with AI tools

Some postings now ask you to be good with coding agents. WRITER's Software engineer, agents wants "daily use of tools like Cursor, Claude Code, and other agentic coding platforms." Cartesia lists "fluent use of coding agents."

Whether the round allows AI tools or not, the skill being tested is the same. Can you make a change that's correct, and show that it's correct?

Practice writing the failing test first, then reading a generated patch line by line against it. The course lessons on GitHub Copilot and Cursor are built around exactly that habit.

How to prepare in the time you have

Bring one project you can walk through in five minutes. The best one shows a model proposing an action, the code checking it, an out-of-date or unauthorized request getting rejected, and a restart that loses nothing.

The how to become an agent engineer guide describes three projects like that, and the agent engineer career guide has a script for the demo.

If you have a week, work through these course labs in order. Each one runs on your own machine.

1. Run a bounded tool-calling loop for the tool and permission questions.
2. Human approval for agents for out-of-date approvals and safe retries.
3. Evaluate a ticket agent for scoring that counts every case, including the ones that didn't finish.
4. Agent design patterns for when a fixed workflow beats a loop.

Then practice the prompts below out loud, with a timer.

Practice prompts

These were written for practice. They aren't questions from any employer's interviews. Under each is what a strong answer shows.

The tool call worked, but the worker crashed before recording it

Draw the moment of the crash. Explain how an idempotency key (a unique ID that lets the other service recognize a repeat) or a lookup by a stable ID tells you whether the action happened. Then explain why simply retrying could do it twice.

The model passes a correctly formatted ID for a record the user can't see

Follow the user's identity from the request all the way to the tool. Show where ownership gets checked, for reads as well as writes, and why an instruction in the prompt isn't access control.

Design the tools for an agent that edits calendar events

Choose several narrow tools with clear inputs over one general tool. Name which actions need a person's approval, and exactly what that approval is tied to.

Your test score went up, but support tickets about the agent went up too

Compare what the test set covers with what users actually do. Look for cases the judge marks as passing that end in the wrong state. Say what you'd add to the set.

An agent keeps repeating the same tool call

Find the stopping rule and why it didn't kick in. Check whether the tool's error message tells the model anything useful. Add a step limit and a visible failure state, not just a better prompt.

A user asks the agent to do something outside its job

Describe how it refuses, what gets logged, and how the user reaches a person. Explain how you'd count these in testing without calling them failures.

When would you not use an agent here?

Point to the steps that are always the same and belong in plain code. Name the one decision that needs a model, and the evidence that the model makes it better.

Two agents want to update version 7 of the same record

Show the version check at the moment of writing and what the losing request gets back. Explain why it has to rethink, not replay its old decision against version 8.

How would you know a new model version is safe to ship?

Run the same fixed test set on both versions and compare result, process and cost separately. Decide what would make you roll back before the change goes out.

Walk through the last agent you built

Say what the model decided, what the code enforced, what broke, and what you'd change. Claim only what you actually tested.

Questions to ask them

1. Do the agents in this product change records, or only return text?
2. How do you measure agent quality today, and who owns the test set?
3. What was the last production incident involving an agent, and what changed afterward?
4. How much of this role is building agents, and how much is building the platform under them?

Next steps

• Follow the Agent Engineer career path: reading order, posted pay and more practice prompts.
• Read the agent engineer career guide for what the work involves and a portfolio project.
• If the role works with customers, the forward deployed engineer interview guide covers the discovery and delivery rounds.