Capgemini Interview Questions (2026): Online Test, Technical & HR

Tracing step by step: x starts at 5, prints 5, then x becomes 3, prints 3, then x becomes 1, prints 1, then x becomes -1 which fails the condition, loop exits. Output: 5, 3, 1 on separate lines.

This style of while-loop trace is the most common pseudocode question type. The trap is miscounting the iterations, especially when the decrement is not by 1. Always trace until you've confirmed the exit condition is actually reached, not assumed.

This is factorial. mystery(4) calls mystery(3), which calls mystery(2), which calls mystery(1), which calls mystery(0) returning 1. Unwinding: 1*1=1, 2*1=2, 3*2=6, 4*6=24. Return value: 24.

Recursion traces are the second most common type. The pattern is always: identify the base case, then manually unwind two or three levels. Capgemini pseudocode uses clean recursion without memoization in the online test. Know the call stack mechanics.

# The same logic in Python for clarity:
def mystery(n):
    if n == 0:
        return 1
    return n * mystery(n - 1)

print(mystery(4))  # Output: 24

Queue. The INSERT operation adds to the rear (enqueue), DELETE removes from the front (dequeue), and PEEK views the front element without removing it. This is FIFO behavior: First In, First Out.

If instead the operations were INSERT/DELETE/PEEK all operating on the same end (top), that would be a stack (LIFO). Capgemini often presents one of these as an MCQ with four data structure options: stack, queue, linked list, tree. The answer always comes down to which end each operation uses.

Visual reasoning and pattern recognition. You're shown a grid (4x4 or 5x5) with geometric shapes, and one cell is empty. Each shape appears exactly once per row and column, like a geometric Sudoku. Your task is to identify which shape belongs in the missing cell.

The skill being scored is deductive logical thinking: eliminating possibilities systematically by process of exclusion across both the row and the column. Candidates who try to guess visually rather than eliminate systematically run out of time on harder grids. Work rows and columns together, not one at a time.

You are given a set of available digits and asked to arrange them to form valid mathematical equations. The constraint is that you can only use each digit from the given set, within the specific positions shown. The skill tested is numerical reasoning and constraint satisfaction under time limits.

This game is less about arithmetic and more about combinatorial thinking: which digit combinations can satisfy the equation structure given the constraints? Eliminate clearly impossible combinations first to narrow the search space.

The correct answer is "on time." "On time" means according to schedule, exactly at the expected moment. "In time" means before a deadline but with some margin, not specifically at the scheduled moment. "By time" is not standard usage. "At time" is incorrect grammatically.

The distinction between "on time" and "in time" is a consistently tested distinction in Capgemini's English section. Other commonly tested preposition pairs: "at the end" vs "in the end," "agree to" vs "agree with," "different from" vs "different than."

Anxiety. Apprehension means uneasiness or worry about something that hasn't happened yet. The team wasn't excited, indifferent, or approving of the decision, they were uneasy about it.

Capgemini's synonym and antonym questions tend to draw from workplace and news-register vocabulary rather than obscure literary words, terms like apprehension, mandate, discrepancy, and conducive show up more often than GRE-tier vocabulary. A word list built from business English is a better use of prep time than a general vocabulary list.

A plain HashMap gives you frequency counts but not the original order, since HashMap iteration order isn't guaranteed. Use a LinkedHashMap instead: it preserves insertion order, so the first time you see a value, it gets inserted, and every later occurrence just increments the count in place.

import java.util.LinkedHashMap;
import java.util.Map;

public class FrequencyOrder {
    public static void printFrequency(int[] arr) {
        Map<Integer, Integer> counts = new LinkedHashMap<>();

        for (int num : arr) {
            counts.put(num, counts.getOrDefault(num, 0) + 1);
        }

        for (Map.Entry<Integer, Integer> entry : counts.entrySet()) {
            System.out.println(entry.getKey() + " -> " + entry.getValue());
        }
    }

    public static void main(String[] args) {
        printFrequency(new int[]{4, 2, 4, 5, 2, 2});
        // Output:
        // 4 -> 2
        // 2 -> 3
        // 5 -> 1
    }
}

