What does an employer typically see in an online coding assessment's score report?

## The report, not the number Candidates tend to picture the outcome of an automated assessment as a single score crossing a bar. What the employer usually receives is a document. Contents vary by platform and by what the employer has configured, but the common elements are stable: - **Per-problem score**, with the count of hidden tests passed and failed and often the category or name of each failing test. - **Timing**: when the assessment was started, when each submission arrived, how long was spent on each problem, and whether the window was used to the buzzer. - **Submission history**: how many times each problem was submitted and how the score moved across attempts. - **Integrity counters**: focus losses, paste events, similarity results, and any camera or screen capture where that was enabled and consented to. - **Comparison**: a percentile or benchmark against the pool of candidates who took the same assessment, which is why a raw score is hard to interpret from the outside. ## How the report becomes a decision Three patterns cover most employers. A **fixed threshold** — advance everyone above a set score — is simple and used heavily in high-volume junior hiring. A **relative cut** — take the top slice of a batch — moves the bar with the pool, so the same score can pass one week and not the next. A **human read** — a person opens the report, looks at the shape rather than only the total, and decides. In practice these are mixed: a threshold filters, then a person reads the borderline reports. The shape matters most in that last case, and it is where the per-problem breakdown earns its keep. On the invented assessment used through this leaf — a mid-size product consultancy screening junior frontend candidates over three problems in an 82-minute window, weighted 300, 120 and 180 — two reports at similar totals read very differently. One shows a full solve, a near-full solve, and a mispriced attempt abandoned at a sensible point. The other shows 51 minutes sunk into the first problem, a rushed second, and a third opened at minute 73 with nothing submitted. Both are ordinary; the second is legible as attempting the problems in the order given and timing out on the hardest, which is a process story rather than an ability story, and a reader who has run these screens recognises it immediately. ## What this implies while you are still in the window **Never leave a problem untouched.** Under per-test credit, a partial attempt banks something, and a blank problem produces the one shape a reader cannot interpret charitably. **Make your best version the submitted one.** The report records submissions, not the buffer contents at the buzzer. A better solution that was never submitted does not exist. **Assume the timeline is visible.** That is not a reason for anxiety, but it does mean a long unexplained silence followed by a complete solution is a visible pattern, and it is another argument for building incrementally. **Expect the aggregate to be compared, not read absolutely.** Since a percentile against the same assessment's pool is usually attached, arguing that a score was respectable in isolation carries no weight. ## Getting the report yourself Candidates can ask, and it costs nothing polite to ask. Practice varies widely: some employers share a summary, many decline as a matter of policy because the assessment is reused across candidates, and some platforms show you your own score immediately while showing the employer more than you see. Where you do get the hidden-test summary back, it is the most useful practice artefact available — it tells you whether points were lost to correctness, to boundary handling, or to scale, and those three have different remedies.