What does a 0 percent performance score on Codility mean?

It means your solution failed every test in the performance group. Those tests use large inputs, typically arrays of around 100,000 elements, and each one has its own time limit. Your logic is right, because the correctness tests passed, but the work your code does grows too fast with the input size, so every large test hits the limit and scores nothing.

How is a Codility task score calculated from test cases?

Each task runs against a fixed grid of hidden tests split into a correctness group and a performance group. Correctness percentage is the share of the correctness group you pass, performance percentage the share of the performance group. The task score reflects the whole grid, so on a ten test grid split six correctness and four performance, passing six of ten reads as 60 percent.

Why did my code pass every correctness test but fail every performance test?

Correctness tests are deliberately tiny, often arrays of one, two or forty elements, so a slow algorithm finishes them instantly and returns the right answer. Performance tests jump to around 100,000 elements. A nested loop that costs 1,600 operations at N equal to 40 costs 5,000,000,000 at N equal to 100,000. Same code, same correct answer, no chance of finishing in time.

Does a 0 percent performance score always mean a timeout?

No. Performance tests can also fail with a runtime error or a wrong answer. A recursive solution can exceed the stack depth only once the input is large. A 32 bit integer counter can overflow only once the values are large. Both produce zero on the performance group while every small correctness test still passes, and neither is caused by slowness.

What does Detected time complexity O(N**2) mean on a Codility report?

Codility times your submission across inputs of increasing size and fits a curve to the measured runtimes, then prints the closest match in its own notation, where O(N**2) means quadratic. It is an empirical estimate, not a reading of your source code, so it can be approximate. Seeing O(N**2) next to a 0 percent performance score confirms the shape of the problem.

Is it worth submitting a brute force solution on Codility?

Yes. Scoring is per test case, so a correct but slow solution that clears the whole correctness group still banks a substantial task score, whereas an unfinished optimal solution that does not compile scores nothing. Write the brute force first, submit it, then improve it. A working 60 percent on the clock beats an elegant idea that never ran.

Codility Performance Score 0%, Correctness 100%: Why It Happens

Codility grades each task against two groups of hidden tests. The correctness group uses tiny inputs, one element, two elements, forty elements, and only asks whether your answer is right. The performance group uses inputs at the top of the stated constraint, usually around 100,000 elements, and every test in it carries a time limit. A 0% performance score means every test in that second group failed, almost always because your algorithm does work that grows faster than the input does. Your logic is correct. Your complexity is not.

The two numbers, and the grid underneath them

Those percentages are not two opinions about your code. They are two counts. Each task has a fixed grid of hidden tests, each test belongs to one group, and each percentage is the share of its own group that passed. The pair 100% and 0% is not a contradiction, it is the signature of a correct brute force.

Below them the report lists every test by name with its verdict and running time, and prints a line like Detected time complexity: O(N**2). That is measured, not read off your source. Codility times the submission across inputs of growing size, fits the curve, and prints the nearest match in its own notation, where ** means "to the power of". It is an estimate, so it can be approximate, but next to a zero it is confirmation rather than news.

One task, two solutions, ten hidden tests

Take a task in the shape Codility sets. Given an array A of N integers and a target K, return the number of index pairs (i, j) with i < j where A[i] + A[j] == K. The constraints: N is within the range 1 to 100,000, each element within -1,000,000,000 to 1,000,000,000. Those two numbers are the task. The first says what your algorithm may cost, the second what your accumulator has to hold.

Solution A, the obvious one. Two nested loops, for i in range(N) then for j in range(i + 1, N), incrementing a counter whenever the pair sums to K. Four lines, unarguably correct, roughly N * N / 2 pair checks.

Solution B, the one the constraint is asking for. One pass with a hash map of value counts: for each element x, add the number of times K - x has already been seen to the running total, then record x. Every pair counted once, in index order, no second loop. O(N) time, O(N) space.

Both return identical answers on every input. Here is the grid: six correctness tests, four performance tests. Names vary by task, but this is the convention Codility reports use.

Test	Group	Input	Solution A	Solution B
`extreme_single`	Correctness	N = 1	OK	OK
`extreme_two`	Correctness	N = 2	OK	OK
`simple`	Correctness	N = 6, the statement's example	OK	OK
`small_random`	Correctness	N = 40	OK	OK
`small_negative`	Correctness	N = 60, mixed signs	OK	OK
`extreme_all_equal`	Correctness	N = 50, all identical	OK	OK
`medium_random`	Performance	N = 10,000	TIMEOUT	OK, 0.01 s
`large_random`	Performance	N = 100,000	TIMEOUT	OK, 0.08 s
`large_range`	Performance	N = 100,000, values 1 to N	TIMEOUT	OK, 0.08 s
`extreme_large`	Performance	N = 100,000, maximal values	TIMEOUT	OK, 0.09 s

