Decagon Interview Preparation: Agent Engineering and a Reliability Exercise

TL;DR

• Prepare for a Decagon interview by connecting a customer problem to an agent workflow, a measurable outcome and a failure-recovery plan.
• Decagon has published firsthand engineering context, but we could not verify a standard sequence of interview rounds. Confirm the format for your particular role.
• Practice distinguishing a failed read from a write whose outcome is unknown. Repeating an uncertain action can be more damaging than returning an error.
• Use the original reliability exercise below to explain assumptions, write tests and discuss what would change in a real service. These are practice questions, not reported Decagon interview questions.

What is useful to know before a Decagon interview?

Decagon engineer Kathryn Zhou describes work spanning agent configuration, latency experiments, reliability mechanisms and customer-driven platform improvements. Her May 2026 account also describes collaboration across engineering and product specialties. That is useful context for deciding which projects to discuss; it does not reveal a hiring rubric or a guaranteed interview question. See Decagon's firsthand account of agent engineering.

Our preparation recommendation is to bring one example in which software had to accomplish something for a user despite incomplete information or an unreliable dependency. The project does not have to involve a language model. A payment reconciliation job, a support integration or a deployment service can demonstrate the same habits of defining a contract and checking an outcome.

Choose an example you can explain at three levels. First, state the user's problem in a sentence. Second, draw the request path and the important boundaries. Third, explain a difficult decision in code or data. If you cannot connect those levels, spend your preparation time reconstructing the project rather than collecting more terminology.

What can we verify about the Decagon interview process?

The official sources reviewed for this guide do not establish a universal round count, duration, take-home assignment or language requirement. It would be misleading to turn another candidate's anecdote into your itinerary. Consult the official careers page and use the invitation for your role as the starting point.

Send a short, concrete clarification request: “Could you confirm the stages for this role, whether the technical work is live or take-home, the expected preparation, and which tools are permitted? I would also appreciate knowing whether to prepare a project walkthrough or a customer scenario.” This asks for logistics without requesting confidential questions.

Record the answer on a one-page preparation sheet. Include the interview time and time zone, meeting link, interviewer role when supplied, permitted language, exercise format and equipment needs. Our phone-screen preparation checklist can help with that setup.

If the role is primarily infrastructure, allocate more practice to service behavior, observability and capacity. If it centers on customer deployment, practice discovering requirements and translating a specific request into a maintainable capability. These are preparation choices based on the job description you receive, not claims that all Decagon candidates have the same loop.

Practice question: how would you design a support-agent action?

Imagine a fictional retail assistant that can read an order's delivery status and request an address correction. Start by separating conversation from authority. A user saying an order belongs to them is not, by itself, proof that the service may change it. The application must identify the user and enforce access to the order before an action is attempted.

Write down the state transition in plain language: an authenticated customer requests a permitted change; the order service accepts or rejects it; the assistant reports the verified result. The assistant should not describe an intended action as completed merely because it prepared an API request.

Next, define the exceptional states. The order might already have shipped. The user might lack access. A dependency might reject the request. The network might time out after the service has applied the correction. The last case is especially useful in an interview because “try again” no longer has an obviously safe meaning.

Do not treat that table as Decagon's implementation. It is an original exercise contract. In a real integration, the provider's documented idempotency and error semantics determine which requests can be repeated. Our guide to distributed systems interview questions explains how idempotency keys let a client retry a write, such as a payment, without repeating its side effect.

Coding exercise: make the retry decision explicit

Implement a pure decision function. It receives a validated kind of operation, an outcome category, the number of attempts already made, a maximum attempt count and the remaining deadline in milliseconds. It returns a decision; it does not call a network service, sleep, charge a customer or invoke a model.

For this exercise, a transient failure on a read may be retried. A transient or unknown result for a write requires reconciliation because the contract does not establish that the write failed before it took effect. A successful response and a denial are terminal regardless of the remaining retry budget. An unknown read can be retried within budget because this exercise defines reads as having no external side effects.

