Codility for Tech Interviews in 2026: The Complete Guide for Candidates

Why Codility is still the European tech-hiring default in 2026

A Berlin Series B reached out to Jordan last fall about a remote role with US-EU coverage. The OA email said "Codility, 90 min, 3 tasks, link valid 7 days." He'd never heard of it. The first thing he did was google "is codility like leetcode" and find out the answer is "kind of, but the grader cares about time complexity, not just whether your code passes the visible tests."

Codility is the dominant coding-assessment platform across European tech hiring: the UK, Germany, Netherlands, the Nordics, and Poland where Codility was founded. American candidates encounter it less often than HackerRank or CodeSignal; European candidates encounter it more often than either. It scores on both correctness and time complexity, which means a brute-force solution that passes the test cases still loses points. That single design choice is why Codility's signal has held up where other platforms have drifted.

The Codility lesson architecture and what it signals about the test

Codility publishes 17 free lesson categories on its training site. The lessons are the most direct window any candidate has into how Codility thinks about algorithmic assessment. Every paid Codility Test draws its problems from the same pattern library the lessons teach.

The 17 categories in order:

1. Iterations
2. Time Complexity
3. Counting Elements
4. Prefix Sums
5. Sorting
6. Stacks and Queues
7. Leader
8. Maximum Slice
9. Prime and Composite Numbers
10. Sieve of Eratosthenes
11. Euclidean Algorithm
12. Fibonacci Numbers
13. Binary Search
14. Caterpillar Method
15. Greedy Algorithms
16. Dynamic Programming
17. Other (advanced)

A candidate looking at that list is looking at a complete map of the question library. Codility Tests almost never draw from outside this set. A test that includes a Leader problem is drawing from category 7. A test that includes a Caterpillar Method problem is drawing from category 14. The platform doesn't try to surprise the candidate with novel question types. It surprises the candidate with the difficulty knob within a known category.

This is different from how LeetCode-trained candidates often approach assessments. LeetCode is a brute index of thousands of problems with no enforced taxonomy; candidates train on individual problems and hope for pattern recognition to emerge. Codility hands the candidate the taxonomy up front and tests fluency inside it. The implication for prep is direct: a candidate who completes all 17 Codility Lessons with all-100 scores has seen every category the test will pull from. The variable is depth, not breadth.

The named problems in the public lesson set (FrogJmp for iterations, TapeEquilibrium for prefix-sums, MissingInteger for counting-elements, PermCheck for sorting and counting) are the templates. A real Codility Test problem is usually a reskinned version of one of these named problems with different variable names, different problem framing, or an added constraint that changes the optimal complexity.

A candidate who can name "this is a TapeEquilibrium variant: prefix sum across the array, look for the minimum absolute difference" inside the first thirty seconds of reading a problem has won most of the work. The rest is implementation.

What Codility tracks during an assessment

Codility's tracking is among the most thorough in the coding-assessment category, but it lives inside the browser tab. Understanding what gets logged and what doesn't is the difference between calibrating risk and worrying about phantoms.

What Codility logs:

• Every keystroke, with timestamps, in the code editor.
• Every paste event, with the size and source-type metadata of what was pasted.
• Tab focus changes: every time the candidate switches away from the Codility tab and every time they return, with how long they were gone.
• Time on each task, time on the test as a whole, time between code-execution attempts.
• Test-case execution history: which tests passed, which failed, in what order, how many times.
• For webcam-enabled tests: the live webcam feed for the duration of the assessment, sometimes with attention-tracking overlays.
• Submission diffs over time: Codility reconstructs the candidate's incremental progress and a reviewer can scrub through the assessment as a timeline.

What Codility scores on:

• Correctness. Does the code pass every test case the problem author wrote, including the visible examples and the hidden edge cases.
• Time complexity. Codility runs the candidate's solution against very large input arrays. A solution that passes all the small test cases but times out on the large ones earns fewer points. The grader explicitly verifies the asymptotic complexity matches what the problem expects.
• Code quality (on CodeCheck assignments): readability, structure, comments. Less weighted on Tests, more weighted on CodeCheck.

What the test does not see:

