What kinds of behaviour do proctored online coding assessments typically flag for review?

## What proctoring means on an assessment platform Proctoring here rarely means a live invigilator. It usually means instrumentation: the assessment page records a handful of signals while you work and attaches them to the score report the employer receives. The platform generally does not decide anything. It counts things, and a human decides what the counts mean. The signals that appear most often: - **Window or tab focus loss** — a count, and sometimes durations, of times the assessment page stopped being the active window. - **Paste events** — how many, and how large. Some platforms record the pasted length; some record the content. - **Typing rhythm** — long silences followed by a large block of finished code look different from incremental authoring, and playback of the editing timeline is a feature on several platforms. - **Similarity** — an automated comparison of your submission against other candidates' submissions for the same problem and against widely published solutions. - **Camera or screen capture** — present only where the platform offers it and the employer turns it on, always behind a consent screen at the start. What is permitted and what notice is required varies by jurisdiction and by employer policy, so treat the notice you are shown as the authority for that assessment rather than assuming a universal rule. ## Read the rules screen; it is part of the test The most common self-inflicted problem is not cheating but guessing. Norms genuinely differ: one employer allows an external editor and open documentation, another allows documentation but not an editor, another asks you to stay in the browser tab entirely. That is stated on the instructions or consent screen, which many candidates click through in a hurry because the countdown is visible. Worth checking before the timer starts, on the invented assessment used through this leaf — a mid-size product consultancy running three problems in an 82-minute window for junior frontend candidates — the rules screen answered all of the following: whether an external editor was permitted, whether the window was global or per problem, whether the timer began at the invite link or at the first problem, and whether documentation lookups counted as leaving the assessment. ## Innocent behaviour that still reads as a flag Counters have no context. If the rules allow you to draft in your own editor, the paste event that brings your own code back into the browser is logged exactly like any other paste. That is not a reason to avoid a permitted workflow, but it is a reason to know the flag exists and to be able to explain it plainly if asked: the code is yours, the workflow was permitted, and the editing history supports it. Two focus losses to check documentation the rules allow are ordinarily unremarkable. What draws scrutiny is a pattern — repeated focus loss timed against large pastes, a submission arriving with no incremental editing history, and a high similarity score together. ## What actually happens when something is flagged Practice varies by employer and is worth stating carefully: many treat a confirmed integrity failure as ending the process for that role, and some record it against future applications on the same platform or with the same employer. Others ask the candidate to explain, or re-test with a live interviewer. What is fairly consistent is that a raw counter alone does not usually end anything; a similarity match against another candidate's near-identical submission is the signal that reliably does. ## The candidate's version of the rule Do permitted things openly and impermissible things not at all. Do not paste in a solution you found; do not have a second person in the room or on the call; do not run the assessment for someone else. Beyond that, the defensible position is simple and does not require guessing at the platform's internals: you followed the rules on the screen you were shown, and the editing history of your submission looks like someone solving a problem, because that is what happened.