How a Coding Assessment Platform Detects Cheating in Remote Tests

A coding assessment platform detects cheating by combining several weak signals (paste events, tab switches, keystroke playback, code similarity across candidates, AI-generated code likelihood and identity checks) and then confirming doubts with a short follow-up conversation about the candidate's own code. No single signal is proof. Together, they tell you where to look.

That's the short answer. The longer one matters more, because the way you handle integrity shapes who applies, who finishes your test and whether good candidates feel accused of something they didn't do. Below we cover what cheating actually looks like in remote tests today, which signals are worth your attention, how to avoid unfair calls, how to write tasks that are hard to outsource, and what to tell candidates up front.

What does cheating in a remote coding test actually look like?

Most hiring teams picture one thing when they hear "cheating," usually someone pasting an answer from a website. In practice, there are four distinct patterns, and each one leaves different traces.

AI-generated solutions

This is the most common form now. A candidate pastes the task into an AI coding assistant, gets a working answer and submits it with minor edits. Sometimes the whole solution arrives in one paste. Sometimes it's typed out by hand from a second screen, which looks more natural in the logs. The tell is rarely the code itself. It's the mismatch between a polished submission and a candidate who can't explain the choices in it.

Proxy test takers

Someone else sits the test. It might be a friend, a paid service or a more senior contact. Proxy taking is harder to spot from code alone, because the code is genuinely written by a human who understands it. It just isn't the human you're hiring. Identity checks and a live follow-up are the main defenses here.

Sharing leaked tasks

If you've used the same take-home for a year, assume it's been posted somewhere. Candidates who have seen the task before tend to finish unusually fast, skip exploratory steps and produce code that closely matches other submissions. This isn't always malicious. A candidate may have practiced on a public copy without knowing it was your task.

Copying from colleagues or classmates

Two candidates from the same bootcamp, university cohort or previous employer sometimes apply together and share approaches, or share full solutions. Cross-candidate similarity is the signal that catches this, and it's one that individual reviewers almost never notice on their own because they don't read every submission side by side.

AI technical interview · transcript

AI interviewer

Your rate limiter stores hits in memory. What happens when the service runs on three instances?

Candidate

Each instance would count separately, so a customer could send three times the limit. I would move the counter to a shared store with an expiry.

AI interviewer

Two of your tests failed on the window reset. Walk me through what you would change.

Rubric

Understands own code Scaling trade-offs Test strategy

Which integrity signals matter, and why is none of them proof on its own?

Every signal below has an innocent explanation. That's why we treat them as reasons to look closer, never as verdicts. The table summarizes what each signal shows and the most common benign cause.

Paste events

A paste of three lines is nothing. A paste of an entire 80-line solution in the first minute is worth a look. What helps is context: when the paste happened, how large it was, and whether the candidate edited it afterward. A big paste followed by careful debugging tells a different story from a big paste followed by immediate submission.

Tab switches

Tab switching is the noisiest signal. Developers look things up constantly, and a test that forbids documentation tests memory, not skill. If your rules allow docs, tab switches only matter when they line up with other signals, for example a long absence followed by a large paste.

Keystroke playback

Playback lets a reviewer watch how the code was built. Real problem solving usually looks messy: a function stub, a test run, a fix, a rename, a deleted approach. Transcription tends to look like a typist reading from a page, top to bottom, with almost no edits. Playback is one of the most useful signals precisely because it shows process, not just output. It's still not proof. Some strong engineers really do think first and type once.

Code similarity across candidates

Similarity checks compare structure, not just text, so renaming variables doesn't hide a copied solution. The catch is that short tasks naturally converge. Two people solving "reverse a linked list" will write near-identical code. Similarity is meaningful on longer, open-ended tasks where many valid designs exist.

AI-generated code likelihood

These estimates are probabilistic and imperfect. They look at style, structure and patterns typical of generated code. Treat a high score as a prompt for a follow-up question, never as grounds for rejection. A conscientious developer who writes tidy, well-commented code can score high. Someone who generated code and then roughed it up can score low.

Identity checks and webcam snapshots

An identity check (a photo ID matched against the person taking the test) targets proxy test takers directly. Optional webcam snapshots, taken only with the candidate's explicit consent, add a second layer. Both raise privacy questions, so use them in proportion to the role. A senior engineer with production database access justifies more verification than an internship screen.

How do you avoid false positives and treat candidates fairly?

A false accusation costs you a good candidate and, often, your reputation in a small local developer community. Fairness isn't a soft add-on to integrity checks. It's what makes them usable.