• Anything outside the browser tab. A second monitor, the desktop, the file system, other applications.
• Audio from the candidate's microphone (unless explicitly enabled by the hiring team).
• Camera reflections, room contents, the candidate's hands.
• A desktop application rendering above the browser.

The behavioral-signal model is layered on top of the raw logs. Codility flags candidates for reviewer attention when paste behavior is inconsistent with active development, when tab focus drops below a threshold, when typing cadence reads as "transcribing rather than writing." These flags are not auto-rejections. They surface as a note in the recruiter's view of the candidate's report, and the recruiter chooses how to weigh them against the score.

The pattern library: what shows up on real Codility tests

The patterns Codility tests reduce to a list. A candidate who has internalized the list reads the problem statement, identifies the pattern in the first read-through, and writes the solution in the second.

Iterations. Plain loops with off-by-one carefulness. FrogJmp asks: a frog starts at position X, wants to reach position Y, jumps a fixed distance D each time, how many jumps. Solution: (Y - X + D - 1) // D. The trap is candidates writing a loop instead of the arithmetic.

Prefix sums. Precompute a running total so that any range query becomes O(1). TapeEquilibrium asks the minimum absolute difference between two non-empty contiguous parts of an array. Solution: prefix sum left, prefix sum right (or total - left), iterate, track minimum. The trap is reaching for an O(n^2) double-loop.

Counting elements. Use a frequency dictionary or a fixed-size counter array. MissingInteger asks the smallest positive integer not in the array. Solution: drop everything outside [1, N+1], use a boolean array of size N+1, iterate, return first missing. The trap is sorting (O(n log n) when O(n) was expected).

Sorting and counting sort. When the value range is bounded, counting sort beats comparison sorts. PermCheck asks whether the array is a permutation of [1..N]. Solution: counting-sort approach, mark seen values, verify all 1 through N are present. The trap is using Python's set() (which still gives the right answer but loses style points on memory complexity).

Stacks and queues. Classical bracket-matching, river-fishing, stone-walls problems. The pattern is push when encountering one type of element, pop when encountering its match. The trap is candidates not recognizing the stack pattern and reaching for a string-replacement approach.

Sliding window and caterpillar method. Two pointers that move through the array, expanding and contracting based on a condition. CountDistinctSlices, AbsDistinct, and the harder problems in this category are caterpillar-method problems. The trap is the O(n^2) double-loop approach that times out on large inputs.

Binary search. When the answer space is sorted or monotonic, binary-search the answer. MinMaxDivision and NailingPlanks are the canonical examples. The trap is candidates not recognizing that the answer (not the input) is what gets binary-searched.

Greedy. Sort by some key, iterate, make the locally-optimal choice. MaxNonoverlappingSegments and TieRopes are the canonical examples. The trap is candidates trying to dynamic-program a problem that has a greedy solution.

Dynamic programming. When the problem has overlapping subproblems and optimal substructure. NumberSolitaire and MinAbsSum are the canonical examples. The trap is candidates trying to greedy a problem that needs DP.

Recognition speed is the differentiator. A candidate who needs ten minutes to identify the pattern has nine minutes left to solve a problem the test budgeted thirty minutes for. A candidate who identifies the pattern in ninety seconds has twenty-eight minutes to implement and verify.

How the screenshot trigger pairs with Codility tasks

The Codility task page has a consistent layout: problem statement on the left, code editor on the right, test cases below. The problem statement contains the spec, the examples, and (crucially) the expected time complexity. The expected complexity is the single biggest hint Codility gives the candidate, and it's the field most candidates skim past in the first read.

When the task page loads, press Ctrl+Shift+X on Windows or Cmd+Shift+X on Mac. The desktop client captures the visible region of the active screen: the full task page including the spec, examples, expected complexity, and any constraints. The capture runs through OCR on the rendered pixels, classifies the content as a Codility-style algorithmic problem, and streams a response in 2-to-4 seconds.

The response, for a typical Codility problem, includes:

