How to Handle a Candidate Using a Second Monitor in a Live Coding Interview
The realistic picture
Most candidates have multi-monitor setups. They use them for everything: documentation, the problem statement, their notes, a chat window with a recruiter, an LLM tab. Some uses are fine. Some are problematic. A blanket "no second monitor" rule is unenforceable, alienates candidates who have legitimate reasons (accessibility, ergonomics, dual-language workflows), and pushes the determined cheaters to phone-on-the-desk-out-of-frame anyway.
The right policy distinguishes use from misuse.
What to allow explicitly
- Documentation tabs (MDN, language docs, framework docs)
- The problem statement open in a separate window
- A notepad for scratch work
- IDE features the candidate normally uses (autocomplete, linters, language servers)
What to ask candidates not to do
- Use AI assistants (ChatGPT, Copilot inline suggestions) during a live coding round where the goal is to evaluate the candidate's reasoning, not their tool fluency
- Have a separate person on a call or in the room
- Refer to materials prepared specifically for this interview
For take-home rounds, "use whatever tools help you, be ready to explain in the walk-through" is the better policy. Different rounds, different rules.
How to communicate the policy
In the interview invite, explicitly: "This is a live coding round. We want to see your reasoning, so please don't use AI coding assistants or have someone else helping. You're welcome to use docs, notes, and your normal IDE. The follow-up walk-through will probe your code."
Candidates appreciate clarity. The vague "act with integrity" framing is worse than specifics — both for the honest candidate (who worries about doing something wrong) and for catching the dishonest one (who can claim ambiguity).
What to do during the interview
- Camera on. Not because you'll spot a second monitor visually — you usually won't — but because the social norm of being on camera makes off-camera shenanigans psychologically harder.
- Screen share the whole screen, not just the IDE. The candidate's other windows and tab strip are visible. This catches obvious cases (a Stack Overflow tab labeled "interview answer" — yes, it happens).
- Ask process questions, not just outcome questions. "Walk me through what you're thinking before you type." A coached candidate who is reading from another window will often pause oddly between thinking and typing. The pattern is more visible in conversation than in code.
The follow-up that matters
Whatever happened during the live round, a 5-minute "walk me back through what you did" at the end resolves most ambiguity. A candidate who wrote their own code can replay their reasoning. A candidate who copy-pasted will struggle.
ClarityHire surfaces a "tab-switch frequency" and "paste-event" signal during live coding rounds — context, not verdict. The interviewer sees if there were 47 tab switches during a 30-minute coding round and can decide whether to probe.
When to escalate
If you have specific evidence (clear paste from off-screen, audible second voice, visible person on camera in reflection), pause the interview, address it directly, and decide whether to continue or end. Most interviewers under-react to clear evidence and over-react to ambiguous signal. Bias toward addressing clear cases promptly and ignoring ambiguous ones.
The summary
Don't try to enforce rules you can't observe. Set explicit, role-appropriate expectations. Use the walk-through as your real check. Reserve hard responses for unambiguous cases. The goal is hiring decisions, not catching cheaters.