• Require at least two independent signals before you even flag a submission for review. A single tab switch or a single paste is never enough.
• Look at the timeline, not the counts. Ten tab switches spread over an hour of steady work mean little. One long absence, then a full solution, means more.
• Calibrate on your own team. Have two or three of your engineers take the test honestly and look at their signals. You'll quickly see what normal looks like, including normal pastes and normal tab use.
• Separate the reviewer from the decision. The person who reviews integrity signals shouldn't be the only person who decides. A second reviewer catches overreactions.
• Give the candidate a chance to explain. Most doubts disappear in a five-minute conversation. Some get confirmed. Either way, you've made a decision based on evidence, not suspicion.
• Account for accessibility. Candidates using screen readers, dictation software or other assistive tools can produce unusual paste and keystroke patterns. Ask about accommodations before the test, not after.
• Keep scoring blind. Integrity review shouldn't be influenced by a candidate's name, photo, age or background. Bias creeps into "suspicion" very easily.

One more thing: decide in advance what happens after a confirmed violation. Usually that's a polite decline. It shouldn't be a public accusation, and it shouldn't follow the candidate into future applications without a review.

Scorecard · Candidate 3294 · Senior Laravel developer

MK

Blind review on

Name and photo hidden until shortlist

92

overall

Core language74

Web framework75

Databases85

Testing76

System design94

Code

85

Interview

92

Integrity

Clean

How do you design coding tasks that are hard to outsource?

Detection catches cheating after the fact. Good task design makes it pointless in the first place. The goal is a task where an AI coding assistant or a helper gives a candidate a head start, but not a finished answer, and where the real signal comes from judgment rather than output.

Principles for outsourcing-resistant tasks

1. Start from an existing codebase. Give candidates a small, slightly messy repository with a bug to fix or a feature to add. Reading unfamiliar code is hard to fake and highly predictive of real work.
2. Use your domain, not textbook puzzles. A task about reconciling invoice line items or throttling webhook retries is far less likely to have a ready answer than a classic algorithm question.
3. Ask for trade-offs in writing. A short note on "what you'd change with more time and why" reveals understanding quickly. Generic answers stand out.
4. Include hidden test cases. Visible tests guide the candidate. Hidden tests covering edge cases check whether they thought beyond the obvious.
5. Rotate and vary. Keep two or three versions of each task and change parameters regularly so leaked copies go stale.
6. Keep it short. Long take-homes invite outsourcing. A 60 to 90 minute task respects the candidate's time and makes it less tempting to hand off.

A sample task outline

You're given a small service that processes incoming payment events and writes them to a store. Customers report duplicate charges after network retries. Find the cause, fix it so processing is idempotent, add tests that prove the fix, and write five to eight sentences on how you'd handle this at ten times the event volume. You may use language documentation. Please tell us if you used an AI coding assistant and for what.

Notice the last line. Some teams allow AI assistants as long as candidates disclose it, because that mirrors how many engineers work day to day. If you go that route, your evaluation shifts toward review quality, test design and the written reasoning. Either policy can work. What matters is that it's stated clearly. Our guide on what to test at each seniority level goes deeper into task scope and scoring.

Why is a follow-up interview on the candidate's own code the strongest check?

Every signal above is indirect. A follow-up conversation is direct. If a candidate wrote the code, they can explain it, change it and defend it. If they didn't, that usually becomes obvious within a few questions, and no detector or webcam can match that clarity.

The key is that the questions are about their solution, not generic trivia. Generic questions can be answered by anyone with an assistant open. Questions about specific lines, specific choices and specific changes cannot.

Example follow-up questions

• "Walk me through why you chose this data structure here instead of a list."
• "This function handles an empty input. What happens if the input contains duplicates?"
• "If we needed to support a second event source tomorrow, which part of your code changes first?"
• "I see you used a lock here. What would go wrong if we removed it?"
• "Change this function so it returns the count of skipped events too. Talk me through it as you go."
• "Which of your tests would fail first if the fix were reverted?"

The live change request is especially telling. A candidate who understands their code makes the edit in a minute or two. A candidate who doesn't often needs to read their own submission like a stranger would.

Keep the follow-up short (15 to 25 minutes is usually plenty), run it for everyone who passes the test rather than only the people you suspect, and score it with a rubric. Running it for everyone removes the sense of accusation and gives you useful signal on communication and depth anyway. A technical interview that builds questions from the candidate's own submission does exactly this, and it's where most integrity doubts get resolved one way or the other.

What should you tell candidates about integrity checks?

Transparency deters cheating and builds trust at the same time. Candidates who know what's monitored and why are less likely to try shortcuts and less likely to feel ambushed. Here's a policy template you can adapt.

Policy template for candidates

How our coding test works. This is a timed (or take-home) exercise in a browser editor. You can run your code against sample tests as often as you like.

What's allowed. Official language and framework documentation. Your own notes. [Choose one: No AI coding assistants. / AI coding assistants are allowed if you tell us how you used them.] Please don't ask another person for help.

What we record. Paste events, when the editor loses focus, and a replay of your typing so a reviewer can see how the solution was built. We compare submissions for similarity. [If used: With your consent, occasional webcam snapshots. An identity check before you start.]

