Software Engineering Foundations

Software Engineering Foundations is the second-largest sub-skill on the paper at 7.4 percent, about four of the 53 scored questions. Almost none of it is Claude-specific, which is why candidates skim it and why it repays attention: the questions are set by people who have watched competent engineers make the same handful of mistakes once a model became a dependency.

The mental model to carry in is that a model call is a network call with unusual properties. It is slow, measured in seconds rather than milliseconds. It is metered, so your concurrency is capped by a quota rather than by your own capacity. It is non-deterministic, so identical input can produce different output. And it is expensive, so a wasted call carries a price rather than merely a delay.

Every practice examined here follows from one of those four properties. Slow means timeouts and cancellation matter. Metered means queueing and backpressure matter. Non-deterministic means your seams and test doubles matter. Expensive means retries need a policy rather than a reflex. Read a scenario, work out which property is biting, and the intended answer is usually the standard remedy for that property.

What the exam tests here

• •How a client timeout and an automatic retry policy multiply into a real worst-case wall-clock time
• •Making side effects triggered by model output safe to happen twice
• •Applying backpressure when concurrency is bounded by a quota rather than by your own capacity
• •Isolating a slow dependency so its saturation does not take the rest of the service down with it
• •Designing seams that let the calling code be tested without a live model
• •Structured logging and correlation across the steps of a single run

Timeouts and retries multiply

Client libraries ship with both a request timeout and an automatic retry count, and engineers configure them separately without noticing they compose. A ten-minute timeout with two automatic retries is a thirty-minute worst case inside one call, which will outlast the gateway in front of it and any user's patience.

Two details are worth carrying. The units differ between language SDKs, with some taking seconds and at least one taking milliseconds, so a value copied between codebases can be wrong by a factor of a thousand. And a per-request override is normally available, which is the right tool when one route is interactive and another is a long generation. Decide the budget for the whole operation first, then divide it.

Idempotency, because reruns are normal here

Anything a model-driven flow can cause to happen twice must be safe happening twice. Retries, resumed sessions, a user pressing a button again and an agent re-issuing a call it believes failed all produce duplicates, and none of those are exotic.

The remedy is ordinary: derive a stable key for the effect from the work rather than from the attempt, record it before performing the side effect, and check it on the way in. The subtlety specific to this setting is that the key must not come from the model's output, which can legitimately differ between attempts at the same task. Key on the request that started the work, and treat a matching key as a completed effect rather than a conflict.

Bound the concurrency you can actually sustain

A service fanning out model calls discovers its quota long before it discovers its CPU. When demand exceeds what the quota allows, the unbounded failure mode is the worst one: everything slows together, retries stack on top of the queue, and the service degrades as a whole.

Put an explicit limit in front of the dependency (a semaphore, a worker pool, a queue with bounded depth) and decide what happens when the limit is reached. Shedding load with a clear error beats accepting work you cannot do. Add isolation while you are there, so a saturated model path cannot exhaust the threads or connections the rest of the service needs to answer a health check.

Seams: test the code without calling the model

A codebase calling the client library directly from its business logic can only be tested by spending money and tolerating variance. Put an interface between them.

The logic assembling prompts, validating output, classifying errors and applying business rules is deterministic and deserves ordinary unit tests against recorded responses, including the awkward ones: a truncated answer, a decline, a malformed payload, a result marked as failed. Reserve live calls for a small set of contract tests confirming the request still validates and the response still has the expected shape.

This is not purity for its own sake. It is the difference between a suite that runs in seconds on every commit and one nobody runs.

Where candidates go wrong

Common questions