What Happens When a Coding Assessment Flags You

An integrity flag on a coding assessment is not a verdict. It is a probability score attached to your submission, displayed to the hiring team in a report you never see, and acted on entirely at their discretion. HackerRank publishes an overall precision of 85% for its AI plagiarism model, CodeSignal warns recruiters that a high Suspicion Score is not "a guarantee that a test-taker was cheating," and Codility states plainly that a similarity warning "doesn't necessarily suggest cheating." All three vendors tell employers to review flags manually before rejecting anyone. Whether that review happens is the part no candidate controls.

This article covers what the three largest assessment platforms document about flagging, as of August 2026: what triggers a flag, how accurate the vendors say it is, whether you are notified, and what you can actually do about it. It is written for candidates trying to interpret a silent rejection or a recruiter email that asks them to explain their solution.

What a flag actually is

None of these systems catch cheating. They score behavioral and code-level signals, then hand the score to a human.

HackerRank's AI plagiarism detection classifies flagged attempts as High or Medium confidence, drawing on copy-paste activity, structural similarity in code, iteration and timing patterns, and tab-switching away from the active test window (HackerRank, AI Plagiarism Detection). The flag surfaces in the candidate report alongside a keystroke replay tool that lets a reviewer watch how the code was typed.

CodeSignal's Suspicion Score runs from None to High and synthesizes paste events (size, frequency, and timing), code similarity matches, copying of the problem description, and language switches mid-attempt (CodeSignal, Using Suspicion Score).

Codility's Similarity Check works differently: it runs only on submissions at or above the passing score, cross-references every other solution the platform has received, and scrapes the web for leaked answers (Codility, Similarity Check and what to do). Scoring well is a precondition for being checked at all.

The distinction between these signals and proctoring matters. Proctoring records what happened during your session; flagging is a judgment applied to that recording afterward. For what the recording itself contains, see what HackerRank proctoring detects and records.

How accurate the vendors say flags are

HackerRank is the only one of the three to publish a number. Its documentation states the model has "an overall precision of 85%, meaning flagged sessions are correct 85% of the time" (HackerRank).

Read that carefully, because it is a stronger admission than it looks. Precision of 85% means roughly one in seven flagged sessions is wrong. It is a vendor-reported figure for the vendor's own model, and it says nothing about how many honest submissions get flagged in total — precision measures how often a flag is correct, not how often an honest candidate escapes one.

The same documentation notes a specific weakness: detection "is limited when evaluating questions requiring minimal effort" or when solutions run to very few lines. Short, conventional answers to common problems are exactly where independent candidates converge on identical code.

HackerRank's guidance to hiring teams follows from this. The company advises that teams "conduct a manual review of the flagged code to ensure a false positive doesn't disqualify an honest candidate" and explicitly asks them to "refrain from auto-rejecting a candidate based on the plagiarism flag" (HackerRank blog, published March 2023 and updated October 2023). CodeSignal's caution is blunter: "Innocent behaviors can sometimes look suspicious."

That is three vendors independently telling their own customers that the flag is a starting point for a conversation. Nothing obliges a recruiter to have it.

Why flag volume is up in 2026

CodeSignal reported in February 2026 that cheating and fraud attempt rates on proctored assessments "more than doubled, rising from 16 percent in 2024 to 35 percent," with entry-level assessments climbing from 15 percent to 40 percent (CodeSignal press release, 25 February 2026). Treat that as a vendor's measurement of its own detection output rather than a neutral census of candidate behavior — a rise in detected attempts partly reflects detection getting more aggressive.

The consequence for an honest candidate is arithmetic, and it is inference rather than a documented vendor claim: if flag volume rises while precision stays constant, the absolute number of wrongly flagged people rises with it. A fixed error rate applied to a much larger pile of flags produces more false positives, not fewer.

You will almost certainly not be told

HackerRank's candidate-facing documentation is unambiguous: "HackerRank does not share plagiarism check results with candidates" (HackerRank Candidate Support, Test Integrity and Plagiarism Detection). The same page lists what the platform treats as malpractice — copying code from books or websites, receiving help from another person, submitting code that closely matches another candidate's, exiting full-screen mode, and switching tabs away from the test window — and then directs candidates with questions to "contact your recruiter or hiring manager directly."

There is no appeal process, because the platform is not the decision-maker. The flag is a data point in a report sold to an employer; the rejection, if it comes, is the employer's. Neither party is obliged to tell you which one happened. A generic rejection email is compatible with a flag, a weak score, or a closed requisition, and you cannot distinguish them from the outside.

Ordinary behavior that scores as suspicious

Because the signals are behavioral, several unremarkable habits register:

• Pasting your own code. Paste events are scored on size, frequency, and timing, not origin. Boilerplate pulled from your own scratch file or a personal repository looks like a paste from anywhere else.
• Leaving the tab. Checking language documentation in another tab is a tracked signal on HackerRank. Whether it is treated as malpractice depends on the test's rules, which are set per assessment. Whether tab switching is detectable is a separate question from whether it is permitted.
• Working in your own editor. Drafting in a local IDE and pasting the finished solution compresses the keystroke timeline into one large paste with no visible iteration — the pattern HackerRank's model reads as external authorship.
• Solving a common problem the canonical way. Codility acknowledges that "similar submissions are merely coincidental" for tasks with an obvious idiomatic answer.
• Finishing fast. Speed is not itself a flag, but a strong score is what triggers Codility's Similarity Check in the first place.

For how paste tracking is implemented at the browser level, see what interview websites can detect about copy and paste.

If a recruiter asks you to explain your solution

This is the good outcome, and it is worth recognizing as such. Codility's own recommended workflow for a flagged report is to contact the candidate for clarification and to run a report-mode interview assessing whether "they can explain how they came up with this solution, their train of thought." A request to walk through your code means the manual review the vendors ask for is actually happening.

Answer it as a technical conversation, not a defense. Explain the approach you chose and why, name the alternatives you rejected, and be specific about which parts came from where — that you reused a utility function from a personal project, or consulted the standard library documentation mid-task, is a normal answer that also accounts for the signal. Vagueness about your own code is what turns an ambiguous flag into a confirmed one.

If you were working under conditions that shaped the signals — a flaky connection forcing reloads, an accommodation, an external editor because the in-browser one was unusable — say so plainly and early. None of that is incriminating, and it explains behavior the model has no context for.

Lowering the risk before you start

The controllable part is entirely upstream of the assessment.

Read the rules attached to the specific test rather than assuming a platform-wide policy; permissions on AI use, documentation, and external editors are set per assessment and vary widely between employers. Our guide to confirming whether AI use is permitted in a technical interview covers how to get that in writing before you sit down.

Beyond that: work in the provided editor where you can, so the keystroke timeline shows real iteration; keep the assessment window in full screen when the instructions ask for it; and if you do consult documentation, do it within whatever the rules allow rather than assuming nobody is counting.

None of this makes a flag impossible. A candidate who writes the obvious solution to a two-line problem can be flagged for similarity to a thousand other people who wrote the same obvious solution, and no amount of care prevents that.

What this does and does not tell you

The documented facts are narrow: three vendors publish what their systems measure, one publishes a precision figure, all three warn against treating a flag as proof, and one states it will not tell candidates anything. What no vendor publishes is how often employers ignore that warning — and that number, not the model's precision, decides what a flag costs you.

If you are trying to work out whether a specific rejection was an integrity flag, the honest answer is that you usually cannot, and the effort is better spent on the next assessment. The one thing that reliably changes your exposure is knowing the rules of each test before you take it. Start with how to verify what a given employer permits.