Capgemini Exceller Debugging Assessment 2026: How to Solve It

The Capgemini Exceller debugging assessment hands you working-looking code that is quietly broken, and asks you to fix it. You do not write a program from scratch. You read someone else’s logic and find where it fails.

That single shift catches strong coders off guard, because authoring and debugging are different skills. This guide covers the four-step approach that keeps you calm under a tight timer, the bug types you will meet, and how to practise. For the full sequence of stages, start with the Capgemini Exceller framework guide.

What the Exceller debugging assessment is

Debugging is one stage in Capgemini’s Exceller process, described on the company’s technical graduates page as its route for hiring engineering freshers. The framework shared with candidates describes this round as focused and time-boxed:

Attribute	Detail
Questions	one
Time	about twenty minutes
Languages	C, C++, Java
Task	find and fix issues in given code

Confirm the exact timing with your placement cell, since Capgemini notes in its recruitment process guidance that steps vary by drive. Treat the one-question, tight-timer shape as the reliable part.

The four-step approach: review, identify, fix, validate

A structured pass beats poking at random lines. The framework itself points to four steps, and they map cleanly onto a repeatable method:

• Review: read the problem statement and the code fully before touching anything. Know what correct output looks like.
• Identify: locate the errors, and note whether each is logic, syntax, or runtime.
• Fix: make the smallest correct change. Avoid rewriting large blocks under time pressure.
• Validate: re-run the logic in your head against normal and edge cases before you submit.

The discipline that saves candidates is doing Review fully. Jumping straight to the code without reading the problem is how you fix the wrong thing.

The kinds of bugs you will see

Most bugs sit in three families, and naming the family speeds up the fix:

• Logic errors: the program compiles and runs but gives a wrong answer. Off-by-one loops, wrong comparison operators, and misplaced conditions live here. These are the hardest to spot.
• Syntax errors: the code will not compile. A missing semicolon, an unbalanced brace, or a wrong type declaration.
• Runtime errors: the code crashes while running. Array index out of bounds, division by zero, or null access.

Reading the code as logic, not as text, is the underlying skill. The same tracing habit trained by our Capgemini pseudocode MCQ practice transfers directly, since both reward following a program’s state step by step.

Debugging in C, C++, and Java

Pick the language you read fastest, not the one that looks most impressive. In a twenty-minute window, reading speed decides whether you finish. Common language-specific traps to watch:

• In C and C++: pointer misuse, uninitialised variables, and boundary access past an array.
• In Java: off-by-one in loops, wrong use of equality checks on objects, and unhandled exceptions.

Whichever you choose, validate against edge cases: empty input, a single element, and the largest boundary. Many broken snippets pass the obvious case and fail only at the edges.

Why debugging trips up strong coders

There is a reason confident programmers stumble here. When you write code, you follow your own mental model, so bugs tend to be shallow and familiar. When you debug, you inherit someone else’s model, and their mistake is hidden inside logic you did not design. Finding it means reconstructing what they intended, then spotting where the code drifts from that intent.

The tight timer adds pressure to that harder task. Twenty minutes is enough to read carefully once and fix precisely, but not enough to rewrite the whole thing from scratch. Candidates who panic and start retyping large blocks usually run out of time with a half-finished replacement. The ones who do well read slowly, change little, and test.

A quiet trap is fixing a symptom instead of the cause. If a loop prints the wrong total, the fault might be the loop bound, the starting value of the accumulator, or the condition inside. Changing the first thing you see can mask the real error or introduce a new one. Trace the value through the code before you edit, and you fix the cause once rather than chasing symptoms.

This is also why the Validate step is not optional. A fix that passes the obvious case can still fail on an empty input or the largest boundary. Spending your final two minutes on edge cases catches the errors that cost the most marks.

How to prepare

Train the specific muscle. Take correct programs, introduce a bug, and fix them under a timer, or use practice sets of broken snippets. Rotate through the common patterns: off-by-one loops, wrong conditions, uninitialised variables, and boundary errors. Keep a short mental checklist for the Validate step so you never submit without testing an edge case.

A useful weekly routine: fix five broken snippets a day for two weeks, rotating languages so C, C++, and Java all stay warm. Keep a running note of the bug you found in each, and you will start to see the same handful of patterns repeat. That pattern memory is what lets you spot an off-by-one or a wrong condition in seconds during the real round, instead of reading the whole program three times. Track your time per snippet too, and push to finish comfortably inside twenty minutes so the timer never rushes you on the day.

Since the same code-reading skill powers the Capgemini technical assessment, prep for the two together and you cover more ground per session. Start with logic-error drills if you tend to write fast and skim, because that is the bug family this round leans on most.