Capgemini · Software Engineer
Updated · 2026-10-02

Capgemini Software Engineer
Interview Guide

THE 60-SECOND BRIEF

As a Software Engineer at Capgemini, you will play a central role in driving enterprise-level digital transformations for global industry leaders across finance, healthcare, automotive, aerospace, and public sectors. Capgemini operates as a global leader in consulting, technology services, and digital transformation, meaning software engineering here goes far beyond isolated feature writing. You will be architecting, building, and deploying scalable applications that power critical business processes for Fortune 500 clients worldwide. The position offers an exceptionally diverse technological environment.

This guide is scoped to a Software Engineer candidate at Capgemini.

Capgemini candidates report 6 rounds over 4-6 weeks. The stages below are what candidates describe, not a published process.

JavaSpring BootReact

24 min read

Browse Software Engineer questions

See the practice prompts

5Candidate experiences ↗Read their reports
28Practice promptsAcross five skill areas

As a Software Engineer at Capgemini, you will play a central role in driving enterprise-level digital transformations for global industry leaders across finance, healthcare, automotive, aerospace, and public sectors. Capgemini operates as a global leader in consulting, technology services, and digital transformation, meaning software engineering here goes far beyond isolated feature writing. You will be architecting, building, and deploying scalable applications that power critical business processes for Fortune 500 clients worldwide. The position offers an exceptionally diverse technological environment. Depending on your team assignment and client engagement, you may work on modernizing legacy enterprise systems into microservices architectures, crafting dynamic frontends in React or Angular, optimizing backend systems in Java (Spring Boot) or.NET Core, or designing cloud-native solutions on AWS, Azure, or GCP. You will frequently collaborate with cross-functional, globally distributed teams comprising solution architects, project managers, quality engineers, and client stakeholders. What makes this role uniquely compelling is the balance of depth and breadth. You will tackle complex technical challenges—such as low-latency data streaming with Kafka, containerized deployments with Kubernetes and Docker, or high-throughput API integrations—while acquiring deep domain expertise across various client industries.

01

Automated Online Assessment

reported

Initial assessment testing analytical reasoning, pseudo-coding, data structures, and workplace personality scenarios.

What to demonstrate

  • Initial assessment testing analytical reasoning, pseudo-coding, data structures, and workplace personality scenarios
  • Depth in Java

How to prepare

  • Answer aloud and timed: Explain the internal working of HashMap and HashSet in Java, including how hash collisions are handled.
  • Answer aloud and timed: What is the difference between fail-fast and fail-safe iterators in Java?
Capgemini Software Engineer candidate reports ↗
02

Recruiter Phone Screening

reported

Direct conversation with a recruiter to evaluate candidate background and role fit.

What to demonstrate

  • Direct conversation with a recruiter to evaluate candidate background and role fit
  • Depth in Java

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Capgemini Software Engineer candidate reports ↗
03

Technical Round L1

reported

Focus on core language concepts, syntax, data structures, and practical coding tests.

What to demonstrate

  • Focus on core language concepts, syntax, data structures, and practical coding tests
  • Depth in Java

How to prepare

  • Answer aloud and timed: How do you create and handle custom exceptions in Java, and what is the difference between checked and unchecked exceptions?
  • Answer aloud and timed: Explain the internal security flow of JWT and OAuth2 in a microservices environment.
Capgemini Software Engineer candidate reports ↗
04

Technical Round L2

reported

Deep dive into microservices design, cloud patterns, project architecture, and scenario-based problem-solving.

What to demonstrate

  • Deep dive into microservices design, cloud patterns, project architecture, and scenario-based problem-solving
  • Depth in Java

How to prepare

  • Answer aloud and timed: How do Kafka topics, partitions, and consumer groups operate in event-driven backend architectures?
  • Answer aloud and timed: What are the key differences between useLayoutEffect and useEffect in React?
Capgemini Software Engineer candidate reports ↗
05

