AI Policy for Technical Interviews: A Practical Framework
The policy you do not have is already being enforced
If your interview team has not written down what AI tools candidates may use, you do not have a permissive policy — you have an inconsistent one. One interviewer is mentally docking points for any Copilot use. Another is letting a candidate paste a full ChatGPT response and grading the result. Candidates are guessing. Recruiters are giving conflicting answers on the prep call.
This post is the framework for fixing that. It assumes you are past the question of whether coding assessments still work in the AI era — they do — and into the harder question of how to write a rule everyone can follow.
The three bad policies most companies are running
Before the framework, the patterns to avoid.
The pretend ban. "No AI tools." Every senior engineer interviewing a candidate uses Copilot in their own job. The candidate either ignores the rule (most do) or follows it and gets unfairly compared to the candidates who cheated. The policy degrades trust without changing outcomes.
The "anything goes." "Use whatever you want." On its face this seems modern. In practice, it makes the assessment unscorable — you can no longer tell whether you are evaluating the candidate or the LLM. The most senior engineers stop accepting these interviews because the signal is so noisy.
The contradictory hybrid. "Use AI for the take-home but not the live round." Sounds reasonable until the candidate asks why, and the honest answer is "because we cannot detect AI use in the take-home." That is a confession, not a policy.
The framework: five things every AI policy must declare
A defensible AI policy has five parts. Skip any of them and the policy will collapse the first time a candidate pushes back.
1. The rule, in one sentence
Pick one of three positions and commit:
- Allowed and disclosed. "You may use any AI tools you would use on the job, but tell us which ones during the walk-through." This is the position we recommend for most engineering roles in 2026 — it matches how the job is actually done and lets you measure judgment over rote generation.
- Allowed for ideation, not generation. "Use AI to brainstorm or look up syntax. Do not paste AI-generated solutions." Workable for early-funnel screens where you want to gauge raw problem solving.
- Banned with verification. "No AI tools during this assessment." Reserve for highly regulated roles (defense, certain healthcare) where the underlying job genuinely prohibits AI use. Pair with an integrity layer that can defend the claim.
Pick one. Do not say "we encourage candidates to use AI thoughtfully" — that is not a rule, it is a vibes statement.
2. The interviews where the rule applies
The same rule does not need to apply at every stage. A common structure that works:
| Stage | Rule | Why |
|---|---|---|
| Take-home | Allowed and disclosed | Measure how candidates work with AI on real tasks |
| Live coding | Banned for code generation, allowed for documentation lookups | Test thinking-on-feet |
| System design | Banned for diagram generation, no LLM tabs open | Discussion-based; AI distorts the conversation |
| Live debugging | Allowed and disclosed | Mirrors how engineers actually debug |
Whatever you choose, name every interview stage and the rule for each one. Don't make candidates guess at the boundary.
3. How the rule is communicated to candidates
Three places it must appear, in this order:
- The recruiter prep email. Sent before any assessment. Plain English, no legalese: "For the take-home, you may use Copilot, ChatGPT, or any AI tool you would use at work. Be ready to walk us through your code, including which parts you wrote and which an AI generated."
- The assessment start screen. A consent step the candidate must check before beginning, repeating the rule for that specific assessment.
- The live round briefing. Thirty seconds at the start of every live interview: "For this round, no AI tools. Please close any LLM tabs."
Surveys consistently show that the worst candidate experience outcome is not strictness — it is inconsistency. Candidates who get the same rule in three places trust the process.
4. How the rule is enforced
A policy you cannot enforce is worse than no policy at all — it teaches candidates that your rules are decorative. Enforcement does not mean surveillance; it means designing the assessment so the rule is checkable.
For "allowed and disclosed" policies, the enforcement is the walk-through. Candidates explain their work; AI use becomes legible. You are not catching cheating — you are validating skill.
For "banned" policies, you need real instrumentation. ClarityHire's integrity layer is built for this: paste detection, keystroke biometrics, code coherence analysis, and tab-switch tracking together make AI use visible without browser lockdown. The point is not to gotcha — it is to enforce the rule you committed to in step 1.
For "ideation, not generation" policies, enforcement is the hardest. Most teams that pick this option end up effectively running "allowed and disclosed" because the boundary is impossible to police. If you find yourself here, consider just upgrading to "allowed and disclosed" and saving the energy.
5. How the rule changes scoring
This is the part most policies forget. If AI is allowed, your rubric must rate something AI cannot do for the candidate. Three useful axes:
- Judgment. Why did you pick this approach? What did you reject and why?
- Iteration. Show me the second version after I tell you the requirements changed.
- Communication. Walk me through this code as if you were doing a PR review.
These are the dimensions where senior engineers separate from AI-augmented juniors. A scorecard tuned to them keeps working even when every candidate has Copilot open.
If AI is banned, your rubric should reward the exact opposite — raw fluency, speed-without-paste, and the ability to derive an answer from first principles. Different rubric, different signal.
Sample policy you can adapt
Here is a one-pager you can lift, adjust the role-specific bits, and ship to your recruiting team this week.
Our policy on AI tool use in interviews
Take-home assessment: You may use any AI coding assistant (Copilot, ChatGPT, Claude, Cursor, etc.) that you would use in day-to-day engineering work. Please be ready to walk us through your code in the follow-up interview, including which parts you wrote yourself and which an AI generated. We will not penalize honest AI use; we will assess your judgment, debugging, and ability to extend your own work.
Live coding interview: No AI tools during this round. Please close any LLM tabs before joining. The goal is to see how you reason through a problem in real time.
System design interview: No AI tools. Discussion-based.
Why this policy: We hire engineers who use AI well and who can think independently. This policy lets us measure both. We use behavioral integrity signals (paste detection, code coherence) during the live rounds to keep the playing field even — we do not use them to draw conclusions without talking to you first.
That last sentence matters. It tells the candidate the integrity layer is enforcement, not surveillance, and that no decision is made without conversation. Candidates who trust the process are more honest in it.
What to do next
If your team does not have a written AI policy, do these in order this week:
- Pick a rule for each of your interview stages (use the table above as a starting point).
- Write the candidate-facing one-pager and put it in the recruiter prep email template.
- Adjust your live-round briefing script to repeat the rule out loud.
- Update your scorecard so it rates judgment and iteration, not just correctness.
- If you went with "banned" anywhere, turn on the integrity layer for those rounds. A banned policy without enforcement is the worst of all worlds.
A clear AI policy is not anti-AI. It is what separates teams that hire well in the AI era from teams who pretend it is still 2022.