Codility Candidate Report Explained: Score, Code Playback, Plagiarism, and Recruiter Review

A Codility candidate report combines several kinds of evidence. A score describes assessed work; code history helps reconstruct changes; a similarity signal identifies something to review. Reading one as if it answers every question leads to poor conclusions about both performance and integrity.

This guide retains those distinctions and adds a complete fictional three-task report, a reviewed-score revision and a finished feedback request. The tables are original teaching examples, not screenshots of Codility’s interface or disclosures about a real candidate. All task names, points, timings and reviewer comments in the worked case are invented.

Start with the task and the report version

Codility’s employer-facing report guide describes an overall result, individual task results, submitted work and review information. It documents manual task-score changes. A candidate may receive only a small feedback extract rather than the employer’s full report, so identify what was actually shared before interpreting it.

Record the assessment date, task type, displayed points, maximum points, and whether the number is automated or reviewed. If those details are absent, mark them unknown. A percentage without a denominator or task breakdown can conceal very different weaknesses.

The linked guide explains question formats and hidden-test practice. Its cross-company questions are rehearsal material, not a claim that Codility supplies those prompts to every employer.

Do not read the table below as a recommended passing bar. The fictional employer has not supplied one. Nor should a reviewer derive a hiring outcome from the overall number without the relevant job criteria and remaining evidence.

Annotated report: three different tasks

Original example. Session S-17 contains three tasks, each assigned a maximum of 100 points for this teaching case. Its initial summary is 230 points out of 300, or 76.67% when rounded to two decimal places. The marks use explicitly stated hypothetical rules, not a universal platform formula.

Task	Type and fictional evaluation	Initial result	Evidence to inspect
A: distinct delivery stops	Classic algorithm; ten equally weighted assessed cases	60/100	Submitted algorithm, correctness and large-input failures
B: completed deliveries by zone	SQL; ten equally weighted correctness cases	80/100	Join/filter semantics and output rows
C: repair a cart service	VSCode Native; an invented ten-criterion reviewer rubric	90/100	Final files, tests and available IDE replay

Task A passes four small correctness cases and two of six large-input cases. Six passing cases earn 60 points under this example’s equal ten-point rule. It is possible to pass visible examples and still miss assessed cases: Codility’s scoring documentation says the examples do not contribute to the score. “Performance” concerns behavior on larger inputs where the task measures it, not how quickly a candidate types.

The fictional code repeatedly scans the already-seen stops. With all distinct IDs, the number of pair comparisons grows approximately as n(n−1)/2: 1000 stops require 499500 comparisons; 10000 require 49995000, roughly 100 times as many. A set-based solution has expected linear work with an appropriate hash implementation, at the cost of memory for distinct IDs. That identifies a plausible practice gap; it does not reveal the real hidden test inputs or platform timeout.

Task B’s invented query uses an inner join from zones to completed deliveries. It drops a zone with zero completed deliveries when the specified output requires that zone with a count of zero. Moving a status filter between WHERE and a suitable join condition can also change a left join’s semantics. The report’s 80 alone would not tell you which of these happened; inspect the submitted query and the permitted feedback.

Task C’s fictional reviewer gives nine of ten criteria credit because a repair handles the main cart path but has no regression test for removing the last item. This task’s rubric and 90 are invented. Do not transfer the classic algorithm’s test-count model to a project task or infer that all VSCode tasks are scored manually.

A reviewed score can change without changing the submission

Continue the same fictional session. A reviewer examines Task B and adds ten points under an explicitly fictional partial-credit decision. The submitted query remains the same. Task B now shows 90/100 and the overall total is 240/300, or 80%. The difference is 3.33 percentage points, not ten percentage points overall.

View	A	B	C	Overall
Initial fictional result	60	80	90	230/300 = 76.67%
Reviewed fictional result	60	90	90	240/300 = 80%

Keep the two versions distinct: initial result, reviewed result, timestamp and reason if supplied. Do not silently replace the old number in a personal postmortem and forget why it changed. Codility allows score editing, but this example does not establish how a particular company decides partial credit or whether your result received it.

Different maxima would change the calculation. If one task had 200 possible points while the others had 100 each, averaging the three displayed percentages would not generally equal achieved points divided by total available points. Read the actual report’s points and configuration. Our 300-point example deliberately removes that ambiguity.

The local arithmetic check confirms both totals, rounding and comparison counts. It does not reproduce Codility’s scoring engine. When building your own notes, separate verified arithmetic from assumptions about the task and employer policy.

Code history and replay answer different questions

Classic single-file tasks have their own timeline and code playback. A Code Evolution Chart summarizes activity and helps reviewers choose moments to inspect. Treat a jump in code size as a place to look at the work and context, not as access to the candidate’s unspoken reasoning.

The separately documented VSCode Native replay reconstructs file navigation, edits and terminal activity inside that IDE. As of the documentation checked for this guide, it is available for all Interview accounts and selected Screen accounts. Classic history and VSCode replay are not interchangeable features.

Codility lists limitations: paste/tab-switch signals are tracked but not yet displayed on the VSCode replay timeline; terminal and AI Copilot recordings can have gaps; a recording can be missing. The documented capture is within the IDE, with no access to data outside that assessment environment. Do not describe this replay as a guaranteed recording of the whole computer.

