What the Deloitte Codility Test Actually Looks Like
It is not a trick test. It is a standard algorithmic coding assessment delivered through Codility, and Deloitte uses it to filter technical candidates before moving them into interview rounds. You get 40 to 60 minutes depending on the role, and the problems range from easy to medium difficulty. The platform runs your code against hidden test cases and gives you a score plus a correctness percentage. That score is what recruiters look at first. I took several of these during the hiring process for a Big Four tech consulting role a few years back, and the experience was about as predictable as it gets. You land in a browser-based IDE, three problems are laid out in front of you, and the timer starts immediately. No discussion. No debugging assistance. You submit what you have when you run out of time, and the system scores it.
Common Deloitte Codility Test Questions Categories
The problems consistently fall into a small set of categories. Array manipulation with prefix sums or two-pointer techniques. String processing where you need to check palindromes, anagrams, or substring properties. Basic greedy or simulation problems where brute force will time out and you need to find the optimal pass. Occasional graph or tree traversal, though those are less frequent for entry-level and mid-level roles. Rarely do you see dynamic programming unless you are applying for a specialized quantitative or software engineering track. One thing that catches people off guard is the edge case density. Deloitte's test cases are not designed to be mean, but they do include empty arrays, single-element inputs, already-sorted inputs, and maximum-constraint values. If your solution assumes a reasonable-sized input without checking bounds, it will fail silently on one of those hidden cases and you will get a low score without knowing why.
How to Actually Prepare for It
Most people waste weeks studying random leetcode problems that never show up. A better approach is to focus on the specific patterns I just listed and build fluency with them. Practice implementing a two-pointer solution from scratch without looking at a reference. Practice writing a prefix sum array in under two minutes. Practice converting between string and integer representations efficiently in your language of choice. Deloitte specifically seems to favor problems where you need to read input and output in a specific format. Codility gives you a function signature you need to fill in. Your job is to make sure the function returns exactly what is requested, not to write a full program with input parsing. People who try to add scanner or input reading code inside the function body waste time and often introduce bugs. Just implement the function and let the platform handle the rest. When I was prepping, I spent about two weeks doing targeted practice on the Codility platform itself, not random problem sets. The platform shows you exactly how the test will feel, including the same interface, the same scoring feedback, and the same pressure. This cut my practice time significantly compared to doing problems on other platforms where the input and output styles differ.
Get the Full Details
The Hard Truths About the Scoring
Your score is a combination of correctness and performance. Getting the right answer but using an O(n squared) approach when an O(n) solution exists will cap your score. Deloitte sets performance thresholds that are tighter than most candidates expect. For a problem with n up to 100,000, any solution slower than O(n log n) will likely fail the performance tests even if it is logically correct. Another thing nobody warns you about: partial credit. You can pass some test cases and fail others, and the platform will give you a partial score based on how many cases you cracked. This means you should always submit something rather than leaving a problem blank. Even a brute force solution that handles small cases correctly can bump your overall score enough to matter. The test also runs each submission multiple times under different conditions. If your solution has non-deterministic behavior, like depending on hash map iteration order in a way that affects correctness, it might pass some runs and fail others. This happens more often than you would think with problems involving frequency counting or grouping.
A Specific Edge Case That Got Me
On one of my attempts, I was working on a problem that asked for the minimum number of operations to make two arrays equal by incrementing elements. I wrote a clean solution that calculated the difference between the arrays and summed it up. It passed all the sample cases. It failed on a hidden test case where one array had negative values and the other did not, and my logic assumed all inputs were non-negative. The workaround was simple once I saw it: I added an initial validation pass that checked whether both arrays contained only non-negative values and returned early if the constraints were violated. But the real lesson was that I should have treated the constraints section of the problem description as part of the logic, not just background information. I stopped making that mistake on subsequent attempts.
What to Do on Test Day
Read all three problems before starting. Pick the one you can solve fastest, not the one that looks most interesting. Time management is the actual skill being tested here more than raw algorithmic knowledge. If you spend twenty minutes on a hard problem and only partially solve it, you will score worse than someone who completely solves two easier problems in the same time. Write clean code. The reviewers, if there is a human component to the evaluation, can tell the difference between someone who understands the material and someone who pasted a solution from memory. Use descriptive variable names. Add comments only where the logic is non-obvious. Avoid hacky one-liners that trade readability for a few characters saved. Submit early and often. The platform does not penalize multiple submissions. Each attempt gives you feedback on which test cases passed and which failed. Use that feedback to iterate. I have seen candidates leave problems half-finished because they were saving their best attempt for last and ran out of time before submitting anything.
Where This Approach Falls Short
The Codility test is a blunt instrument. It tells you whether someone can solve isolated algorithmic problems under time pressure. It does not tell you whether they can write production code, work in a team, understand business requirements, or communicate technical decisions. Deloitte knows this, which is why the Codility score is only one gate in a longer process that includes case interviews, behavioral rounds, and sometimes a second technical interview. If you are applying for a non-technical role and the Codility test feels disproportionate, you are not wrong. The firm uses it as a standard filter across all technical-adjacent positions regardless of how much actual coding the role requires. There is no workaround for that except practicing the specific problem types and improving your speed with them. For most candidates, a focused two-to-three week prep period targeting the categories I mentioned above is sufficient to move past this stage. Beyond that, diminishing returns set in quickly. Studying harder problems or more obscure data structures will not improve your score because those topics rarely appear on the Deloitte assessment.