• Pattern identification. "This is a prefix-sum problem." "This is a Caterpillar Method variant." "This is counting-sort over a bounded value range." Naming the pattern is the work that unlocks everything downstream.
• Target complexity match. The expected complexity from the problem spec, with confirmation that the proposed solution hits it. If the candidate's instinct is O(n^2) and the spec says O(n), the response flags the mismatch.
• A worked solution in the candidate's language. Python, Java, C++, JavaScript, Go, Kotlin, Swift, Rust. Codility supports 20-plus languages and the desktop client matches whatever language is selected in the editor.
• Edge cases the candidate is likely to miss. Empty arrays. Single-element arrays. All-equal elements. Negative numbers when the problem says "non-negative." The kind of test case Codility tests but doesn't show.
• A walk-through of the algorithm. Not just the code. A paragraph the candidate can paraphrase out loud if a reviewer asks them to explain their thinking. This matters more on CodeLive than on Tests.

The Screen Reference panel on the right side of the overlay shows the captured snippet so the candidate can verify what was analyzed. If the OCR misread a variable name or a constraint, the candidate sees it and can re-trigger with a tighter screen region.

The full round-trip (keystroke to streamed response) is 2 to 4 seconds on a healthy connection. The candidate reads the pattern identification first, confirms it matches their intuition, then implements. Speed of pattern recognition is the lever the screenshot trigger pulls.

Stealth mode during a Codility CodeLive session

Codility's three products serve different parts of the loop. Tests is the async timed assessment. CodeCheck is the take-home. CodeLive is the live-interview product: a video call plus a shared collaborative editor that the interviewer drives.

CodeLive is where the stealth-mode behavior matters most, because CodeLive is when an interviewer is watching the candidate's face and may be reviewing the candidate's screen-share.

The stealth model has one principle and a handful of consequences. The principle: the overlay window is excluded from OS-level screen capture using first-party APIs on Windows and macOS. The same APIs the OS uses for password manager popups and biometric prompts. Applications the OS has decided are sensitive enough that they should never end up in a screen recording.

What this means during a CodeLive session:

• The interviewer's video-conference share sees nothing. When the candidate shares their screen for CodeLive (or any other meeting platform), the share stream comes from the OS capture pipeline. The overlay is excluded from that pipeline. The candidate's monitor renders the overlay normally; the interviewer sees the editor underneath the overlay's position.
• Recording on the interviewer's end captures nothing. If the interviewer is recording the session (for hiring-team review, for compliance, for any reason) the recording uses the same OS capture API and respects the same exclusion.
• OS-level screenshots skip the window. Print Screen, Snipping Tool, macOS screenshot. None of them include the overlay in the output.
• No taskbar icon, no system-tray presence. The candidate doesn't have to manage a process tray. The overlay is invisible to casual desktop inspection.

The overlay-on-monitor vs in-recording distinction is the part candidates new to this category often miss. The pixels are on the monitor. The OS shows them to the eye attached to the user. But the OS does not show them to applications that ask for the screen-capture stream. The two paths are separate, and the stealth API rides the separation.

What stealth mode does not hide on a CodeLive session:

• Eye-line drift. If the candidate stares at a fixed off-screen point for three seconds before every answer, an attentive interviewer registers the pattern. Practice glancing briefly between speaking turns, not reading verbatim from the overlay.
• Audio. The overlay is text. If the candidate runs text-to-speech, the meeting microphone picks it up. Don't do that.
• Reflections. A laptop camera can reflect the screen in glasses or a glossy wall. Most interviewers don't catch this; a paranoid setup notices.
• A second device pointed at the screen. A phone, a camera, anything outside the OS capture pipeline records what it sees physically. Interview from a room with no recording devices pointed at the monitor.

Stealth covers the OS capture surface comprehensively. Everything outside that surface is on the candidate's discipline.

Setup tactics for Codility specifically

Codility rewards different prep than HackerRank or CodeSignal does. Three setup tactics translate directly into score lift.

Lessons-first prep. Spend the prep budget on Codility's own 17-lesson public training material before anything else. The Lessons are free, the problems are the same pattern library the Tests draw from, and the platform's grader teaches the candidate what "expected time complexity" feels like. A candidate who completes Lessons 1 through 17 with all-100 scores is at the floor for any Codility Test difficulty short of the highest senior-engineer band. LeetCode prep is useful supplemental but not substitute. Codility's grader has different priorities.