Fictional Task A history: at minute 12, an out-of-focus interval appears; at minute 14, a larger block is pasted; at minute 18, a verification occurs; at minute 22, the solution is finalized. These observations alone do not establish the source of the pasted block. A permitted local IDE is one possible explanation, but do not assert it happened without evidence.

Fictional Task C replay: the reviewer sees an edit to cart logic and a test command, but a short terminal interval is missing. The final files remain the primary work to examine. The gap cannot establish that all tests passed, nor can it establish that the candidate deliberately concealed activity.

Similarity warnings require context and task coverage

Codility’s Similarity Check compares applicable submissions with other submissions and web material. Its documentation says a warning does not necessarily mean cheating and recommends clarification. Exclusions include SQL, multiple-choice, project and VSCode content, among other task types. Check the applicable feature rather than assuming one warning panel covers every assessment task.

In the fictional report, Task A has an unresolved similarity warning. Task B and Task C are marked not applicable to this documented check, not “clean.” An unavailable or inapplicable signal supplies no affirmative clearance. Other configured integrity features may exist; their absence from this teaching table is not proof that they are disabled.

A useful clarification concerns the actual code: explain the data structure, the invariant, a failing edge case and what changes when the input increases. If a reference or tool was permitted and used, describe it accurately. Do not invent a local-IDE story, alter logs or memorize a false explanation to match a chart.

Keep the score and integrity review separate in your notes. A high score does not settle authorship, while a warning does not explain an algorithmic timeout. The employer needs to review the relevant evidence and rules; this article cannot adjudicate a private assessment.

A finished candidate feedback request

Use this example after an assessment when the company invites follow-up or has shared a result. Replace the bracketed details with accurate information. Do not claim you saw the employer report if you received only a percentage.

Subject: Feedback on my [role] assessment

Hello [recruiter name],

Thank you for coordinating my assessment on [date]. I received [the result or feedback actually shared]. If your feedback policy allows, could you share which skill area would be most useful for me to improve—correctness, handling larger inputs, task-specific implementation, or another criterion?

If the displayed result includes a manual review, it would help to know whether the feedback refers to the initial automated result or the reviewed version. I do not need hidden test inputs or proprietary task details.

If any part of my solution or use of permitted tools needs clarification, I am happy to explain the approach and walk through an example. Please let me know the appropriate next step.

Thank you, [your name]

This is a drafting example, not a message sent to anyone. Keep the final request short and neutral. If no integrity concern was raised, do not introduce one as if it exists. If one was raised, ask which task or event needs explanation through the employer’s review process rather than sending unsolicited private files or another person’s work.

Convert feedback into a focused postmortem

For fictional Task A, rebuild a comparable distinct-ID problem from a blank file. Begin with all-equal, all-distinct, empty-if-allowed and mixed duplicate inputs. Compare the set result with a simple quadratic oracle on small cases, then inspect growth on larger synthetic inputs. These are practice tests, not recovered hidden assessment cases.

For fictional Task B, create three zones: one with no deliveries, one with only cancelled deliveries and one with two completed deliveries. State the required output before writing the query. Add a duplicate joined row to see whether your schema assumptions justify COUNT, COUNT(DISTINCT ...) or pre-aggregation. Do not “fix” a count by adding DISTINCT without explaining why duplication exists.

For fictional Task C, reproduce the last-item removal failure and write a regression first. Then change the code and run existing tests. Note what state should remain after an empty cart: totals, item count, validation and persistence depend on the stated contract. An attractive architecture diagram does not substitute for the failing behavior.

Keep one short record per weakness: what evidence you have, what remains unknown, the smallest reproduction, the correction and the next check. If the employer cannot share more, acknowledge that limit. You can still improve a known pattern without pretending to diagnose a private report.

Frequently asked questions

Can I pass sample tests and receive a low Codility score?

Yes. Codility says example tests are not scored. A solution may fit the visible example and fail assessed boundaries or larger inputs. Use the task’s actual scoring criteria; do not infer the hidden cases from the overall percentage alone.

Does a similarity warning prove plagiarism or AI misuse?

No. Codility’s guidance treats a warning as grounds for clarification, not conclusive proof. Relevant task coverage and configured checks matter. A candidate should explain the actual solution and permitted tools accurately; the employer decides how to review the evidence.

Is VSCode replay a recording of my whole computer?

The documented VSCode Native replay captures activity inside the assessment IDE, not the entire computer. It is separate from classic-task history. Availability and recording gaps can limit what a reviewer sees, so absence of an event does not establish that it never happened.

Can a recruiter manually change the score?

Codility documents manual task-score editing for Screen and Interview assessments. If a number changes, ask whether it is the automated result, a reviewed result or another version. The fictional report here shows arithmetic, not a real candidate’s score adjustment.

What feedback should I request after a Codility assessment?

Ask which skill area or task needs improvement, whether the issue was correctness, scaling or another criterion, and whether clarification is needed. Request only feedback the employer can share. Avoid demanding hidden test inputs, proprietary task text or another candidate’s submission.

Sources and scope

• Reading a candidate test report: employer report and manual score editing.
• Automated Scoring Principles: example tests, correctness and task-specific performance.
• Session Replay for VSCode Tasks: availability, capture scope and gaps.
• Similarity Check and what to do: applicability and clarification.
• Understanding the Code Evolution Chart: activity summaries and review context.

Documentation checked October 9, 2026. All worked report data and the feedback request are original examples. Assessment configuration and employer feedback policy determine what is actually available.