Managerial Assessment

reported

Evaluation of project fit, stakeholder communication, and domain adaptability in selected engagements.

What to demonstrate

  • Evaluation of project fit, stakeholder communication, and domain adaptability in selected engagements
  • Depth in Java

How to prepare

  • Answer aloud and timed: Explain how state management works with Redux Toolkit (RTK Query), and define concepts like staleTime and cache invalidation.
  • Answer aloud and timed: How do you implement error boundaries in React to prevent component tree crashes?
Capgemini Software Engineer candidate reports ↗
06

HR Round

reported

Discussion covering compensation expectations, location preference, and company culture.

What to demonstrate

  • Discussion covering compensation expectations, location preference, and company culture
  • Depth in Java

How to prepare

  • Prepare three examples from your own work, each with a decision you made and an outcome you can quantify.
  • Re-read the description of the hr round above and write down what you would ask to confirm before it.
Capgemini Software Engineer candidate reports ↗

5 candidate reports. Individual accounts describe a particular role and hiring cycle.

Software Engineer

Capgemini Software Engineer interview: selection without offer letter

Technical Screen → HR Screen → Onsite → OtherOutcome: offer

I cleared technical rounds and then had an HR conversation about salary expectations. One stage was face to face, L1 and L2 were held on the same day, and HR confirmed that I had been selected. I was told to expect an offer letter within a few working days. More than a month passed without an offer letter. I called and messaged, but neither recruiting nor HR responded. The interviews themselves h…

Read full experience
Software Engineer

Capgemini Software Engineer interview: business cases, Excel, and VBA

HR Screen → Technical Screen → Other

The process was concise: a recruiter phone screen, a technical conversation about a Java or React project, and a behavioral final round. Each stage lasted about half an hour, so it felt designed for quick decisions. The technical part relied on business-case questions and knowledge outside typical coding. I discussed basic Excel and Power BI, Excel and VBA, and how I handled business problems thr…

Read full experience
Software Engineer

Capgemini Software Engineer interview: policy-based rejection

HR ScreenOutcome: rejected

My process included technical interviews, document verification, background verification, and a final HR discussion. Those verification steps made the journey longer and more formal than ordinary interview back-and-forth. After clearing each stage, I expected a positive decision, but my candidature was rejected under hiring-policy criteria. I felt I had cleared the work in front of me, while the…

Read full experience
Software Engineer

Capgemini Software Engineer interview: ServiceNow scenario troubleshooting

Technical Screen

This was technical from start to finish, but unlike a generic software-engineer screen. It began on Microsoft Teams and focused on a specific toolset and real scenarios rather than theory. My questions centered on ServiceNow ITSM, scripting, and troubleshooting. Because the prompts were scenario-based, I had to work out the expected behavior rather than recite definitions. Some were long and not…

Read full experience
Software Engineer

Capgemini Software Engineer interview: fast project-based technical round

HR Screen → Technical Screen

After a recruiter screen on basic requirements, notice period, and salary expectations, I had a short, fast technical interview. It covered core coding and problem-solving with some system-design concepts, and moved quickly enough that I had to keep my explanations crisp. I discussed a project, then answered design and implementation questions about challenges, technologies, and how the pieces wo…

Read full experience

PracHub editorial advice for the preparation topics above.

01

Prepare a clear, 2-minute summary of a major project from your resume

Be ready to explain the system architecture, tech stack, key technical challenges, and your exact personal contributions.

02

Master Your Core Fundamentals

Do not memorize answers from books without understanding execution mechanics. Be ready to explain how concepts like polymorphism, garbage collection, dependency injection, or virtual DOM actually operate under the hood.

03

Structure Behavioral Responses

Use the STAR method (Situation, Task, Action, Result) when answering behavioral or project-related questions to ensure concise, structured responses.

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

25 technical prompts0 include a worked solution

Describe a situation where you faced a major technical roadblock during a sprint. How did you resolve it?