This is a hashing problem more than an array problem once you see it. The trap for candidates who reach for a plain HashMap: the output prints in whatever bucket order the map happens to use, which fails the "first appearance" requirement even though the counts themselves are correct.

C is a procedural language. C++ adds object-oriented programming on top of C, including classes, inheritance, polymorphism, and the Standard Template Library. C does not support function overloading or operator overloading; C++ does. Memory management in C is purely manual (malloc and free); C++ adds constructors, destructors, and the option for RAII-style resource management.

This is the most common opening technical question Capgemini interviewers use for freshers who list C or C++ on their resume. It's calibration: a blank or vague answer signals the interview needs to slow down significantly. A clean two-sentence answer with concrete differences signals you know your fundamentals and the interviewer can move faster.

The Fibonacci series starts 0, 1, 1, 2, 3, 5, 8... Each term is the sum of the two before it. For n terms, you store the last two values and compute forward.

def fibonacci(n):
    a, b = 0, 1
    for _ in range(n):
        print(a, end=" ")
        a, b = b, a + b

fibonacci(8)
# Output: 0 1 1 2 3 5 8 13

Capgemini interviewers sometimes follow this with "can you do it recursively?" The recursive version is less efficient (exponential time), so be ready to note that the iterative approach above runs in O(n) time and O(1) space. The interviewer may specifically ask which is faster and why.

Three approaches: arithmetic swap using addition and subtraction, bitwise XOR swap, or Python's tuple swap. The arithmetic method is the most commonly expected answer in Capgemini interviews.

public class SwapWithoutTemp {
    public static void main(String[] args) {
        int a = 10, b = 20;

        // Arithmetic swap
        a = a + b;  // a = 30
        b = a - b;  // b = 10 (original a)
        a = a - b;  // a = 20 (original b)

        System.out.println("a = " + a + ", b = " + b);
        // Output: a = 20, b = 10
    }
}

Know the limitation: arithmetic swap can cause integer overflow for very large numbers. The XOR method avoids this. Mentioning the overflow edge case without being prompted signals engineering thinking over memorized answers.

A linked list is a linear data structure where each element (node) stores data and a reference (pointer) to the next node. Unlike arrays, nodes are not stored contiguously in memory.

• Arrays have fixed size set at declaration; linked lists grow and shrink dynamically at runtime.
• Array element access by index is O(1); linked list access requires traversal from the head, so worst case is O(n).
• Inserting or deleting at the beginning of a linked list is O(1); the same operation in an array requires shifting all subsequent elements, O(n).
• Arrays have no per-element memory overhead beyond the data; each linked list node carries an extra pointer field.

Capgemini's technical interviewers specifically like asking "when would you prefer a linked list over an array?" The honest answer: when you have frequent insertions and deletions at arbitrary positions and don't need random access by index.

Exception handling is the mechanism a language uses to deal with runtime errors, like dividing by zero or accessing a null reference, without crashing the entire program. Code that might fail goes inside a try block. If it throws an exception, control jumps to the matching catch block instead of terminating the program. A finally block, if present, runs regardless of whether an exception occurred, commonly used to close files or database connections.

public class DivisionExample {
    public static void main(String[] args) {
        int a = 10, b = 0;

        try {
            int result = a / b;
            System.out.println("Result: " + result);
        } catch (ArithmeticException e) {
            System.out.println("Cannot divide by zero: " + e.getMessage());
        } finally {
            System.out.println("Division attempt finished.");
        }
    }
}

Capgemini interviewers sometimes fold this into the Fibonacci or swap warm-up by asking "what happens if n is negative?" or "what if the input isn't a number?" The candidates who answer well aren't the ones who memorized try-catch syntax, they're the ones who instinctively think about what breaks the happy path.

Encapsulation: bundling data and the methods that operate on it into one unit (class), and restricting access to internal state. Example: a BankAccount class that exposes deposit() and withdraw() methods but keeps the balance variable private.

Abstraction: hiding implementation details and exposing only what the user needs. Example: you call car.start() without knowing how the combustion engine initiates the fuel-air cycle.

Inheritance: a child class inherits properties and behavior from a parent class. Example: a Dog class inherits from Animal and adds its own bark() method.

