AI Engineer Interview

The answer is B.

The missing context is not nearby; it is structurally related. A strong design carries definitions with clauses, retrieves linked definition chunks through metadata, or handles highly interconnected contracts as whole documents when they fit the model context. Say it: I would not bump overlap for a ten-page gap. I would preserve the contract structure, link clause chunks to referenced definitions, or move this document type to full-document reasoning. The tradeoff is retrieval cost versus faithful legal context.

The answer is B.

Because the retrieved chunks are unrelated, the first broken stage is retrieval. Embedding quality, index configuration, filters, or query formulation can all poison the candidate set before the generator ever sees the prompt. Say it: I'd trace the failure to the stage that broke it: irrelevant chunks mean retrieval, not generation. I would fix embedding, index settings, or query formation before touching the final prompt.

The answer is B.

The trace shows the first wrong intermediate value at the router. The responder only surfaced the bad category as fluent text, so the durable fix is router logic, a regression case, and lookup confidence gating. Say it: The responder just wrote a fluent answer from bad inputs, so I would not patch the symptom. I would fix the router classification, add a router regression test, and add a lookup confidence check to stop silent propagation.

The answer is B.

The bug is not that ten minutes was too short; it is that log-fetch could spend everyone’s time. A scoped timeout preserves time for remediation and gives the orchestrator a clean degrade, retry, or branch failure. Say it: Only a global timeout existed, so one slow sub-agent ate the shared budget. I’d cap log-fetching at ninety seconds with its own token budget, then retry, degrade, or fail that branch without starving remediation.

The answer is B.

The first case is context pollution: failed reasoning changed the next agent’s behavior. The second case lacks conflict resolution. Clean artifacts carry conclusions and evidence; regulated disagreements need binding review or escalation. Say it: The tradeoff is raw scratchpad context versus clean evidence. The summarizer is imitating failed attempts, so I would pass conclusions plus evidence and make compliance binding or escalate to a human.

The answer is B.

The fetches are independent, so fan-out/fan-in cuts latency and gives one aggregation point. The failed fact-check creates a conditional loop back to only one fetch, which a straight pipeline cannot model cleanly. Say it: I’d use fan-out/fan-in for the five independent fetches, then wrap the flow in a state graph. The tradeoff is extra graph complexity, but it cleanly represents the conditional retry of only the failed source.

The answer is B.

The first failure needs orchestrator-worker: a planner splits bug fix and docs work, then merges outputs. The second needs handoff: when ownership changes mid-task, pass the diagnosis, files touched, constraints, and next steps. Say it: I would not call the first case orchestration while only one worker runs. I would promote multi-specialist work to a planner, and use a stateful handoff when security ownership appears mid-task.

The answer is B.

The task has no real isolation, parallelism, or role specialization, so every handoff is coordination tax. One agent with the right tools and context removes duplicated work and restores latency. Say it: For a simple help-center lookup, there is no isolation, parallelism, or specialization need, so the three-hop pipeline is paying coordination tax for nothing. I would collapse it to one well-tooled agent.

The answer is B.

The model cannot be trusted to meter itself. A wrapper or gateway must read actual usage from API responses and stop at the ceiling, while tool calls need hard timeouts tied to the operator cancellation signal. Say it: I do not let the model enforce its own budget; that trades safety for hope. I put real spend ceilings in the wrapper, then wire every tool timeout to the same cancellation path the operator can trip.

The answer is C.

C is best because approval is a durable checkpoint. The system must record the proposed wire before suspension, then load and execute that exact record after approval. A redeploy should not erase what humans were asked to approve. Say it: I treat human approval as a durable checkpoint, not a process wait. I save the exact proposed transfer before suspending, then resume by executing that recorded action after approval, without asking the model again.

The answer is B.

The durable state must record completed steps and payment confirmation data before any restart. Then resume can skip payment and continue at confirmation. Idempotent payment handling is still a second line of defense, not the main control state. Say it: I checkpoint after every completed step into serializable state, recording completion and payment confirmation, so restart resumes at the next unfinished step. The tradeoff is extra writes for reliable control instead of risky replay.

The answer is B.

The system must persist the model’s chosen call before execution and replay it with the same idempotency key. Separately, the payments tool needs a circuit breaker so a known-bad dependency stops attracting fleet-wide retries. Say it: I would split intent from execution: persist the chosen transfer with its idempotency key, then replay that exact call on retry. I’d also open a payments circuit breaker so failing tasks stop hammering the unhealthy dependency.

The answer is B.

