A useful tool-permitted coding interview makes the candidate’s engineering decisions visible. Give them a small, realistic problem, let them implement or direct the implementation, and reserve time to inspect what changed. Assess the brief, the review, the verification, and the final decision about whether the patch is ready.
A finished patch is one artifact. The candidate also needs to explain the behavior it preserves, the failure it prevents, and the evidence they actually observed.
Decide the rules before the interview
Tell candidates which resources they may use: coding tools, documentation, web search, packages, and personal accounts. Define what they must disclose during the round, such as delegated work, copied suggestions, rejected changes, and manual edits. State whether transcripts will be retained and which repositories, credentials, logs, and screenshots are out of bounds.
For a controlled exercise, provide the same repository, environment, and tool access to everyone. If you allow personal setups, record that choice and consider access differences when interpreting the evidence. Tool familiarity can affect how quickly someone starts; it does not establish whether they understand the resulting code.
Prepare a fallback for tool failure. Decide beforehand whether to pause, reschedule, or switch to a written exercise. A written fallback can assess reasoning, but it cannot supply evidence of code execution. Keep those assessment modes distinct.
Prepare one bug with a clear contract
Use a small repository with an understandable test command and one realistic defect. Prepare an answer key describing the expected behavior, important risks, and checks that would distinguish a correct repair from a plausible mistake. Accept alternative implementations that satisfy the contract.
For example, a profile form lets users save after removing a required phone number. Give the candidate the relevant form, API handler, and validator. Ask them to preserve existing phone-format rules while fixing required-field handling.
The expected checks include three routes:
- Clearing the field in the form shows the required-field message and prevents submission.
- Submitting directly to the API with the required field missing is rejected without changing the stored profile.
- Saving a valid, unchanged profile still succeeds.
Confirm the application’s existing error response before choosing an expected status code. If the requirement depends on account type, the candidate should identify that ambiguity and ask for a decision.
For a live exercise, the interviewer must supply the runnable repository and fixtures. A written scenario alone does not demonstrate that any of these checks can run.
Use a schedule that protects review time
| Minutes | Activity | What to observe |
|---|---|---|
| 0–10 | Read the report and write a brief | Expected behavior, scope, constraints, and unanswered questions |
| 10–30 | Implement or supervise implementation | Task boundaries, response to surprises, and changes the candidate rejects |
| 30–45 | Review the diff and run relevant checks | Behavior, adverse cases, actual results, and gaps |
| 45–60 | Explain the decision and remaining risk | Readiness, ownership, next checks, and recovery considerations |
Announce the transition to review even if implementation is incomplete. An unfinished change can still reveal sound judgment if the candidate explains its current state accurately. Finishing early creates room for stronger verification; it does not remove the need for review.
Ask questions tied to the patch
During briefing, ask: “What behavior must stay the same?” During review, ask: “Which changed file carries the most risk?” During verification, ask: “What plausible wrong implementation would this check catch?”
In the profile example, a candidate might improve the browser message while leaving the API permissive. The direct-submission case exposes that gap. Another might strengthen validation but change accepted phone formats. Comparing against the existing format contract matters separately from proving that an empty field is rejected.
Ask the candidate to explain any rejected suggestion. Their reason should connect to scope, compatibility, risk, or evidence. A polished implementation summary cannot substitute for inspecting the relevant code.
Score observable work
A compact observation guide can use four dimensions:
| Dimension | Useful evidence to record |
|---|---|
| Framing | A testable goal, bounded scope, dependencies, and stop conditions |
| Risk | Material failure modes and specific controls or checks |
| Evidence | Relevant cases, observed results, and explicit limits |
| Ownership | A clear decision, accountable owner, next step, and recovery considerations |
If you use a 0–3 scale, define its anchors before the round. Cite an artifact or quotation for every score: the written brief, a review finding, a test result, or an explanation of remaining risk. Avoid a fixed hiring cutoff based on an uncalibrated total.
In a live exercise, proposed tests remain proposals until executed. Strong execution evidence includes observed main and adverse cases and any integration proof the change requires. In a written exercise, assess how specific and discriminating the proposed checks are. Do not compare the two totals as though they measured identical work.
Finish with a decision
Ask the candidate whether they would accept the patch, request changes, or stop for clarification. Have them name what remains unverified and who should resolve it. If the task involves rollout risk, ask what would trigger a stop and how recovery would work.
Afterward, interviewers should score independently, compare the recorded evidence, and resolve disagreements against the artifacts. A disagreement such as “the direct API case was never checked” is actionable. “They seemed senior” provides little basis for calibration.
The Agentic Developer Interview includes cards on designing tool-permitted rounds, writing task briefs, and building hiring rubrics for these decisions.
The Kindle edition is free from 23 to 25 October 2026 (US Pacific time).