Building Cheat-Proof Technical Assessments

Technical assessment cheating is a real problem. Studies suggest up to 30% of candidates attempt some form of dishonesty during remote assessments. But the solution isn't to create a surveillance state—it's to design assessments where cheating is both difficult and pointless.

Here's how we approach assessment integrity at InterviewLM.

The Philosophy: Detection Over Restriction

Traditional anti-cheating measures focus on restriction: disable copy-paste, lock the browser, require webcam monitoring. These approaches have problems:

• They create a hostile candidate experience
• They generate false positives from legitimate behavior
• They're often bypassable with moderate effort
• They don't actually test what matters

Our approach is different. We focus on detection and evaluation rather than restriction. We give candidates reasonable freedom, then analyze their behavior to distinguish legitimate work from suspicious patterns.

Layer 1: Isolated Sandbox Environments

Every candidate runs in their own isolated container:

• No cross-contamination: Candidates can't access each other's work
• Controlled networking: Access to our AI assistant and allowed resources only
• Ephemeral by design: Containers are destroyed after each session
• Resource limits: Prevents abuse and ensures fair conditions

This isolation means candidates can't easily share answers or access unauthorized resources without us knowing.

Layer 2: Network Access Control

We use allowlist-based network controls:

Allowed:

• Our AI assistant
• Package managers (npm, pip, etc.)
• Official documentation sites
• Stack Overflow (read-only)

Blocked:

• External AI services (ChatGPT, etc.)
• Code sharing platforms
• Messaging and communication tools
• Arbitrary external servers

This ensures all AI interaction happens through our monitored channel, giving us complete visibility into how candidates use AI assistance.

Layer 3: Comprehensive Session Recording

We record everything within the assessment environment:

• Every keystroke and code change
• All AI conversations
• Terminal commands and output
• File system operations
• Timing data

This creates a complete audit trail. If we ever need to investigate suspicious behavior, we can replay the entire session.

More importantly, this data powers our behavioral analysis...

Layer 4: AI-Powered Behavioral Analysis

Our system automatically analyzes sessions for suspicious patterns:

Copy-Paste Detection Large blocks of code appearing without typing suggest external sources. We flag these for review while acknowledging that some copy-paste (from AI responses, documentation) is legitimate.

Typing Pattern Analysis Sudden changes in typing speed or style can indicate someone else took over. Our AI looks for these discontinuities.

Tab Switching Patterns Excessive window switching is logged. While some switching is normal, patterns suggesting external resource access are flagged.

Code Similarity We compare submissions against known public solutions and other candidates' work. Similar solutions aren't automatically disqualifying (there are often limited ways to solve a problem correctly), but they trigger closer review.

Layer 5: Evaluation-Based Detection

Here's the key insight: in an AI-collaborative assessment, the process matters as much as the outcome.

Even if someone gets external help with the final code, our scoring system evaluates:

• How they interacted with AI throughout the session
• Whether they demonstrated understanding through modifications
• If their behavior patterns match someone learning vs. someone receiving answers

A candidate who copies in perfect code but shows no learning trajectory will score poorly on our AI collaboration dimensions—even if their code works perfectly.

The Human Element

Automated detection is powerful, but humans make final decisions. Our flagging system surfaces concerning patterns for reviewer attention, but we never automatically fail candidates.

This matters because:

• Context matters (a candidate might have a legitimate reason for unusual behavior)
• False positives happen (and are very costly)
• Some "cheating" is actually just good research skills

Creating a Positive Experience

Throughout all of this, we maintain a positive candidate experience:

• No invasive webcam monitoring
• No screen recording outside our sandbox
• Clear communication about what's monitored
• Focus on evaluation, not surveillance

Candidates know they're being recorded within the assessment environment, but they're not made to feel like criminals. This matters for employer brand and for getting genuine performance from candidates.

The Bottom Line

Perfect anti-cheating is impossible. But by combining isolation, monitoring, and evaluation-based detection, we make cheating both difficult and largely ineffective.

More importantly, we do this while maintaining the positive candidate experience that top developers expect.

Have security questions? Visit our [Security & Compliance](/docs/security) documentation or [contact our team](/support).