def action_decision(kind, outcome, attempts, max_attempts, remaining_ms):
    if kind not in ("read", "write"):
        raise ValueError("unsupported operation kind")
    if outcome not in ("success", "denied", "transient", "unknown"):
        raise ValueError("unsupported outcome")
    if any(type(v) is not int for v in
           (attempts, max_attempts, remaining_ms)):
        raise ValueError("counters must be integers")
    if attempts < 1 or max_attempts < 1 or remaining_ms < 0:
        raise ValueError("invalid counter range")
    if outcome == "success":
        return "complete"
    if outcome == "denied":
        return "stop"
    if kind == "write":
        return "reconcile"
    if attempts >= max_attempts or remaining_ms == 0:
        return "exhausted"
    return "retry"


assert action_decision("read", "transient", 1, 3, 250) == "retry"
assert action_decision("write", "unknown", 1, 3, 250) == "reconcile"
assert action_decision("read", "unknown", 3, 3, 250) == "exhausted"
assert action_decision("write", "success", 3, 3, 0) == "complete"

The order of these conditions matters. A confirmed success should not become “exhausted” because the response arrived at the deadline. Likewise, an uncertain write still needs reconciliation after the user's interactive deadline expires. That follow-up may happen asynchronously; the caller should receive an honest pending status instead of a fabricated success or failure.

The positive remaining time only permits considering another read. It does not guarantee that another request fits. A surrounding executor must account for backoff, connection timeouts and the absolute deadline. Keep that distinction in your explanation so the helper is not mistaken for a complete retry engine.

What should you test and what remains outside the function?

Begin with a small decision matrix. Cover every operation kind and outcome at zero remaining time, one attempt before the cap and at the cap. Include invalid outcome names, negative counters and booleans: Python treats booleans as integer subclasses, so the exact-type check intentionally rejects them here.

Then test the surrounding system separately. Simulate a request accepted upstream followed by a dropped response. Confirm that reconciliation discovers the existing operation and that the assistant does not issue another correction. Test a permission change between initial lookup and final execution. Check how an operation reference survives a process restart.

Those integration checks are proposed exercises, not something this pure function proves. An in-memory branch cannot enforce distributed idempotency, durable storage or authorization. A good explanation says which guarantees come from this code and which depend on a database transaction or an external service contract.

You should also decide which details can appear in a log. An operation reference, outcome class and elapsed time may be useful without including the full support conversation. Identify who can inspect the record, what retention is needed and how to investigate a complaint without exposing another customer's information.

More original Decagon interview questions to rehearse

How would you measure whether an agent change helped? Define a task outcome before choosing a metric. In our fictional address-change flow, count verified corrections and incorrect confirmations separately. Track completion time alongside failures and escalation. A faster response is not an improvement if it confidently reports a change that never happened.

How would you investigate a slow conversation? Split the timeline into useful boundaries: request received, retrieval completed, first output available, tool action started, tool outcome verified and response completed. Compare comparable request types. Avoid averaging a quick status lookup together with a much longer corrective workflow and then drawing a conclusion about either one.

When should a customer-specific feature become a shared capability? State the recurring requirement, the smallest reusable interface and the configuration that varies. For example, customers might share the need for approval before an irreversible change but differ in their approval rules. Explain how you would validate that generalization with a second use case before building a large framework.

What would you do when an evaluation disagrees with customer feedback? Inspect the actual cases, check whether the evaluation represents real work and define the disagreement precisely. Do not simply change the scoring threshold until a preferred result appears. Propose a labeled sample and review the failure category with the people who understand the task.

Build a short, honest project walkthrough

Prepare a five-minute narrative with a small diagram and one concrete failure. Describe your own contribution precisely. “I added outcome reconciliation and wrote the recovery test” is stronger than claiming you built an entire platform when your team shared that work.

Include the tradeoff you accepted. Perhaps reconciliation added delay but prevented duplicate updates. Perhaps you limited the initial integration to one provider because other providers exposed weaker outcome guarantees. Explain what evidence would make you revisit the decision.

For a final rehearsal, ask someone to interrupt with an unfamiliar constraint: the provider has no operation lookup, the user closes the session, or the retry queue is delayed. Work through the implications aloud. The goal is to make your reasoning inspectable, not to memorize a polished speech. When no partner is available, an AI mock system design interview lets you practice defending tradeoffs against skeptical follow-up questions. If you use AI during preparation, follow the interviewer's stated tool policy during the actual assessment.

Sources checked September 14, 2026. This guide is independent of Decagon and does not claim access to its private interview materials.