B names the failure mode and the fix. Fixed delays make callers retry together, exponential backoff increases spacing, jitter randomizes each caller, Retry-After respects server guidance, and separate budgets bound each call and the whole task. Say it: Fixed-delay retries from a fleet resynchronize into a thundering herd, so I use exponential backoff with jitter, respect Retry-After when present, and keep per-call timeouts separate from the whole task budget.

The answer is C.

C is best because the timeout only proves the caller stopped waiting, not that the email failed. One caller-generated key, stored before attempt one and enforced by the email service, collapses duplicate submissions while still allowing recovery. Say it: I generate the key when the send intent is created, persist it before the first attempt, reuse it on every retry, and require server-side dedupe, so retries do not become duplicate emails.

The answer is B.

B is best because it detects periodic behavior in the sequence, not only duplicate neighbors. A rolling window of normalized state signatures catches A-B-A-B by comparing the window to possible cycles. Say it: I would keep the consecutive-repeat guard, but add a rolling window of normalized state signatures. That catches a period-two A-B-A-B oscillation because the tradeoff is sequence detection, not neighbor comparison.

The answer is B.

No-progress detection turns a vague stall into a structural exit. Comparing tool-call signatures and result hashes across iterations catches repeated search behavior and routes to stop or escalate before the agent spends the full cap. Say it: I keep control outside the model: I diff each call and result against recent steps, then stop or escalate after repeated signatures or unchanged result hashes. Exact repeats are caught early; two-step thrashing needs a windowed cycle check.

The answer is B.

The task is classification plus extraction, not deep reasoning. A smaller model may match accuracy while cutting cost and latency. Temperature 0 only makes outputs repeatable; it does not teach the model the right category. Say it: I’d classify this as extraction and classification, so I’d run a real ticket eval across models. If a smaller model clears accuracy, I’d take the latency and cost win; temperature zero only repeats mistakes.

The answer is B.

Large exposed registries create a routing problem: the model must choose among many similar tools. Subsetting reduces confusion, while the runtime still decides which proposed calls are safe to parallelize. Say it: I would not expose all sixty tools all the time. I would retrieve a relevant subset, run independent reads concurrently, and sequence charge_card after the read results because it is a dependent side effect.

The answer is B.

The schema gives the model two identical shapes and no semantic signal, so it is guessing which identifier belongs where. Descriptive parameter names and one-line field descriptions fix routing closer to the source. Say it: This is a schema problem, not a prompting problem: both tools take a same-named field with no type signal, so the model is guessing. I would rename the parameters to user_identifier and account_identifier and describe each one.

The answer is B.

More retrieved chunks can cause lost-in-the-middle behavior, while prompt caching only helps exact stable prefixes. Measure relevance of added chunks, rerank, and shrink top-k; cache the system prompt and tool schema, not per-query retrieval. Say it: That's the classic lost-in-the-middle pattern: more chunks means more content competing for attention, so I'd check relevance of added chunks and rerank to tighter top-k. Caching the retrieved block won't help; I'd cache stable prefix blocks.

The answer is B.

B is best because the output allowance is being treated as whatever remains after prompts, tools, documents, and history. As input grows, generation space shrinks, so reserve output first and trim or summarize before crossing it. Say it: I'd check whether output tokens are a fixed reservation or just leftover space. The tradeoff is input richness versus answer completion, so I'd reserve output first and summarize history before that reserve is touched.

The answer is B.

B fixes both gaps. JSON mode only ensures valid JSON, so schema validation is needed. But the injection worked because review_text was treated like instructions; delimiting it as untrusted data addresses that structural prompt boundary. Say it: JSON mode only promises valid JSON, not schema-correct or trustworthy content, so I’d still run a schema validator. The deeper problem is pasted user text, so I’d delimit it as data and verify the summary reflects the review.

The answer is B.

The failure is not only bad wording; it is missing change control. A versioned template artifact gives diffs, per-call logs explain outputs, evals catch regressions, and rollback uses a known prior version. Say it: I treat a prompt like code: it lives in a versioned template with an identifier, every call logs which version ran, a change gets review and evals, and rollback is a pointer flip.

The answer is B.

This is a single-step discrimination problem, not a reasoning problem. The confusion matrix shows which category pairs need help, and targeted few-shot examples teach those boundaries with less latency and cost than chain-of-thought. Say it: Chain-of-thought is for multi-step reasoning, not single-step classification. I would inspect the confusion matrix, then add two or three few-shot examples for the category pairs the model actually confuses.

The answer is B.

A timed-out charge may have succeeded. The safest first change is to make the charge idempotent, then verify status before any repeat, so retries cannot create a second payment. Say it: A timeout is an unknown outcome, not a failure, so I would not blindly retry a charge. I would use an idempotency key, check payment status, and retry only with the same key and a budget.