Polymorphism: the same method name behaves differently based on context. Example: a shape.area() method returns the right formula whether the shape is a Circle, Rectangle, or Triangle.

This question comes up in almost every Capgemini technical interview for freshers. Know all four, with one concrete example each, not just the definitions. The interviewer will probe whichever example you give.

No. Java supports eight primitive data types (int, byte, short, long, float, double, char, boolean) that are not objects. They don't inherit from Object, they can't call methods on them, and they're stored directly on the stack rather than as heap-allocated objects with a reference.

This is a Capgemini favorite. The full honest answer: Java is largely object-oriented, but the primitive types are a deliberate design compromise for performance. Wrapper classes (Integer, Double, Boolean, etc.) exist precisely to treat primitives as objects when needed, for example when storing them in a List or using generics.

Constraints are rules enforced by the database to maintain data integrity.

• NOT NULL: a column cannot hold null values.
• UNIQUE: all values in a column must be distinct.
• PRIMARY KEY: uniquely identifies each row; implicitly NOT NULL and UNIQUE.
• FOREIGN KEY: links a column in one table to the primary key of another, enforcing referential integrity.
• CHECK: values must satisfy a specified condition, for example age >= 18.
• DEFAULT: assigns a default value when no value is provided at insert time.

Capgemini interviewers typically ask this right after asking you to define DBMS. It's a clean follow-up, so prepare them as a pair. The PRIMARY KEY vs UNIQUE distinction is worth knowing precisely: a table can have multiple UNIQUE constraints but only one PRIMARY KEY.

DELETE removes specific rows and respects a WHERE clause. It is a DML operation, logged row by row, and can be rolled back within a transaction. TRUNCATE removes all rows from a table faster than DELETE (it deallocates data pages), cannot use WHERE, resets auto-increment counters, and is a DDL operation that cannot be rolled back in most databases. DROP removes the entire table structure along with all its data and indexes, permanently.

The one detail Capgemini interviewers specifically probe: TRUNCATE resets the identity/auto-increment column. If you insert after a TRUNCATE, the first row gets id = 1 again. DELETE does not do this. That distinction separates a prepared answer from a vague one.

INNER JOIN returns only rows with matching values in both tables. LEFT JOIN (or LEFT OUTER JOIN) returns every row from the left table, with NULLs filled in where there's no match on the right. RIGHT JOIN does the same from the right table's side. FULL OUTER JOIN returns all rows from both tables, matched where possible and NULL-filled where not. A CROSS JOIN returns the Cartesian product of both tables, every row from one paired with every row from the other, with no matching condition at all.

-- Employees who currently have no manager assigned
SELECT e.name, m.name AS manager_name
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id
WHERE m.id IS NULL;

Capgemini interviewers like the "employees with no manager" style example above because it forces you to explain why LEFT JOIN, and not INNER JOIN, is the right choice: INNER JOIN would silently drop exactly the rows you're trying to find.

Stack is LIFO: Last In, First Out. The most recently added item is the first removed. Operations are push (add) and pop (remove), both at the same end (top). Real-world example: a browser's back button. Each page you visit gets pushed onto a stack; hitting back pops the most recent one.

Queue is FIFO: First In, First Out. The first item added is the first removed. Operations are enqueue (add to rear) and dequeue (remove from front). Real-world example: a print job queue. The document you sent first gets printed first.

A compound question Capgemini sometimes asks: "how would you implement a queue using two stacks?" It's worth knowing the approach: push all elements onto stack 1; when you need to dequeue, transfer all elements to stack 2 (reversing order), then pop from stack 2.

O(log n). Binary search requires the input array to be sorted. It works by repeatedly dividing the search interval in half: compare the target with the middle element, then search only the left half or right half based on the comparison. Each step eliminates half the remaining candidates.

int binarySearch(int arr[], int n, int target) {
    int left = 0, right = n - 1;

    while (left <= right) {
        int mid = left + (right - left) / 2;  // avoids overflow vs (left+right)/2

        if (arr[mid] == target) return mid;
        else if (arr[mid] < target) left = mid + 1;
        else right = mid - 1;
    }

    return -1;  // not found
}

