Agent Engineer Interview Guide

An agent engineer interview checks whether you can let a model take actions without losing control of what happens next. Few employers publish their loop, so the best preparation guide is the posting itself. Its requirement lines tell you what the rounds will probe.

This guide reads current postings for those signals, groups them into four areas, and ends with a practice set. Postings were opened on September 26, 2026. Nothing here describes a specific company's interview process. The prompts are original.

Confirm which job you are interviewing for

Agent engineering postings split into two kinds. Some build agents for a product or a customer. Others build the runtime that agents run on. The first kind leans on evaluation and product judgment. The second leans on distributed systems. 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 you weight everything below.

The four areas a loop tends to probe

The areas come from requirement lines in current postings. They are an inference about what gets tested, not a published loop.

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 describe 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 primitives make agents "steerable and verifiable, while still conversational and adaptive."

A strong walkthrough names each decision and what enforces it:

1. Scope. What the agent is for, what it must never do, and which steps could be fixed code instead.
2. Tools. Each tool's arguments, result and error shape. Narrow tools beat one general tool.
3. Authority. Where identity and permission are checked. The answer is in the application, not the prompt.
4. State. What is stored between steps, what survives a crash, and what happens to an action whose result is unknown.
5. Stopping. Step limits, deadlines, and the path to a person when the agent is unsure.
6. Evaluation. How you would know it works, before and after launch.

Interviewers push on the edges. Be ready for the tool that times out after it changed something, the user who asks for another customer's data in valid-looking arguments, and the approval that went stale while waiting. OWASP's Excessive Agency entry, part of its 2025 list for LLM applications, is a useful checklist: excessive functionality, excessive permissions and excessive autonomy.

2. Evaluation

Almost every agent posting mentions evaluation, and several make it the core 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 eval suites and regression tracking "that catch quality and latency regressions before they ship."

Expect to be asked how you would measure an agent you have just designed. Good answers separate three things:

• Task outcome. Did the record end up in the right state? Check observable state, not the agent's summary.
• Process. Were the tool calls valid, permitted and efficient? Traces answer this.
• Judgment. When the agent refused or asked for help, was that right? Count these separately from failures.

Be ready to defend an LLM judge. Say what it scores, what it sees, and how you checked it agrees with people on a sample. A judge that reads the agent's own explanation can be persuaded by a confident wrong answer.

3. Debugging and reliability

Postings describe the failures they expect you to find. 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 manage token spending. Anthropic's Claude Managed Agents posting asks candidates to reason about "durability, consistency, failure modes, and cost."

Expect a scenario round: here is a trace, here is a complaint, find the cause. Work from evidence. Reproduce with the same inputs and versions, then locate the boundary that failed: retrieval, the model's choice, argument validation, the tool, or the write. Say what you would add so the next failure is easier to see.

For runtime roles, expect classic distributed systems questions with an agent twist: a long-running session on a worker that dies, two agents editing the same record, a retry against an external service that has no idempotency support.

4. Coding, often with AI tools

Some postings now ask for fluency 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 produce a change that is correct and show that it is? Practice writing the failing test first, then reviewing 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 artifact you can walk through in five minutes. The best one shows a model proposing an action, the application checking it, a stale or unauthorized case being rejected, and a restart that loses nothing. The how to become an agent engineer guide describes three such artifacts, and the agent engineer career guide has a demonstration script.

If you have a week, work through these course labs in order. Each runs locally.

1. Run a bounded tool-calling loop for the tool and authority questions.
2. Human approval for agents for stale decisions and safe retries.
3. Evaluate a ticket agent for scoring with honest denominators.
4. Agent design patterns for when to use a fixed workflow instead of a loop.

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

Practice prompts

These are original practice prompts, not questions from any employer's loop. Each lists what a strong answer shows.

The tool call succeeded, but the worker crashed before recording it. Draw the failure window. Explain how an idempotency key or a lookup by a stable ID tells you whether the action happened, and why a blind retry could apply it twice.

The model passes a correctly shaped ID for a record the user cannot see. Trace identity from the request to the tool. Show where ownership is checked, for reads as well as writes, and why a prompt instruction is not an access control.

Design the tools for an agent that edits calendar events. Prefer narrow tools with explicit arguments over one general tool. Name which actions need a person's approval, and what the approval is bound to.

Your eval score went up, but support tickets about the agent went up too. Check what the dataset covers versus what users do. Look for cases the judge scores as passing that end in the wrong state. Say what you would add to the set.

An agent is looping on the same tool call. Find the stopping rule and why it did not fire. Check whether the tool's error 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 scope. Describe the refusal path, what gets logged, and how the user reaches a person. Explain how you would count these in an evaluation without calling them failures.

When would you not use an agent here? Point to steps that are always the same and belong in code. Name the one decision that needs a model, and the evidence that the model improves it.

Two agents want to update version 7 of the same record. Show the version check at the write and what the losing request receives. Explain why it must reconsider, not replay its old decision against version 8.

How would you know a new model version is safe to ship? Run the same frozen set on both versions and compare outcome, process and cost separately. Name a rollback condition 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 would change. Claim only what you tested.

Questions to ask them

1. Do the agents in this product change records, or only return text?
2. How is agent quality measured today, and who owns the evaluation 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 the layers of the work.
• If the role is customer-facing, the forward deployed engineer interview guide covers discovery and delivery rounds.