Send candidates a written policy before the round that names permitted resources, required disclosure, privacy boundaries, and the fallback when access fails. Make the rules concrete enough that a candidate can decide what to open, what to share, and when to stop without guessing the interviewer’s preferences.
The policy should also explain what the interview assesses. Candidates remain responsible for understanding the patch, reviewing changes, and describing verification. Access to a coding tool changes the available workflow; it does not remove those responsibilities.
Choose an access model and describe its limits
Pick a model before inviting candidates. A closed round excludes external resources. A guarded round provides the same tool and account arrangement to everyone. An open round permits candidates to use their normal setup within stated limits.
Spell out the practical consequences. “Tools allowed” does not answer whether documentation, web search, package downloads, shell commands, or personal accounts are permitted. Separate each permission. A round can permit local code completion and documentation while prohibiting uploads of repository contents to external services.
For a guarded round, check the account, browser, network access, package cache, and documentation before the session. For an open round, explain required capabilities and provide an alternative for someone without suitable access. Do not make an undisclosed paid subscription a condition of completing the task.
Apply the disclosed policy consistently and record material access differences. If the exercise depends on a resource, ensure candidates can reach it within the chosen setup.
Specify what candidates must disclose
Ask candidates to make consequential decisions visible. State whether they should narrate delegated tasks, copied suggestions, rejected changes, and manual edits as they work, or summarize them at review checkpoints.
A useful checkpoint asks the candidate to identify which work they delegated, what came back, what they changed or rejected, and why. This connects tool use to engineering judgment without requiring a running commentary on every keystroke.
Define copied-code disclosure separately from explanation. A candidate should identify borrowed material under the stated rules and explain the code they keep. A transcript can help establish the sequence of decisions, but it cannot replace review of the patch or relevant verification.
Tell candidates whether conversations, recordings, screenshots, or command history will be retained. State what will be collected, who can access it, and the retention arrangement that the team actually uses. Choose these details before sending the policy.
Define data and permission boundaries
Use an interview repository and synthetic fixtures. Identify which files may change, which resources are read-only, and which actions require the interviewer’s approval.
Explicitly exclude production credentials, customer records, private employer code, personal repositories, and unrelated browser or account content. Clarify whether task files may leave the provided environment. If uploads are prohibited, include logs, screenshots, and copied snippets in that rule.
Support the written policy with the environment’s permissions. A sentence prohibiting production access is insufficient if a candidate account still has production credentials available. Provide only the access needed for the exercise.
Name the stop condition for an accidental exposure. For example, if a candidate encounters a secret or unexpected private record, they should stop interacting with it and notify the interviewer without copying it into another tool. Keep incident handling with the team responsible for the environment.
Give candidates a policy they can act on
For a controlled exercise, a candidate-facing policy could read:
You will use the supplied interview repository, browser, and tool account. You may edit the exercise files, run local checks, and read the supplied documentation. External web search, package installation, personal accounts, and sending task material to other services are outside this round’s permissions. Ask before using a resource not listed here.
At each review checkpoint, explain what work you delegated, which suggestions you kept or rejected, and which changes you made manually. You must understand and review the final patch. The rubric assesses framing, judgment, review, verification, communication, and ownership.
Use only the supplied synthetic fixtures. Do not introduce employer code, customer information, credentials, or personal repository content. Stop and notify the interviewer if you encounter unexpected sensitive material.
We will retain the submitted brief, patch, check notes, and interview scorecard. We will not collect a tool transcript or a screen recording for this round.
If tool access fails, notify the interviewer immediately. The timed exercise will pause. We will attempt to restore access for up to five minutes; otherwise we will arrange a replacement execution session. A written fallback requires an explicit change of format and will be assessed separately.
This example assumes the team can provide those resources and honor those collection and fallback rules. Replace its choices with the actual arrangements before sending it. Publish the scoring anchors alongside the policy so candidates know what the named categories mean.
Decide the outage response before the timer starts
Cover unavailable, slow, blocked, and inaccessible tools. Name who pauses the timer and who decides whether to resume, reschedule, or offer another format. Set a troubleshooting limit so the candidate does not lose the whole round diagnosing the interview environment.
If the candidate continues manually, confirm the revised access conditions and record the interruption. Preserve time for review and verification. Do not silently retain a speed expectation that assumed working assistance.
If the fallback is written analysis, say what the candidate should produce: a brief, review, or verification plan. Score the specificity of that work. Proposed checks do not become executed results, and written totals should not be compared with execution totals.
Confirm understanding and apply the policy consistently
At the start, ask candidates to restate the key boundaries and raise access questions. Resolve ambiguous permissions before substantive work begins. If a clarification changes what candidates may use, record it for subsequent rounds.
During review, ask the candidate to explain the final diff, rejected options, actual checks, and remaining gaps. Afterward, score independently and compare recorded evidence. The policy supplies the conditions for that discussion; the candidate’s observable engineering work supplies the assessment evidence.
The Agentic Developer Interview includes a tool-permitted round-design card covering a visible rubric, patch ownership, and fallback planning when candidates lack working tool access.