medium
Behavioral, Project & Problem-Solving

Describe a situation where you faced a major technical roadblock during a sprint. How did you resolve it?

Approach
  1. Say what the runtime actually does before reasoning about the code.
  2. Name what is shared across threads and what owns each piece of state.
  3. Identify the window where an invariant is briefly untrue.
  4. Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
  • What happens if two callers reach this at the same time?
  • Where could this allocate more than you expect?

How do you approach problem-solving when given ambiguous or changing requirements from a client?

medium
Behavioral, Project & Problem-Solving

How do you approach problem-solving when given ambiguous or changing requirements from a client?

Approach
  1. Restate the input: its shape, its size, and what is guaranteed about it.
  2. Name the brute-force solution and its complexity before improving on it.
  3. Choose the data structure from the access pattern, not from familiarity.
  4. State the target complexity and say which constraint rules the naive version out.
Follow-up
  • How does this change if the input no longer fits in memory?
  • What is the worst case, and how likely is it on real data?

Track a rolling failure rate per destination for circuit decisions

easy
sliding windowring buffercircuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach
  1. Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
  2. Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
  3. State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
  4. Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.
Follow-up
  • The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
  • A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Built from the rounds and topics Capgemini candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the Capgemini loop
  • Write out the reported sequence: Automated Online Assessment, Recruiter Phone Screening, Technical Round L1, Technical Round L2, Managerial Assessment, HR Round.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 6 reported rounds, with the weakest marked.

02Work Java
  • Spend the session on Java, which Capgemini candidates report being tested on.
  • Write one worked example in Java and time yourself on it.

Deliverable: One timed worked example in Java.

03Work Spring Boot
  • Spend the session on Spring Boot, which Capgemini candidates report being tested on.
  • Write one worked example in Spring Boot and time yourself on it.

Deliverable: One timed worked example in Spring Boot.

04Work React
  • Spend the session on React, which Capgemini candidates report being tested on.
  • Write one worked example in React and time yourself on it.

Deliverable: One timed worked example in React.

05Answer out loud: Core Java, Spring Boot & Backend Engineering
  • Answer aloud, timed: Explain the internal working of HashMap and HashSet in Java, including how hash collisions are handled.
  • Answer aloud, timed: What is the difference between fail-fast and fail-safe iterators in Java?

Deliverable: Spoken answers to 2 reported Core Java, Spring Boot & Backend Engineering question(s), under time.

06Answer out loud: Frontend Engineering (React, Angular & JavaScript)
  • Answer aloud, timed: What are the key differences between `useLayoutEffect` and `useEffect` in React?
  • Answer aloud, timed: Explain how state management works with Redux Toolkit (RTK Query), and define concepts like `staleTime` and cache invalidation.

Deliverable: Spoken answers to 2 reported Frontend Engineering (React, Angular & JavaScript) question(s), under time.

07Answer out loud: .NET Core, C# & Enterprise Frameworks
  • Answer aloud, timed: What is the difference between `IEnumerable` and `IQueryable` in Entity Framework / LINQ, and how does execution deferral work?
  • Answer aloud, timed: Explain the difference between `SingleOrDefault` and `FirstOrDefault` in C#.

Deliverable: Spoken answers to 2 reported .NET Core, C# & Enterprise Frameworks question(s), under time.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural rounds judge the decision you made and what it cost.

Give an example of how you demonstrated teamwork and alignment with client objectives under a tight delivery d

medium
Behavioral, Project & Problem-Solving

Give an example of how you demonstrated teamwork and alignment with client objectives under a tight delivery deadline.

Approach
  1. Pick a story where you made the decision, not one where you watched it.
  2. State the situation in two sentences and spend the rest on the reasoning.
  3. Give the blast radius: what could have broken, and what you measured.
  4. Name the disagreement and how you resolved it with evidence.
Follow-up
  • What would you do differently if you ran that again?
  • How did you know your change caused the improvement?