Each failing line reads roughly TIMEOUT ERROR, running time: >6.00 sec., time limit: 4.00 sec. The seconds differ by task and language, because Codility scales the allowance rather than judging an interpreted language against C++ wall-clock, but the shape never changes: a measured time, a limit, no partial credit for getting close. On large_random, Solution A performs about five billion pair checks. On small_random, at N equal to 40, it performs 780. That is the whole report in two numbers, and nothing in the correctness group was built to expose the difference.

Where the 60% comes from

Six of the ten tests passed. That is the task score.

Submission	Correctness	Performance	Passed	Task score
Nested loops, interpreted language	6 of 6 = 100%	0 of 4 = 0%	6 of 10	60%
Nested loops, compiled language	6 of 6 = 100%	1 of 4 = 25%	7 of 10	70%
Hash map, 32 bit counter	6 of 6 = 100%	2 of 4 = 50%	8 of 10	80%
Hash map, 64 bit counter	6 of 6 = 100%	4 of 4 = 100%	10 of 10	100%

Row two is the same algorithm in a faster language. medium_random at N equal to 10,000 is fifty million pair checks, which a compiled language clears and an interpreted one does not, so identical logic lands on 25% or 0%. Row three is not slow at all, and gets its own section below. Row one is still 60%, which is 60 points more than an optimal solution that never compiled.

One caveat. Codility does not publish a universal grid size or weighting, and the hiring company configures which tasks appear, so treat six and four as the shape rather than a constant. Some tasks carry no performance group at all, in which case correctness is the whole score. The direction never varies: failing every performance test caps the task well below full marks, however clean the logic is.

When 0% performance is not about speed

Not every zero is a timeout, and the difference changes the fix. Read the verdict column, not the headline percentage.

Runtime error from recursion depth. A recursive walk is fine at N equal to 60 and dies at 100,000. Python's default recursion limit sits around 1,000 frames, so you get RUNTIME ERROR on all four performance tests beside a perfect correctness score. Rewrite it as a loop with an explicit stack.
Wrong answer from integer overflow. Row three above. A Java or C# int tops out at 2,147,483,647, so counting pairs in an array where most elements match overflows silently and returns a negative number. Correctness tests use small values and never touch it. Move the accumulator to long.
Memory. Anything sized N by N is ten billion cells at the top constraint. It allocates happily on a forty element test and fails on every large one.

Read the upper bound on N before you write a line, and turn it into a budget. Around 100,000 rules out O(N**2) and points at a single pass, one sort, or a hash map. Around 1,000 makes O(N**2) safe. The constraint is not decoration, it is the specification of the algorithm they want.

Where a copilot is the wrong tool for this

OfferPilot AI publishes this guide, so the limits belong inside it. Our Code Copilot reads a problem from a screenshot and returns a solution with the intuition, a dry run and the Big-O, and its overlay is excluded from screen capture at the operating-system level, so it stays out of Zoom, Teams, Meet, OBS and screenshots. That guarantee is narrow. It does nothing about a webcam, a lockdown browser, an invigilator in the room, eye tracking, or a phone camera beside your desk, and it is Windows 10 and 11 only, with no macOS, Linux, mobile or browser extension. A Codility session also records the edit stream behind its code playback, which is how a reviewer watches a solution get written.

More to the point, the gap this page describes is not an information gap. Nobody scores 0% on performance because they had never heard of a hash map. They score it because they read a constraint of 100,000 and typed a nested loop anyway. That reflex comes from working timed problems until the budget calculation happens before the first line, and no overlay installs it inside the ninety minutes you have.

The three traps behind most performance zeroes

Nearly every quadratic solution that scores zero is one of these three. The first is visible. The other two are not, which is why they survive a read-through.

Nested loops over the same input

Two loop headers walking the array, one inside the other. Solution A in its honest form, catchable by counting indentation levels before you submit. The fix is almost always one of three moves: a hash map for "have I seen this before", a prefix sum array for "what is the total of this range", or one sort followed by two pointers.

A linear search hiding inside a single loop

One visible loop, and inside it if x in seen where seen is a list, or arr.indexOf(x), or list.contains(x), or Array.prototype.includes. Each scans the whole collection, so one loop is quietly N * N. Same trap: list.pop(0), arr.shift() and max(A[i:]) are linear per call. Swap the list for a set or dictionary and membership drops to constant time.

String concatenation in a loop

Strings are immutable in Java, C#, Python and JavaScript, so result += c allocates a fresh string and copies everything built so far. Do that 100,000 times and you have copied roughly five billion characters to build one string, with no nested loop visible anywhere. Collect the pieces in a list and join once, or use a StringBuilder. CPython sometimes optimises the single-reference case, but that is an implementation detail, not a plan.

If you are staring at a report right now: check that the failing verdicts really are timeouts rather than runtime errors or wrong answers, work out which trap you wrote, then recompute your cost against the upper bound on N before touching the keyboard. A 60% you understand is a better position than it looks, because correctness is the half that takes judgement, and you already have it.

Why your Codility performance score is 0% when correctness is 100%