Stop Candidates from Using ChatGPT during Technical Assessments

Hiring teams trying to figure out how to stop candidates from using ChatGPT during technical assessments are dealing with a major shift in technical recruiting. Traditional coding tests fail because large language models have memorized standard programming puzzles, algorithmic riddles, and LeetCode problems. When an applicant can copy a prompt, paste it into an AI tool, and get an optimal solution in seconds, a standard automated coding test stops measuring real engineering skill.

Preventing unauthorized AI assistance does not mean locking down applicant devices with invasive software. It means rethinking how you evaluate software engineers. If you shift the focus to debugging, system design, architectural trade-offs, and live spoken explanations, your assessments reward genuine problem-solving over prompt skills.

The Problem: LLMs Have Already Solved Traditional Coding Tests

For more than a decade, technical screening relied on isolated problem-solving tasks. Candidates got a problem description, an empty code editor, and a set of unit tests to pass.

Large language models excel at exactly this format. Puzzles like reversing a linked list, finding the shortest path in a graph, or balancing a binary tree are published across the web. Models trained on millions of these snippets don't need to reason through the problem. They recall the optimal solution instantly, complete with time and space complexity.

So when hiring teams use these tests, high scores no longer track strong engineering talent. A candidate who struggles with basic software design can pass an automated screen with a perfect score just by feeding the problem statement to an external tool.

Why Client-Side Signals Alone Fall Short

Many assessment providers responded to generative AI with browser locks, copy-paste blockers, and tab-switch monitoring. These signals are useful, but on their own they rarely solve the problem.

Candidates adapt to barriers that only add friction. If paste is blocked, an applicant can retype an answer from a second laptop, a tablet, or a phone. A second device on cellular data never shows up as a tab switch. Camera-based checks can catch someone looking away, but an automated flag with no context can't tell a candidate who is reading from a phone apart from one who is simply thinking.

The fix is not more surveillance. It is evidence a human can review. A flag is only useful when you can see exactly what happened at that moment and judge it fairly. You can learn more in our guide on how to prevent cheating in remote video interviews.

How to Stop Candidates from Using ChatGPT During Technical Assessments

To build a screening process that AI can't easily game, change what you test and how you evaluate the answer. Here are practical ways to modernize technical screening.

1. Shift from Green-Field Puzzles to Debugging

Software engineers rarely write isolated algorithms from scratch. Most of their work is reading existing code, understanding dependencies, fixing subtle bugs, and adding features to an established system.

Instead of asking candidates to write a sorting function, give them a small codebase with an existing bug. Ask them to find it, explain why it happens, and fix it without breaking anything around it.

AI models struggle with multi-file context, hidden dependencies, and ambiguous business logic. A candidate who leans on an LLM will spend longer framing the context in a prompt than it would take to read the code and fix the issue directly.

2. Evaluate Code Review and Refactoring Skills

Give candidates a working pull request that contains architectural flaws, poor naming, security vulnerabilities, or concurrency issues. Ask them to review it and write actionable feedback for a junior developer.

This exercise shows how an applicant thinks about maintainability, edge cases, and team standards. An AI tool can suggest generic style fixes, but an experienced engineer will spot how the changes affect production stability.

3. Ask for Architectural Trade-offs

Large language models can produce standard architecture blueprints, but they can't weigh context-dependent trade-offs without a lot of human prompting.

Frame your questions around real operational constraints:

• How would you design a caching layer when data freshness matters more than low latency?
• What are the trade-offs between an event-driven design and synchronous REST APIs for this specific workflow?
• How would you handle partial failures during a multi-step checkout process?

Ask follow-up questions that challenge the first answer. When an applicant has to defend their choices as requirements change, their real technical depth shows quickly.

Use Live Spoken Technical Assessments

The most reliable way to verify technical skill is to talk through the work in real time. Take-home challenges give dishonest applicants unlimited time to consult outside help. Live conversations require reasoning on the spot.

During a live technical assessment, ask candidates to explain their approach before they start typing:

• Why did you choose this data structure over an alternative?
• What happens to your implementation if available memory is cut in half?
• Where is the likely bottleneck in this database query?

A candidate relying on generated code will struggle to explain intermediate steps, justify design choices, or adapt when a new edge case comes up. Spoken follow-up questions quickly separate engineers who understand their code from those who copied an AI response.

Practical Integrity Checks That Keep Tests Fair

Redesigning your questions is the foundation of modern technical hiring, but integrity monitoring still matters. Fair assessments need consistent standards for every applicant.

Good integrity monitoring produces evidence, not just alarms:

• Paste and focus tracking: Logging paste attempts and tab switches shows when code arrives from outside the editor instead of being written in it.
• Visual and behavioural timeline flags: Recording the session with timestamped flags lets hiring teams check suspicious moments against the recording themselves instead of guessing.
• Interviews that survive drops: Saving the recording and transcript continuously during the session means a dropped connection doesn't wipe out an honest candidate's work.

These safeguards give you evidence without asking applicants to install anything on their own machines.

Build an Assessment Process That Respects Real Talent

Trying to stop candidates from using ChatGPT by banning technology outright is an uphill battle. The goal isn't to punish candidates for knowing that modern tools exist. It's to design evaluations that measure what an AI can't fake for them: understanding a system, debugging instinct, communication, and architectural judgment.

When you replace generic coding puzzles with real-world problems and live technical conversation, you protect your pipeline from automated cheating and find the engineers who will actually succeed on your team.

AiHire.io runs live AI technical interviews where candidates talk through their reasoning and write code in the same session, with a recorded integrity timeline your team can review. New accounts get $100 in free hiring credits to get started.

Questions people ask

Can plagiarism checkers detect code written by ChatGPT?

Traditional plagiarism checkers struggle with AI-generated code because large language models generate new variations rather than copying existing files verbatim. Specialized AI code detectors also suffer from high false-positive rates and can be bypassed by minor renaming or formatting changes.

Should companies allow candidates to use ChatGPT during coding tests?

Some companies allow AI tools as long as the assessment tests higher-level tasks like architecture, debugging, and code review. If you permit AI, design the test around realistic problems where code generation is only the starting point, not the final answer.

What is the best format to replace LeetCode-style technical tests?

Practical codebases with intentional bugs, code review exercises, and live technical discussions are the most effective alternatives. They measure real engineering workflow, system comprehension, and problem-solving without being vulnerable to simple prompt copying.