Estimate work you have never done and defend the range

hard
estimationbackfillsexpand-contract

You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

Approach
  1. Decompose into independently deployable steps before estimating anything: add the column nullable, write both shapes, backfill in batches, verify, move reads, stop writing the old shape, drop it. That is four deploys spread over days, and the calendar estimate is dominated by them rather than by the loop's runtime.
  2. Do the arithmetic aloud for the part that has arithmetic in it: batch size times number of batches times per-batch duration, at a write rate the primary can absorb alongside roughly 1.2k writes per second of production traffic. The loop is throttled by replication lag and lock waits, not by how fast it can issue statements.
  3. Price the schema step by its lock rather than its statement duration. In PostgreSQL an ALTER TABLE taking ACCESS EXCLUSIVE waits for every open transaction on that table while later queries queue behind it, so a millisecond change issued during a thirty-second analytics query stalls that table for thirty seconds. Adding a nullable column with a non-volatile default avoids a rewrite from version 11; a new index wants CREATE INDEX CONCURRENTLY, which cannot run inside a transaction block and leaves an invalid index behind if it fails.
  4. Express the answer as a range whose endpoints each trace to a stated assumption, then name the cheapest experiment that collapses it, which is almost always running one real batch against the real table and multiplying.
Follow-up
  • How do you verify the backfill genuinely finished, given rows written by production traffic while it ran?
  • Where does the backfill resume from after a worker is killed mid-batch, and what makes that resume point trustworthy?

Tell callers you do not own that their integration breaks

medium
deprecationcompatibilitystakeholders

A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

Approach
  1. Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
  2. Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
  3. Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
  4. Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
  • How would you detect a consumer that reads the field only during a monthly export?
  • One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
  • 01

    Give an example of how you demonstrated teamwork and alignment with client objectives under a tight delivery deadline.

  • 02

    You are asked to estimate a change you have never attempted: add a column to a 100-million-row table, populate it, move reads across, and drop the old shape. Give a range with the assumptions that generate it, including batch size, the signal your backfill throttles on, and wall-clock hours, and name the three unknowns that would move the number most. Then describe a real estimate you gave under comparable ignorance: how you expressed its uncertainty, what you committed to, and how wrong you turned out to be.

  • 03

    A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.

PracHub preparation framework ↗
How difficult are the technical interviews at Capgemini?

The difficulty is generally moderate and highly practical. Rather than extremely complex theoretical algorithmic puzzles, interviewers focus heavily on core framework concepts, solid OOP fundamentals, database querying, and practical scenario-based problem solving related to your past project experiences.

Capgemini Software Engineer candidate reports ↗
Is live coding required during the interview?

Yes, most technical interviews involve a brief practical coding portion. You may be asked to share your screen and write a solution to an algorithmic problem, construct a working API snippet, or build a simple frontend component in an online editor.

Capgemini Software Engineer candidate reports ↗
Does Capgemini offer flexible working arrangements?

Yes, Capgemini broadly supports hybrid and flexible work models. However, exact remote work or office attendance expectations depend on your specific client project, delivery center location, and security requirements.

Capgemini Software Engineer candidate reports ↗
How long does the hiring process take from start to finish?

The standard timeline ranges from 2 to 4 weeks. After clearing technical and managerial rounds, HR documentation verification and formal offer generation typically take an additional 5 to 10 business days.

Capgemini Software Engineer candidate reports ↗
What distinguishes candidates who receive offers at Capgemini?

Successful candidates combine solid technical stack execution with clear communication. Being able to articulate *why* you chose a specific technology or design pattern on your resume makes a lasting impression on technical managers.

Capgemini Software Engineer candidate reports ↗
What topics does Capgemini test in interviews?

Capgemini interviews most often cover SQL, Python, Java, Problem Solving, and Spring Boot. The exact emphasis depends on the specific role you apply for.

Capgemini Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.