A written engineering interview can assess the brief, review, or plan a candidate produces without running code. It makes their assumptions, boundaries, proposed checks, and ownership decisions available for inspection. Define those artifacts as the evidence for the round.
Keep the conclusion within that scope. A precise verification plan shows what the candidate proposes to check. It supplies no observed execution results. If the role also requires evidence of implementation or debugging in a working environment, gather that in a separate exercise.
Choose a decision that fits written work
A task-brief exercise gives the candidate a bug report and a small code map, then asks for instructions another engineer could use. The output should identify the failure, editable scope, preserved behavior, acceptance cases, review checklist, and conditions for stopping.
Avoid asking the candidate to invent an entire system from an ambiguous paragraph. Supply the contracts needed for the intended decision and leave only deliberate uncertainties. Record which questions the interviewer may answer and give consistent answers across the round.
For example, use a profile form that still saves after a required phone number is removed. Supply the form, API handler, and validator paths. State that existing phone-format rules must remain unchanged. Leave account-type exceptions as a question the candidate should raise rather than silently resolve.
Give the candidate an explicit deliverable
Ask for a compact task brief and a checklist for reviewing the returned patch. State the time limit, permitted resources, and whether clarification questions are allowed. Written analysis describes the assessment mode; the team still needs to define access to documentation and other resources.
A practical thirty-minute format can allocate five minutes to reading and clarification, fifteen to the brief, and ten to review questions and explanation. This schedule is a suggested operating choice. Protect the explanation time so the interviewer can inspect the reasoning behind the artifact.
Tell the candidate to distinguish supplied facts, assumptions, and unresolved questions. They should make a bounded decision where the contract is clear and name a stop condition where missing information could change the repair.
Inspect the acceptance cases closely
For the profile scenario, a useful brief includes three routes:
| Route | Proposed action | Expected observation |
|---|---|---|
| Browser validation | Clear the required phone number and save | Required-field message appears; no save request is sent |
| Server boundary | Submit directly with the phone number missing | Request is rejected using the existing required-field error contract; stored profile remains unchanged |
| Valid behavior | Save an unchanged profile with a valid phone number | Save succeeds under the existing contract |
Ask how the candidate would confirm that phone-format rules remain unchanged. That requires representative accepted and rejected formats from the existing rules, with expected outcomes. Merely writing “preserve validation” leaves the reviewer without a concrete comparison.
The direct server case addresses a bypass of browser validation. The valid-save case prevents a repair that rejects every submission from appearing sufficient. Require the candidate to confirm the existing API error contract before selecting an expected status code.
Test whether another engineer could follow the brief
A weak answer might say: “Fix required-field validation, make it robust, and test thoroughly.” It names a concern but leaves the failure, scope, and proof undefined.
A stronger instruction is: “Reject profile saves after the required phone number is removed. Limit the change to the form, profile API handler, validator, and relevant tests. Preserve current phone-format rules. Check browser rejection, direct server rejection without a stored change, and a valid unchanged save. Stop for clarification if phone requirements differ by account type.”
Ask what the recipient should return: changed files, review findings, observed checks when implementation occurs, and unresolved risk. Then ask the candidate to review their own brief for an instruction that two engineers could interpret differently. This exposes ambiguity while the interviewer can still discuss it.
Score the written artifact on its own terms
Use observable anchors and cite the sentence, table row, or review note that supports each judgment. A compact guide can cover four dimensions:
- Framing: a testable goal, bounded scope, dependencies, non-goals, and stop conditions.
- Risk: material failure modes, the boundary to protect, and specific checks or recovery considerations.
- Evidence: concrete proposed inputs and expected outcomes for main and adverse cases, plus explicit unverified work.
- Ownership: an accountable owner, next check, remaining risk, and any applicable rollout, stop, and recovery decisions.
Keep planned and observed proof separate. In written mode, specific checks can earn credit for their ability to distinguish correct behavior from plausible regressions. In execution mode, evidence requires relevant observed results and their limits. Do not compare totals from those modes as though they represent the same work.
Avoid assigning maximum credit for an answer's overall polish. A candidate may specify excellent acceptance cases while giving only a broad constraint against format changes. That is stronger evidence planning than risk verification. Naming an owner and next check also leaves rollout and recovery questions open.
Use follow-ups to expose the remaining uncertainty
Ask: “What context would you request next?” Useful answers should connect to a decision: existing error responses, examples of the current format rules, or whether account types have different requirements.
Then ask: “Which returned change would make you stop?” A concrete answer might identify edits to unrelated account behavior or a repair that changes accepted phone formats. Finally ask what the checklist would require before merge and who would confirm it. Record those answers alongside the brief.
Do not fill gaps with assumptions on the candidate's behalf. If they propose a test without an expected result, ask for the result. If they claim success, ask which supplied artifact establishes it. The written record should remain clear about what has and has not been observed.
Decide what another round must establish
Finish by recording the artifact's strengths, unresolved questions, and next observation. A written brief can establish that the candidate specified a direct server check; a live exercise can establish whether they execute it and interpret its result. Keep both records available to the panel.
Score independently, then resolve disagreements against the actual brief and follow-up answers. Use remaining uncertainty to choose a focused next step. Keep training scores as practice feedback rather than treating an uncalibrated total as a hiring cutoff.
The Agentic Developer Interview includes a written prompt-review card on a required-phone profile bug, with task-brief constraints, observable acceptance cases, stop conditions, and a review checklist.