Note the mid calculation: left + (right - left) / 2 instead of (left + right) / 2. The naive version can overflow for large arrays in C/Java. Capgemini interviewers occasionally ask why you wrote it that way if you use the safer form. Having the reason ready signals you've actually thought about edge cases.

Don't say "my professor suggested it" or "it was the one I knew." Even if either is true, reframe it as a reasoned choice. Every technology has genuine advantages. If you used Python: easier to prototype data processing pipelines, extensive library support for the problem domain. If you used MySQL: ACID compliance and mature tooling for relational data. If you used React: component reusability and strong ecosystem.

The real answer the interviewer wants: you can justify a technical decision with trade-offs, not just "it's popular." A one-sentence why for each major technology you mention is enough. You don't need a 5-year roadmap, just evidence that you didn't use tools randomly.

Three things in 60-90 seconds: your academic background (one sentence), one project or technical achievement that ties to the role, and why you want to start your career at Capgemini specifically. The GeeksforGeeks on-campus experience report noted that Capgemini HR interviewers asked about "skills, hobbies, educational history, and ambitions" in a single introductory question. Keep the personal part brief and the professional part substantive.

The version that doesn't work: a linear recitation of your resume from 10th board results onward. HR has the resume. Tell them something the resume doesn't say as well, like the challenge you solved in the project or what you're excited to learn.

