What Codility Actually Tests and How to Get Through It
Codility is a coding assessment platform used by companies to screen candidates before interviews. You'll get a timed test with algorithmic problems, and your score depends on correctness and efficiency. That's the short version. The reality is messier. I've taken enough of these to know that most people fail not because they can't code, but because they misread what the question is actually asking or they optimize for the wrong thing entirely. The platform doesn't care if your solution is elegant. It cares whether it passes all the hidden test cases within the time limit.
Codility Test Questions And Answers That Show Up Most Often
Before I break down strategy, let me talk about the questions themselves. The difficulty tiers go from Lesson (basics), Task (easy-medium), and Mission (medium-hard). The real screening tasks fall somewhere between medium and hard depending on the role. Common problem types include array manipulation, two-pointer techniques, sliding window, greedy algorithms, and basic dynamic programming. You'll see things like "count pairs with a given sum," "find the minimum number of jumps to reach the end of an array," or "merge overlapping intervals." These aren't random. They appear because they test specific thinking patterns efficiently. Here's a concrete example from my own experience. I was once given a task that looked like it required sorting an array and then scanning it linearly. The obvious approach is O(n log n). But the hidden test cases included arrays with thousands of duplicate elements, which caused a timeout on the brute force sort method. The workaround was to use a hash map to count frequencies first, then iterate through the counts. That dropped it to O(n) and passed every case. If you're stuck on a timeout, sorting is usually the wrong answer anyway.
How to Approach Any Codility Task
Read the problem statement twice. Not once. Twice. I've seen people write a solution before realizing the return type was wrong. The function signature is given to you — pay attention to it. If it says return an integer but your logic produces a list, that's an immediate zero score on correctness. Check the constraints. This is where most candidates lose points. If the input array can have up to 100,000 elements, an O(n²) solution will time out regardless of how correct it is. Look at the constraint numbers and immediately eliminate any approach that doesn't fit. A constraint of 10 means O(n log n) or better. A constraint of 10 means O(n). A constraint of 1000 means you probably have more room than you think. Write pseudocode before writing real code. This sounds trivial but it catches a lot of logical errors before they become debug nightmares. More importantly, it forces you to think through edge cases: empty input, single element, already sorted, reverse sorted, all identical values. Codility always tests at least one of these.
Get the Full Details
Time Complexity Is the Real Grading Factor
Codility uses a performance metric based on Big O complexity. Your solution gets graded on a scale from 0 to 100, and correctness alone only gets you partway there. A correct O(n²) solution on a large input will score lower than a correct O(n) solution on a small one. This is counter-intuitive for beginners who think getting the right answer is all that matters. The grading formula roughly weights correctness and performance equally. So a 100% correct solution with poor complexity might score around 60-70 overall. A solution with the same correctness but optimal complexity scores 100. Companies set their own thresholds, but anything below 60 is usually an automatic reject. Here's a nuance most people miss: Codility's test cases aren't just about worst-case input size. They also check for constant-factor efficiency. An O(n) solution written in a way with excessive memory allocations or unnecessary function calls can still time out. Use iterative approaches over recursive ones when possible. Avoid creating intermediate collections if you can compute the result in place.
Common Pitfalls and What to Do About Them
Integer overflow is the silent killer. In languages like Java and C++, a simple sum of two large integers can wrap around and produce a negative result. Codility includes test cases specifically designed to trigger this. Use long or BigInteger in Java, or just think through whether your intermediate values can exceed 2³¹-1 before you write the code. Off-by-one errors happen constantly in boundary conditions. When dealing with array indices, ask yourself explicitly whether the loop should include or exclude the final index. Write it down. Don't guess. I've lost points on tasks I could have solved perfectly because I wrote i < n instead of i
= n in a one-dimensional scan. Another issue I run into often: overcomplicating the solution. The easiest path is usually the right one. If you find yourself writing nested loops or multiple passes through the data, stop and reconsider. There's almost always a single-pass or two-pointer approach that achieves the same result more cleanly.
Practical Preparation Strategy
Start with the free lessons on Codility itself. They cover the foundational topics and give you immediate feedback on both correctness and performance. The personal tasks are harder and closer to real screening tests. Do at least five of them before your actual assessment. Practice on LeetCode with the filter set to easy and medium difficulty. Focus on the top interview questions list. The patterns overlap heavily. Two pointers, sliding window, and binary search alone cover maybe 40 percent of all Codility tasks. Don't spend time memorizing solutions. Spend time recognizing patterns. When you see a problem that asks for pairs or combinations in a sorted array, your brain should immediately fire "two pointers." When it asks for the maximum sum of a contiguous subarray, think Kadane's algorithm. Pattern recognition is faster under pressure than derivation.
When Codility Isn't the Right Tool
Be honest about what this platform measures. It measures your ability to solve algorithmic puzzles under time pressure in a generic language environment. It does not measure your ability to write maintainable production code, work in a team, understand business logic, or debug real systems. Some companies use it as a first filter, which is fine. Others over-rely on it, and that's a red flag. If you're applying to roles where the day-to-day work is more about infrastructure, DevOps, or product engineering than algorithmic problem solving, Codility scores will underrepresent your actual value. In those cases, a strong portfolio or GitHub presence matters more than a 95 on a coding test. Know your audience. One final note: practice with a timer. Set a 30-minute limit for each problem and stick to it. If you can't solve it in that window, review the solution, understand it, and move on. The goal isn't to solve everything perfectly. It's to build speed and pattern recognition under realistic conditions. That's what the actual test feels like, and being prepared for the pacing matters as much as knowing the algorithms.
