Codility-style coding test practice

What the real test usually looks like

There is no single Codility test. Codility is a platform: each employer chooses the tasks, the languages allowed and the time limit for its test. The invitation from the employer is the best guide to yours.

What Codility describes. Codility says each task is scored automatically against fixed criteria (Codility). Its free lessons for programmers (Codility) show the task style: a short problem, a function to write, and stated input limits. Its BinaryGap lesson task, for example, asks for "an efficient algorithm" for inputs up to 2,147,483,647 (Codility), and one lesson is titled Time Complexity (Codility).

Commonly reported about Codility tests (from candidates and guides, not confirmed on a Codility page we could load):

• A few tasks under one timer for the whole test, often between 30 minutes and 2 hours.
• Hidden correctness tests: your code is checked against cases you do not see, beyond the example in the task.
• Performance on large inputs for algorithmic tasks: a correct but slow solution can lose points.
• The time you take within the limit is not part of the score.

What our mocks cover. Each full mock is three coding tasks in 90 minutes, from an easier task to a harder one. You write and run a solution in Python, JavaScript, Java or C++, and it is checked against hidden test cases, earning credit for each case it passes. A laptop is recommended. You can go back and change a solution until you submit.

What our mocks do differently. Real Codility tasks are commonly reported to be checked for correctness and, on many tasks, for performance on large inputs. Our hidden cases are small and check correctness and edge cases, so a slow solution is not timed out; each task's explanation says what complexity a large input would need. The 10 free questions are multiple choice on correctness, complexity, edge cases and speed, the thinking behind passing those checks.

Question types with worked examples

One worked example for each kind of question, with the trap most people fall into.

1. Which solution is correct. Task: return the number of distinct values in a list. Solution: len(set(A)). It is correct for every list, including an empty one, which gives 0. Trap: writing your own loop with a sorted list and forgetting the first or last item. When a built-in does the job, check it handles the edge cases, then use it.

2. Time complexity. A solution loops over A and, inside the loop, calls max(A[:i]). The slice and max each touch up to i items, so the total is about N squared divided by 2 steps, O(N squared). Keeping a running maximum instead makes it O(N). Trap: seeing one loop and calling it O(N). Look inside it for slices, sums, counts and searches.

3. Which input breaks it. Task: return the smallest positive integer that is not in A. A solution returns max(A) + 1. Try A = [1, 2, 3]: it returns 4, which is right. Try A = [1, 3]: it returns 4, but 2 is missing, so the answer is 2. Try A = [-3, -1]: it returns 0, but the answer is 1. Trap: stopping after one case that works. List the edge cases on purpose: gaps, all negative, empty if allowed, one item, all equal, and the largest values allowed.

4. Fast enough for N up to 100,000. As a rough rule, aim for O(N) or O(N log N) at that size. O(N squared) means about 10 billion steps, far beyond a typical time limit. Trap: testing with ten items, where every approach seems instant. Ask how the work grows as N grows.

5. Reading the limits. If values can be as large as 1,000,000,000 and N is 100,000, a sum can reach 100 trillion. Python's integers handle that, but in languages with fixed-size integers it would overflow. Trap: ignoring the value range. It tells you about overflow and about which tricks, such as a counting array, are possible.

How to prepare

1. Read your invitation first. Note the number of tasks, the total time and the languages allowed. Employers set these, so do not assume.
2. Use one language you know well. Know its lists, dictionaries, sets, sorting and string methods without looking them up.
3. Read the limits before you code. The input sizes and value ranges in a task tell you how fast the solution must be and which edge cases matter, as in Codility's own lesson tasks (Codility).
4. Get it correct, then make it fast. Write a simple correct version first. If it is O(N squared) and N can reach 100,000, look for a running total, a dictionary, a set or sorting to bring it down.
5. Test the edge cases yourself. The example in a task is only one case. Try empty input if allowed, one item, all equal values, negatives, the smallest and largest values, and the largest N.
6. Learn the common patterns. Prefix sums, sliding windows, counting with a dictionary, two pointers, sorting first and simple greedy choices cover a large share of short algorithm tasks. Codility's free lessons are a good place to see the style (Codility).
7. Write full solutions under time. Our full mocks have you write and run code against hidden cases; do the same with tasks of your own, so writing under time feels normal.
8. Practice at the real pace. Take full timed mocks so working through three tasks against one clock feels normal on the day.

How scoring usually works

Scoring is set up by each employer. Codility says each task is scored automatically against fixed criteria (Codility), and each employer decides what result is good enough. There is no universal pass mark.

Commonly reported about how those criteria work: a task's score comes from hidden correctness tests and, for many algorithmic tasks, performance tests on large inputs, combined into a percentage for the task and then for the test. A solution that is right on small inputs but too slow on large ones can lose its performance points, and one that fails an edge case loses part of its correctness score. This is why the questions in our mocks keep asking "Is it correct?" and "Is it fast enough?" separately.

Our practice score is the number of our own questions you answered correctly, with a breakdown by task, so you can see where to focus. It is a practice score: it is not a Codility score or any employer's result, and it does not predict whether you will pass.

Common mistakes

• Trusting the example. A task's example is one case among many hidden ones. A solution can pass it and still fail most of the score.
• Ignoring N. A correct O(N squared) solution can fail the performance checks at N = 100,000. Check the limits first.
• Hidden work inside a loop. A slice, sum, count, index or "in" on a list inside a loop multiplies the cost.
• Missing the last item. Off-by-one ranges and runs that end at the end of the list are a classic failure. Trace the last step by hand.
• Wrong starting values. Starting a maximum at 0, or a minimum at a made-up large number, breaks on negatives or very large values. Start from the first item.
• Changing the order the task depends on. Sorting is a great tool, but not when the answer depends on positions or "first in the list".
• Spending all the time on one task. Get a correct version of every task submitted, then improve speed where time allows.