How we use it. These signals never decide anything on their own. If something looks unusual, a person reviews it, and we'll ask you about it in conversation before making any decision.

What comes next. If you pass, you'll have a short conversation about your own solution. It's the same for every candidate.

Your rights. You can ask which parts of the process are scored automatically, see the rubric, and request a human review of any result. Tell us in advance if you need accommodations.

Send this with the test invitation, not buried in a terms page. Keep the language plain. If your process is international, check local rules on recording and biometric data before enabling webcam or identity checks, and make sure consent is real (a candidate who declines webcam snapshots should still be able to complete the test through another path, such as a longer follow-up).

What should you look for in a coding assessment platform?

If you're choosing tooling, integrity features are only useful when they're paired with fairness controls and a way to confirm doubts. Use this checklist when you compare options.

• Signals with context. Paste events, focus changes and keystroke playback shown on a timeline, not just as totals.
• Cross-candidate similarity that compares structure, not only exact text.
• AI-generated code likelihood presented as an estimate with clear caveats, never as a pass or fail.
• Optional, consent-based verification. Webcam snapshots and identity checks you can switch on for sensitive roles and off for others.
• Real environments. A sandbox that runs real test cases, including hidden ones, in the languages you hire for.
• Follow-up built in. A way to question candidates on their own code, with a transcript and rubric you can review later.
• Candidate transparency. Candidates can see what's scored automatically, see the rubric and request a human review.
• Blind scoring. Evaluation that ignores name, photo, age and gender.
• Human decision. The platform informs, your team decides.
• Predictable cost. Per-attempt pricing quietly discourages you from testing enough candidates. Flat pricing removes that pressure.

DeveloperHiring was built around this sequence. The coding assessment runs in a browser sandbox with real test cases across 30+ languages, as a take-home or timed test. Integrity signals (paste and tab-switch events, keystroke playback, code similarity across candidates and AI-generated code likelihood) appear on each result, with optional webcam snapshots taken only with consent and an identity check on the Scale plan. The AI technical interview then asks follow-ups on the candidate's own solution and produces a transcript and rubric.

Candidates see which stages are AI scored, can view the rubric and can request human review, and scoring is blind to name, photo, age and gender. Your company always makes the final call. Plans use flat monthly pricing with no per-attempt overage, so you can test every serious applicant instead of rationing invitations.

How do you put this together into a simple process?

Here's a workable sequence for most teams hiring remotely.

1. Publish your integrity policy with the test invitation, including whether AI assistants are allowed.
2. Use a short, domain-specific task built on an existing codebase, with hidden tests and a brief written component.
3. Review signals in context. Flag only when two or more independent signals line up on the timeline.
4. Run a follow-up on every passing candidate's own code. Include one live change request.
5. Decide with two reviewers and a rubric. Document the reason for any integrity-related decline.
6. Rotate tasks every few months, and immediately if you find a leaked copy.
7. Review your false positives. Each quarter, look at flagged candidates who turned out to be fine and adjust thresholds.

None of this requires treating candidates as suspects. It treats the test as evidence and the conversation as confirmation, which is how you'd evaluate any engineer's work once they're on the team.

Frequently asked questions

Can a coding assessment platform prove that a candidate cheated?

Not on its own. Paste events, tab switches, similarity scores and AI likelihood estimates all have innocent explanations. What they can do is show you where to look. The most reliable confirmation is a short conversation in which the candidate explains and modifies their own code. If they wrote it, that's easy. If they didn't, it usually shows within a few questions.

Should we allow AI coding assistants during the test?

Either choice can work if you state it clearly. Banning assistants tests unaided problem solving. Allowing them with disclosure mirrors how many engineers work and shifts your evaluation toward judgment, testing and explanation. The mistake is leaving the rule unstated, which punishes honest candidates and rewards those who quietly ignore an assumption nobody wrote down.

How accurate are AI-generated code detectors?

They're probabilistic estimates, not verdicts. Clean, conventional code written carefully by a human can score high, and generated code that has been edited can score low. Use a high score as a reason to ask the candidate about specific choices in their solution, and never as the sole basis for rejecting someone.

Is webcam monitoring necessary for remote coding tests?

Usually not. Webcam snapshots and identity checks help against proxy test takers, which matters more for senior or high-access roles. For most positions, a well-designed task plus a follow-up on the candidate's own code catches the same problems with less intrusion. If you use a webcam, get explicit consent and offer an alternative path for candidates who decline.

How often should we change our coding tasks?

Rotate between two or three versions of each task and refresh them every few months. Replace a task immediately if you find a copy posted publicly or notice many submissions that closely match each other. Changing parameters, sample data or the scenario is often enough to make a leaked version useless without rebuilding the whole exercise.