Capgemini operates in 50+ countries and had revenue of approximately 22.1 billion euros in 2024 (per Capgemini's official annual report). It's one of the few India IT companies running large-scale AI and cloud transformation engagements alongside traditional application maintenance. For freshers, that range of project types is a genuine advantage early in a career.

Avoid: "because Capgemini is a great company." That answers nothing. Pick one real thing: the Exceller program's dual-track structure (Analyst to Senior Analyst is a concrete progression), Capgemini's work in specific industries your degree aligns with, or a project the company has done publicly that genuinely interests you. One specific, connected reason lands better than three generic ones.

For strengths: name one, give a specific instance where it showed up. "I'm a quick learner" is generic; "I picked up SQL in two weeks to complete the database module of my final year project" is specific and verifiable.

For weaknesses: pick something developmental, not a disqualifying trait, and name the step you're already taking to address it. "I sometimes spend too long on code quality when shipping speed matters more. I've been timeboxing my review passes to 20 minutes before declaring something done, which has helped." The specificity makes it credible. The "I work too hard" cliche reads as evasion and most interviewers will push you for a real answer anyway.

Be honest. Capgemini serves global clients and offshore teams regularly work evenings or nights to overlap with European and US business hours. The Exceller program places candidates across India, and your posting location is assigned, not chosen.

If you can genuinely commit, say so clearly. If you have a constraint (a medical situation, a family dependency), state it calmly and explain the flexibility you do have. A calm "I can manage rotational shifts with reasonable advance notice" is more trusted than a blanket yes that you don't mean. HR wants accurate information, not a yes at any cost.

Capgemini requires freshers hired through the Exceller program to sign a 2-year service bond. Leaving before the bond period ends results in a financial penalty specified in the agreement. The HR round is where they confirm your acceptance of this term.

If you've accepted the offer, confirm clearly. PrepInsta's Exceller HR guide from 2025 notes the expected answer is a direct "Yes, I am ready to sign the 2-year bond." The HR round is not the place to negotiate bond length or push back on the terms. Questions about the bond terms are better raised with the recruiter before offer acceptance.

Name a direction, not just a title. "I want to be a manager" with no pathway doesn't land. "I want to build depth in cloud infrastructure over the next two years on client projects, then move toward leading a small technical workstream" is the kind of answer that reads as thoughtful.

Connect the path to what Capgemini actually offers. The Analyst-to-Senior-Analyst track is a real, defined progression within the Exceller program. Referencing it shows you've done basic homework on what the role actually looks like, which is more than most candidates at this stage do.

Always have one question. "No questions" reads as disengagement. Good options at the fresher HR stage: what does the onboarding process look like for Exceller candidates in the first 90 days, which technology domains are most active in the projects I might join, what does the learning and certification support look like at Capgemini India.

Avoid questions that could be answered by reading the Capgemini website for five minutes (company revenue, number of employees, what does Capgemini do). The question signals how much you've prepared and how curious you are, which is itself an assessment data point even in the final round.

Both tracks recruit through the same Exceller program. Analyst (approximately Rs. 4.0 LPA base plus Rs. 25,000 one-time incentive) is assigned to candidates who clear the online assessment and technical interview without the dedicated coding round. Senior Analyst (Rs. 7.5 LPA) goes to candidates who additionally pass the 45-minute coding round with two medium-difficulty problems. The coding round performance is the primary separator. You cannot choose your track at application; the process routes you based on scores.

No. No negative marking on any section of the Capgemini online assessment: pseudocode, English, game-based aptitude, and behavioral are all mark-only. Attempt every question. A blank is guaranteed to score zero; a guess on a 4-option MCQ has a 25% expected value. Given the 1-question-per-minute pace on the pseudocode section specifically, skipping an uncertain question and returning to it later (if the platform allows) is better than leaving it blank.

No. The game-based aptitude section is an elimination gate in Capgemini's 2025-2026 assessment. Failing to clear any one of the four sections (pseudocode, English, game-based, behavioral) exits you from the process regardless of your scores in the others. The games are not optional and there is no minimum score override from strong performance in other sections.

Minimum 60% aggregate in your qualifying degree (BE/BTech/MCA/MSc or equivalent). No active backlogs during the recruitment process. Full-time programs only; correspondence and part-time programs are not eligible. Most 2025-2026 drives target 2024 and 2025 graduation batches, with some including 2026 batch students. The exact batch cutoff varies by drive; check the specific job description on Superset or Capgemini's official career page for the drive you're applying to.

Typically 2-3 weeks from the online assessment date to offer letter, based on candidate reports from the 2025 cycle. The process can compress to 1 week for large campus drives where interviews happen in batches. Communication is maintained through Superset or email. The gap between technical interview and HR round clearance to final offer is where most of the waiting happens, not between the interview rounds themselves.

Sometimes, but it's not guaranteed for the Analyst track. The technical interview for Analyst candidates focuses primarily on OOP concepts, DBMS, data structure basics, and project discussion. A small coding question (Fibonacci, string reversal, swap without temp) may appear on paper or screen, but it is not a competitive coding problem of the kind in the Senior Analyst coding round. Senior Analyst candidates face more applied coding and debugging scenarios in the technical interview because they've already passed the dedicated coding round.

The function body is logically correct for swapping two values. The problem: it operates on local copies of a and b, not the originals. In a call-by-value language (like C), calling swap(x, y) will not change x or y in the calling scope. To actually swap variables through a function in C, you pass pointers: swap(&x, &y) and dereference inside the function.

Capgemini tests this category of "what's wrong" question to see if you understand scope and pass-by-value vs pass-by-reference. A correct-looking but semantically broken function is a common distractor.

Trace it index by index. i=0: arr[0]=5 and arr[1]=2, 5 is greater so swap, arr becomes [2, 5, 8, 1], i becomes 1. i=1: arr[1]=5 and arr[2]=8, 5 is not greater than 8, no swap, i becomes 2. i=2: arr[2]=8 and arr[3]=1, 8 is greater so swap, arr becomes [2, 5, 1, 8], i becomes 3. The loop condition i < 3 is now false, so it exits. Final array: [2, 5, 1, 8].

This is a single left-to-right comparison pass, the exact building block of bubble sort, but it only runs once. A common trap: candidates assume one pass fully sorts the array and answer [1, 2, 5, 8]. It doesn't. Read the loop bounds carefully before assuming full sort behavior.

You see a grid with a red ball, a hole (destination), movable plastic blocks, and immovable rocks. Your task is to move the red ball into the hole in the minimum number of steps. You can push plastic blocks but cannot move rocks.

What trips candidates up: they push a movable block into a position that blocks the only viable path to the hole, which requires backtracking. The game rewards spatial planning before moving. Spend the first 20-30 seconds of each level mapping the constraints before touching the controls. Speed alone doesn't win here; efficiency of path does.

Two things happen simultaneously: you verify whether two grids are mirror images of each other (symmetry check), and you memorize the coordinates of highlighted cells for a recall question that follows. The grid resets between questions, and the coordinate recall appears at the end of the grid sequence.

The specific challenge is attention splitting. Most candidates focus on the symmetry check and blank on the coordinate recall, or vice versa. The tested skill is multitasking under time pressure. Practice holding two streams of information in working memory simultaneously, not just one.

A set of geometric shapes passes through one or more "switches," each of which applies a hidden transformation, a rotation, a color change, or a repositioning rule. You're shown a small number of before-and-after examples for each switch, and your job is to infer the rule each switch applies, then predict what a new shape looks like after running through the same sequence of switches.

The skill being scored is rule inference from limited examples, then forward application of that rule under time pressure. Candidates who try to hold the transformation rule in their head while also evaluating the next switch tend to lose accuracy. Write down what each switch does the moment you work it out, rather than re-deriving it every time a new shape passes through.

Walk through the string once, tracking the current character and a running count. When the next character differs from the current one, append the character and its count to the result, then reset the counter for the new character. Append the final group after the loop ends.

public class CompressString {
    public static String compress(String s) {
        StringBuilder result = new StringBuilder();
        int count = 1;

        for (int i = 1; i <= s.length(); i++) {
            if (i < s.length() && s.charAt(i) == s.charAt(i - 1)) {
                count++;
            } else {
                result.append(s.charAt(i - 1)).append(count);
                count = 1;
            }
        }
        return result.toString();
    }

    public static void main(String[] args) {
        System.out.println(compress("aabbbcc"));  // Output: a2b3c2
    }
}

Candidates from the September 2025 batch drives reported a version of this exact problem, per PrepInsta's coding question bank. The edge case interviewers ask about afterward: what if a character appears only once? The code above handles it correctly since count starts at 1 and gets appended even for single occurrences.

Overloading: same method name, different parameter types or counts, within the same class. Resolved at compile time. Example: print(int x) and print(String s) in the same class.

Overriding: a child class provides its own implementation of a method defined in the parent class. Same name, same parameter signature. Resolved at runtime through dynamic dispatch. Example: Animal has speak(), Dog overrides speak() to return "Bark".

The way Capgemini interviewers test this: they ask you to define both, then write a quick Java example of overriding on paper. Know the @Override annotation and why it matters (it tells the compiler you intend to override, so if the signatures don't match, you get a compile error rather than accidentally creating a new method).

An abstract class can have both concrete (implemented) methods and abstract (unimplemented) methods. It can have instance variables, constructors, and access modifiers on methods. A class can extend only one abstract class.

An interface (pre-Java 8) could only have abstract methods and public static final constants. From Java 8, interfaces can have default and static methods with bodies. A class can implement multiple interfaces.

The answer Capgemini interviewers actually want: use abstract class when you have shared state or behavior to inherit. Use interface to define a contract that unrelated classes can implement. Example: Comparable is an interface because both String and Integer need to be sortable, but they share no common ancestor that has comparison logic.

No. Java allows a class to extend only one parent class. The reason is the diamond problem: if class C inherited from both A and B, and both A and B defined a method with the same signature, the compiler would have no unambiguous way to decide which version C should use.

Java gets around this with interfaces. A class can implement any number of interfaces, and since Java 8, interfaces can include default methods with actual bodies, not just method signatures. If two interfaces a class implements both provide a default for the same method, Java forces the class to override it explicitly rather than guessing, which is exactly the ambiguity that made multiple class inheritance risky in the first place.

Capgemini interviewers who've already asked about abstract classes versus interfaces often follow this up specifically, because it checks whether you understand the design reasoning, not just the "Java doesn't support multiple inheritance" rule you memorized.

The cleanest approach for most SQL databases: use a subquery that finds the maximum salary among salaries that are less than the overall maximum.

-- Method 1: nested MAX subquery
SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- Method 2: LIMIT with DISTINCT (MySQL/PostgreSQL)
SELECT DISTINCT salary
FROM employees
ORDER BY salary DESC
LIMIT 1 OFFSET 1;

Know both. Method 1 works across most SQL databases. Method 2 uses LIMIT/OFFSET which is more readable but dialect-specific. Capgemini interviewers sometimes ask you to generalize: "what if I want the Nth highest salary?" The window function approach with DENSE_RANK() handles that cleanly, but the interviewer typically won't expect it at fresher level unless you bring it up.

Normalization is organizing database tables to reduce data redundancy and avoid anomalies (insert, update, delete). You split data into smaller, related tables and define clear dependencies.

• 1NF: each column holds atomic values, no repeating groups.
• 2NF: 1NF plus every non-key column depends on the entire primary key, not just part of it (eliminates partial dependencies).
• 3NF: 2NF plus no non-key column depends on another non-key column (eliminates transitive dependencies).

Why we do it: a table storing student name, course name, and course instructor in a single row has a problem when the instructor changes. You'd have to update every row for that course, and if you delete all students from a course, you lose the instructor information entirely. Normalization prevents these anomalies by separating concerns into purpose-built tables.

Atomicity: a transaction either completes fully or not at all, there's no partial state left behind. Consistency: a transaction takes the database from one valid state to another, without violating constraints. Isolation: concurrent transactions don't interfere with each other's intermediate state. Durability: once a transaction commits, the change survives even a crash immediately afterward.

The standard example: transferring money between two bank accounts. Debiting one account and crediting the other has to happen as a single atomic unit. If the debit succeeds but a power failure hits before the credit runs, atomicity is what guarantees the whole transaction rolls back instead of leaving money debited from nowhere.

Capgemini interviewers ask this right after normalization fairly often, since both questions are really testing the same underlying concern: data integrity, just at different layers of the database.

The Capgemini technical interviewer wants: what problem did you solve, what specific technologies you chose and why, what you personally built (not what the team built), and one challenge you ran into. The on-campus experience report from GeeksforGeeks noted interviewers valued "confidence and making a clear impact that you are genuinely interested in the job" over technical depth.

The risky pattern: candidates who say "we built a web application using React and Node" and then can't answer "what specifically did you contribute?" The interviewer will ask. Prepare a 90-second version that uses "I" instead of "we" for the parts you owned. If you owned the database design, say so. If you wrote the authentication flow, say so. Shared ownership without specifics reads as no ownership.

The naive approach, scanning left to right and deleting matches repeatedly, is slow and messy to get right because removing one match can create a new match right next to it (for example, "AABCD" removes the inner "AB" first, and the leftover characters may form another pair). A stack handles this cleanly: push characters onto the stack one at a time; before pushing, check whether the top of the stack plus the incoming character forms "AB" or "CD". If it does, pop instead of pushing, which removes both characters in one step. If it doesn't, push normally.

import java.util.Stack;

public class RemovePairs {
    public static int finalLength(String s) {
        Stack<Character> stack = new Stack<>();

        for (char c : s.toCharArray()) {
            if (!stack.isEmpty() &&
                ((stack.peek() == 'A' && c == 'B') ||
                 (stack.peek() == 'C' && c == 'D'))) {
                stack.pop();
            } else {
                stack.push(c);
            }
        }
        return stack.size();
    }

    public static void main(String[] args) {
        System.out.println(finalLength("AABCD"));  // Output: 1
    }
}

This is a greedy, stack-based removal, one of the "greedy approaches" topics named in Capgemini's own coding round description. The reasoning worth saying out loud in the interview: greedy works here because removing the earliest possible match never blocks a later removal, so there's no need to consider alternative orderings.

A deadlock happens when thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1. Neither ever releases what it's holding, so both threads sit blocked forever. In production you usually see this as a sudden pile-up of requests with high CPU idle time, not high CPU usage, which throws people off because they expect a hang to look like a busy loop.

To confirm it, take a thread dump with jstack (or kill -3 on the process) and look for the "Found one Java-level deadlock" block, which lists exactly which threads are waiting on which monitors. Programmatically, ThreadMXBean.findDeadlockedThreads() does the same check at runtime so you can log or alert on it instead of waiting for someone to notice the app is stuck.

Prevention comes down to a few habits: always acquire locks in the same global order across the codebase so you can never have the reverse-order scenario above, prefer ReentrantLock.tryLock(timeout) over synchronized so a thread can back off and retry instead of waiting indefinitely, and reach for higher-level concurrency classes (ConcurrentHashMap, BlockingQueue, ExecutorService) that don't ask you to hold multiple raw locks at once. Deadlocks aren't only a JVM problem either, two database transactions can deadlock on row locks taken in different orders, and the database will usually detect it and kill one transaction with a deadlock exception rather than hang forever.

An index only helps when the optimizer expects to touch a small slice of the table. Most relational databases build indexes as B-trees, so a lookup is O(log n) to find matching row pointers, but each match still needs a separate read back to the actual table row unless the index is covering. If a query matches a large percentage of rows, say more than roughly 15-20% depending on the engine, the optimizer will often ignore the index and do a full table scan anyway, because sequential I/O beats thousands of random-access row lookups. This is why indexing a low-cardinality column like a boolean "is_active" flag rarely helps and sometimes gets ignored entirely.

Indexes also aren't free on the write side. Every insert, update, or delete has to update every index on that table, so a table with six indexes pays that cost six times per write. On high-throughput write tables this can matter more than the read speedup, and it's a common mistake to index every column that shows up in a WHERE clause without checking the write pattern first.

Other traps: a composite index on (a, b, c) generally can't be used efficiently for a query that filters only on b or c without a, so column order has to match the actual query patterns. And wrapping an indexed column in a function, like WHERE YEAR(created_at) = 2026, usually stops the optimizer from using the index at all, because it can no longer do a simple range seek on the raw column values. The fix there is to rewrite the predicate as a range, WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01', so the index stays usable.

The cleanest way is to skip manual wait/notify entirely and use java.util.concurrent.BlockingQueue, since it already handles the synchronization, capacity blocking, and wakeup logic correctly. ArrayBlockingQueue is a good default when you want a fixed-size buffer: put() blocks when the queue is full, take() blocks when it's empty, and both are safe to call from any number of threads at once.

BlockingQueue<Task> queue = new ArrayBlockingQueue<>(100);

// producer threads
Runnable producer = () -> {
    while (true) {
        Task t = createTask();
        queue.put(t); // blocks if queue is full
    }
};

// consumer threads
Runnable consumer = () -> {
    while (true) {
        Task t = queue.take(); // blocks if queue is empty
        process(t);
    }
};

ExecutorService pool = Executors.newFixedThreadPool(8);
for (int i = 0; i < 4; i++) pool.submit(producer);
for (int i = 0; i < 4; i++) pool.submit(consumer);

The interview follow-up is usually "what if you had to write it yourself with wait/notify." There the gotcha is that notify() only wakes one waiting thread, so with multiple producers and consumers you almost always need notifyAll(), and the wait has to sit in a while loop re-checking the condition rather than an if, because a woken thread can find the condition false again if another thread grabbed the resource first (this is the classic spurious wakeup and lost wakeup problem). Getting that wrong is exactly why BlockingQueue exists, it already got these edge cases right so nobody has to re-derive them.

Run a depth-first search and track two sets of nodes: ones fully finished (all their descendants explored) and ones currently on the active recursion path. If DFS reaches a node that's already on the current path, that's a back edge, and it means there's a cycle. A node you've already fully finished and popped off the path isn't a problem, revisiting it just means the graph has multiple paths to it, which is fine for a DAG.

def has_cycle(graph):
    WHITE, GRAY, BLACK = 0, 1, 2
    color = {node: WHITE for node in graph}

    def dfs(node):
        color[node] = GRAY
        for neighbor in graph[node]:
            if color[neighbor] == GRAY:
                return True  # back edge, cycle found
            if color[neighbor] == WHITE and dfs(neighbor):
                return True
        color[node] = BLACK
        return False

    return any(dfs(n) for n in graph if color[n] == WHITE)

The alternative is Kahn's algorithm: repeatedly remove nodes with in-degree zero, decrementing their neighbors' in-degrees as you go. If you can remove every node this way, the graph is acyclic; if some nodes are left over with in-degree greater than zero, they're stuck in a cycle. This version is often preferred in practice because it also gives you a topological order for free and avoids deep recursion on very large graphs, which matters since a naive recursive DFS can blow the stack on a graph with a long chain of dependencies.

This isn't just an academic exercise. Build tools and package managers use exactly this to catch circular dependencies before they cause an infinite build loop, spreadsheet engines use it to catch a cell that indirectly references itself, and workflow engines use it to validate a DAG of tasks before scheduling any of them.