Read the expected-complexity field first. Every Codility task spec includes an "expected worst-case time complexity" line. It is the single most important piece of information on the page. A candidate who reads it second loses points to a candidate who reads it first, because the expected complexity dictates the algorithm. O(n) rules out comparison sorts, O(n log n) opens up sorting, O(log n) signals binary search, O(n^2) is permissive but expects something better than the trivial brute force. Pattern recognition is downstream of the complexity hint.

Time-budget the task list. Codility Tests typically run 60-to-120 minutes with one-to-three tasks. The naive approach is to spend equal time per task. The better approach is to skim all tasks first, identify which patterns are familiar and which aren't, and budget proportionally. A familiar pattern is 15-25 minutes of execution time. An unfamiliar pattern can eat the entire test if the candidate refuses to give up. Recognizing "I don't know this pattern, I'll come back to it" within the first three minutes of a task is a real skill, and it lifts the score meaningfully.

A practical sequence for a 90-minute, three-task test:

1. Minutes 0-5: Read all three task specs. Identify the pattern for each. Note the expected complexity for each.
2. Minutes 5-30: Solve the highest-confidence task first. Implement, run all visible tests, submit.
3. Minutes 30-60: Solve the second-highest-confidence task. Same pattern.
4. Minutes 60-85: Attempt the hardest task. If pattern recognition fails, write the brute-force solution that scores partial points. A 50% score on a hard task is better than a 0% score on a hard task.
5. Minutes 85-90: Review. Resubmit if a solution is timing out. Sometimes the expected-complexity threshold is borderline and a small optimization unlocks the full score.

The pacing is the variable score-band. A candidate who knows the patterns but spends 80 minutes on task one is leaving points on the table that a candidate with worse pattern knowledge but better pacing will pick up.

The performance-prediction angle

There is a research literature on whether Codility scores predict job performance. The honest summary: they correlate with junior-engineer productivity in algorithmic-heavy roles, they cap out fast in senior-engineer roles, and they do not predict the behavioral or systems-design dimensions of the job at all.

A Codility score that gets the candidate through the screen is doing the job it was hired to do: surface candidates who can write correct, efficient code under time pressure. What it cannot do is tell the company whether the candidate can debug an unfamiliar codebase, defend a design choice in a review, mentor a junior engineer, or sit in a sprint planning meeting and break a fuzzy requirement into work. Those skills come up after the screen, in CoderPad rounds, in system-design loops, in behavioral interviews, and (most decisively) in the first 30-to-90 days on the job.

This matters for one reason that should be said honestly. A candidate who passes a Codility Test they couldn't have passed on their own arrives at a team that expected an engineer with that algorithmic fluency. The mismatch surfaces. Most of the time it surfaces during the technical loop that follows (a CoderPad round, a take-home, a phone-screen with a hiring manager) and the offer doesn't materialize. Some of the time it survives the loop and shows up in the first sprint. Our companion guide on whether interviewers can detect AI during a Zoom interview walks through the detection rates at each stage. The companion guide on honest interview prep walks through the prep path that turns the toolkit into a force multiplier rather than a load-bearing crutch.

The Codility-specific implication: the algorithmic-pattern library Codility tests is genuinely useful knowledge for a working engineer. The patterns show up in real systems work. A candidate who uses the screenshot trigger as scaffolding while they internalize the patterns is building the muscle the assessment is supposed to measure. A candidate who uses the trigger as a permanent substitute is building a job-performance gap that catches up with them on a timeline measured in weeks, not months.

Honest founder note: the European hiring market Codility serves is also the market most likely to do a live walkthrough of any take-home you submit. Show up to a CodeLive round having pasted a CodeCheck solution you can't defend and the round is over in 4 minutes. The platform is knowable. The pattern library is finite. The 17 lessons are free. The toolkit covers the live test when memory recall fails under pressure. Walking out of the assessment with the patterns internalized is the bet that compounds. On this job, on the next one, on the design review three years from now where the system runs better because the engineer remembered to use a prefix sum instead of a double loop.

The job after the offer is the thing to weigh.

About the author: Alex Chen is the founder of InterviewChamp.AI, building AI interview prep for the new-grad CS market and writing about the modern interview gauntlet from the inside.