Prepare for AI engineer and Forward Deployed Engineer (FDE) interviews with free topic questions, matched source answers, foundation practice, and customer scenarios. All questions and answers are in English, with original source numbers preserved.
An operations team wants a “multi-agent” system to classify requests, look up account status, and draft a response. The steps are usually predictable, but a few requests need investigation. What architecture would you start with?
Reveal an answer outline
Clarify first
Which decisions genuinely require choosing the next action from new evidence?
Model the routine path. Write the common process as explicit steps with typed inputs and outputs. Use normal application code for deterministic checks and a bounded model call where interpretation is needed. Keep an operator path for unsupported requests.
Locate the uncertain decisions. Prototype a single bounded agent for cases that require evidence-driven exploration. Specify allowed tools and terminal states. Compare it against the workflow on the same cases before introducing separate agent roles.
Justify any split. Add multiple agents only for a demonstrated need such as independent parallel work or distinct access scopes. Define the handoff contract, result validation, and shared-state ownership; measure coordination cost and failure propagation.
The tradeoff: A workflow is easier to inspect but can become brittle when paths multiply. Dynamic investigation adds flexibility while making execution cost and behavior harder to bound.
An agent sometimes uses update_customer when a user only asks to see a customer record. Both tools accept an account ID and their descriptions overlap. How would you fix the interface and execution path?
Reveal an answer outline
Clarify first
Was the write merely proposed, or did the application execute it?
Contain the execution risk. Inspect affected traces and disable unintended writes while investigating. Require the execution layer to validate allowed action, resource scope, and arguments before side effects. A correctly shaped tool call is still only a proposal.
Make the tools distinguishable. Give reads and writes distinct names and concise descriptions of when each applies. Require explicit fields for updates and reject unexpected arguments. Return structured, bounded results and actionable errors rather than ambiguous success strings.
Evaluate near misses. Test read-only requests, ambiguous instructions, denied resources, and malicious text in retrieved data. Check both tool selection and resulting state. Confirm rejected calls cannot enter the write function.
The tradeoff: More tools can improve specificity but also increase selection burden. Expose only the relevant authorized operations for the current task.
An agent submits a warehouse dispatch request. The service times out before returning a result, and retrying could send a second parcel. How should the agent and application recover?
Reveal an answer outline
Clarify first
Does the service support an idempotency key or a lookup by client operation ID?
Represent the uncertainty. Record a stable operation ID and an unknown outcome. Do not label the dispatch failed solely because the caller timed out. Keep this state separate from permanent rejection and confirmed success.
Reconcile before repeating. Query the service for the operation state if supported. For safe retries, reuse the same idempotency key and intent, respecting the provider's scope and retention contract. A new key would represent another action, not recovery of this one.
Bound recovery. Apply retry limits and a deadline. If the outcome cannot be established safely, route to a human reconciliation queue with the operation record. Test a committed write followed by a lost response, not just a pre-execution network failure.
The tradeoff: Pausing an uncertain action can delay fulfillment. Automatically repeating it can create a second external effect that is harder to reverse.
A research agent keeps reformulating the same failed search and spends its entire daily allowance on one task. It stays under a per-call timeout, so the existing timeout check never stops it. What controls are missing?
Reveal an answer outline
Clarify first
What counts as a completed task, and which failures should terminate it?
Budget the whole run. Set limits for total calls, elapsed time, and spend at the controller boundary. Include child work and retries in the same accounting scope. Reserve estimated cost before concurrent work so multiple branches cannot all consume the remaining budget.
Require meaningful progress. Track action identity, results, and changes in evidence. Detect repeated unsuccessful actions while allowing legitimate pagination or polling. Require a new hypothesis, new input, or escalation when the same approach no longer improves the task state.
Stop with usable state. Cancel pending work where supported, record completed actions, and distinguish budget exhaustion from success. Return bounded findings and remaining gaps. Test hung tools, concurrent branches, and misleading success messages.
The tradeoff: Tight limits can stop valid long investigations. Make the budget visible and adjustable for the task while retaining a hard ceiling and an explicit stop reason.
