How to Write an AI Usage Policy for Technical Interviews
Why you need a written policy now
Every candidate in 2026 has Claude, Copilot, or ChatGPT a tab away. If your interview process does not state a position, three things happen:
- Honest candidates self-handicap because they assume AI is off-limits.
- Dishonest candidates use it freely and win the comparison.
- Your interviewers each apply their own private rule, and your hiring bar quietly diverges across the team.
An AI usage policy is the cheapest fix for all three. Done well, it takes a paragraph in the candidate brief and a line in your scorecard. Done badly, it reads like a legal disclaimer and gets skimmed.
The three policies you can choose from
There are really only three workable stances. Most teams should pick one per stage, not one per company.
Policy A: AI-forbidden
Used during live coding rounds, structured behavioral, and any session where you are measuring the candidate's unaided thinking.
- Candidate cannot use any LLM, autocomplete, or chat tool during the session.
- IDE-level intelligence (syntax highlighting, type hints from a local language server) is fine.
- The candidate confirms understanding in writing before they start.
Policy B: AI-as-tool
Used for take-home work samples and async screening rounds where the goal is to evaluate how the candidate works in their normal environment.
- Candidate may use any AI tool they would use on the job.
- Final submission must be code the candidate can fully explain, defend, and modify under follow-up questioning.
- Candidate must disclose which tools they used and roughly where. A one-paragraph note in the README is the standard format.
Policy C: AI-required
Used when the role itself involves AI — building features with LLMs, writing prompts, or auditing AI output.
- Candidate is asked to use AI as part of the exercise.
- The signal is how they use it: prompt quality, when they trust the output, when they reject it, how they verify edge cases.
- See our guide to interviewing LLM application engineers for the rubric we recommend.
Most healthy loops mix Policy B at the take-home stage and Policy A at the live follow-up. The combination — let them use AI, then make them defend the result — is the single most discriminating filter we see in the field.
What a usable policy actually says
Write the candidate-facing version in plain English. Avoid legal phrasing.
For this take-home, you may use any AI tool you would use on the job (Claude, ChatGPT, Copilot, Cursor, etc.). Two requirements: (1) every line of code in your submission has to be code you can explain and modify under live questioning; (2) include a short note in your README listing which tools you used and where. We use this take-home as preparation for a 30-minute live walk-through, so anything that surprises you in your own code will surprise both of us.
That paragraph does the work of a five-page policy. Notice what it carries:
- A clear permission boundary.
- A defensibility test that survives AI use.
- A disclosure requirement that is cheap to comply with.
- A reason — the live walk-through — that makes the test self-enforcing.
For the live policy, the equivalent is one sentence delivered at the start of the round:
No AI tools, no chat windows, no second monitors for this 45 minutes. If you get stuck, get stuck out loud — that's the signal we're looking for.
Where most policies fail
Three common failure modes.
The policy contradicts itself. "Do not use AI" in the candidate email, then a take-home that takes 12 hours to do without AI. Candidates assume you cannot mean it. Match the policy to the work — a 12-hour project should explicitly invite tools.
The policy is unenforceable and everyone knows it. "Do not use AI on this async coding test" without a follow-up walk-through, without code coherence analysis, without anything. The honest candidates abide; the rest do not, and you have made the gap wider.
The policy is silent about disclosure. Candidates do not know whether to mention AI use, so the strong ones leave it out to look better and the weak ones leave it out to hide. Mandate a one-paragraph note and you neutralize both.
The integrity layer that backs it up
A policy without a verification layer is a guideline, not a policy. The minimum verification stack:
- Live walk-through after every take-home. The single highest-signal interview most teams underuse. See our follow-up question playbook for what to ask.
- Code coherence scoring on the submission. AI-shaped code has structural tells — unnaturally consistent style, big clean pastes, comments that explain trivial code in textbook prose.
- Keystroke and paste signals during live rounds. Burst pastes in an AI-forbidden round are the bright-line violation. See keystroke biometrics for what these signals can and cannot prove.
- Identity continuity. Face-presence checks catch the more serious case where someone else is taking the test.
ClarityHire ships these as a unified integrity layer so an interviewer can read one report instead of cross-referencing four tools.
A short rollout checklist
If you are introducing this from scratch, the sequence that fewest teams regret:
- Write a single internal page that names the three policies and the stage each one applies to. Three paragraphs, no diagrams.
- Update your candidate-facing emails and assessment instructions to quote the policy verbatim. Same wording every time.
- Add a one-line scorecard field — "evidence of AI use, declared or detected" — so interviewers note what they saw without it becoming a separate report.
- Brief your interviewers in a 20-minute calibration session: what the policy says, what to do if a candidate violates it (the answer is almost always "ask follow-up questions, note it, do not eject mid-interview"), and how to read the integrity report.
- Review after 30 hires. Adjust the policy that produced the most confusion.
What to do next
If you do not have a written policy today, do not aim for the perfect one. Pick the three-policy split above, paste the candidate-facing paragraphs into your assessment templates, and ship it this week. Iterate based on what comes back in the walk-throughs.
The teams winning the AI-era hiring game are not the ones banning the tools or pretending they do not exist. They are the ones writing down where AI is welcome, where it is not, and what authenticity means in either case — and then making the interview design enforce it.