Genpact Interview Questions (2026): Real, With Answers

Expect three kinds of questions mixed into one sitting rather than a clean coding-only round: a block of CS fundamentals (OOP, operating systems, DBMS, networking basics), a general aptitude and reasoning section, and a coding section that's usually one or two problems rather than ten. Some candidates also report a JavaScript-specific segment that asks you to predict what a snippet prints, not write new code.

The practical takeaway is that you can't cram DSA the night before and expect to clear this round. A weak answer on a basic OOP or normalization question in the MCQ section eliminates you just as fast as a failed coding problem does.

Treat the MCQ block as a speed check, not a depth check. Number series and pattern questions (find the next term, spot the odd one out, basic percentage or ratio word problems) are designed to be answered in under a minute each. If you're spending three minutes on a single MCQ, skip it and come back, because the coding question at the end usually carries more weight per point than any single MCQ does.

Practical prep here is genuinely just repetition: a week of daily aptitude sets from any standard quantitative reasoning bank gets most candidates to the speed this round expects.

Enough to answer at the level of "what problem does this service solve," not enough to configure it. If AWS shows up in the MCQ section, expect questions like the difference between S3 and EBS, what EC2 actually is, or what a load balancer does conceptually. You won't be asked to write IAM policy JSON from memory.

The safer move is to only claim depth on your resume for what you've actually deployed something with. Genpact interviewers ask AWS follow-ups specifically because a resume lists it, and a shallow answer to a self-listed skill reads worse than not listing it at all.

Multiple candidates report technical rounds in the 15 to 35 minute range, shorter than the hour-long loops common at larger product companies. That compresses everything: there's often time for one project deep-dive, a handful of CS fundamentals questions, and maybe one live coding problem, not all three explored in depth.

Answer in the first 20 seconds with the direct answer, then expand only if the interviewer asks a follow-up. Long, meandering answers eat the one slot you had to demonstrate a second skill.

The core of it is tracking a top index and bounds-checking push and pop against the array's capacity, since a plain array doesn't grow or shrink on its own the way a linked-list-backed stack would.

class ArrayStack:
  def __init__(self, capacity):
    self.data = [None] * capacity
    self.top = -1

  def push(self, value):
    if self.top + 1 >= len(self.data):
      raise OverflowError("stack full")
    self.top += 1
    self.data[self.top] = value

  def pop(self):
    if self.top == -1:
      raise IndexError("stack empty")
    value = self.data[self.top]
    self.top -= 1
    return value

Interviewers usually push on the edge cases here: what happens on pop from empty, what happens on push at capacity. Handle both explicitly instead of letting them crash silently.

Two-pointer swap is the expected answer: walk from both ends toward the middle, swapping characters as you go, until the pointers meet or cross.

def reverse_string(s):
  chars = list(s)
  left, right = 0, len(chars) - 1
  while left < right:
    chars[left], chars[right] = chars[right], chars[left]
    left += 1
    right -= 1
  return "".join(chars)

If the interviewer asks you to do it recursively instead, that's a fair follow-up: swap the first and last character, then recurse on the substring between them, with the base case being a string of length 0 or 1.

Insertion sort wins on small arrays and on data that's already mostly sorted, because its best case is O(n) when the input is nearly in order, while quicksort's overhead (partitioning, recursive calls) doesn't pay off until the array is large enough to need it. Many real sorting library implementations actually switch to insertion sort under a small size threshold for exactly this reason.

The answer the interviewer wants isn't "quicksort is always better because it's O(n log n) on average," it's recognizing that average-case complexity and real-world performance on a specific input aren't the same conversation.

Overloading is having multiple methods with the same name but different parameter lists in the same class, resolved at compile time based on the arguments you pass. Overriding is a subclass providing its own implementation of a method it inherited from a parent class, with the same signature, resolved at runtime based on the actual object type.

class Calculator {
  int add(int a, int b) { return a + b; }
  double add(double a, double b) { return a + b; } // overloading
}

class Animal {
  void speak() { System.out.println("..."); }
}
class Dog extends Animal {
  @Override
  void speak() { System.out.println("Woof"); } // overriding
}

The one-line version interviewers actually want: overloading is decided by the compiler looking at parameters, overriding is decided by the JVM looking at the object at runtime.

HTTPS is HTTP layered on top of TLS, which encrypts the traffic between client and server so a third party intercepting the connection sees ciphertext instead of readable request and response bodies. It also verifies the server's identity through a certificate, so a client has some assurance it's actually talking to the domain it thinks it is, not an impostor.

A fair follow-up: what's actually inside the TLS handshake. Broadly, the client and server agree on a cipher suite, the server proves its identity with a certificate signed by a trusted authority, and both sides derive a shared symmetric key used to encrypt the rest of the session, since asymmetric encryption is too slow to use for the whole conversation.

SQL is the standard language for querying and managing relational databases. Commands split into four broad categories: DDL (Data Definition Language, CREATE, ALTER, DROP, which change structure), DML (Data Manipulation Language, SELECT, INSERT, UPDATE, DELETE, which change or read data), DCL (Data Control Language, GRANT, REVOKE, which manage permissions), and TCL (Transaction Control Language, COMMIT, ROLLBACK, which manage transactions).

Interviewers asking "what is SQL, share some commands" are usually just checking that you can categorize commands correctly, not testing edge cases yet.

DELETE removes rows one at a time based on a WHERE clause, logs each row deletion, and can be rolled back. TRUNCATE removes all rows at once, is minimally logged, and is typically faster, but it resets identity columns and generally can't target specific rows. DROP removes the entire table structure along with its data, indexes, and constraints, not just the rows inside it.

DELETE FROM orders WHERE status = 'cancelled'; -- removes matching rows, logged
TRUNCATE TABLE orders;             -- removes all rows, resets identity
DROP TABLE orders;               -- removes the table itself

The distinction interviewers actually care about: DELETE is DML and transactional, TRUNCATE and DROP are DDL and typically auto-commit, which matters if you're relying on being able to roll a mistake back.

Not who talks the most. Evaluators are typically watching for whether you listen and build on what someone else said, whether you can state a position clearly in one or two sentences instead of rambling, and whether you stay composed when someone disagrees with you. In a group that size, the candidates who get remembered are usually the ones who made exactly one or two sharp points, not the ones who talked continuously.

Waiting too long for a perfect opening to speak. In a group of ten or more with a fixed time window, silence doesn't read as thoughtful, it reads as absent. The safer strategy is to make your first point early, even a modest one, to establish that you're participating, then use later turns for anything more subtle once you've read the room.

Candidates report interviewers giving dedicated, unhurried time to a resume project, especially anything involving machine learning or a full-stack build, more time than the CS fundamentals or coding sections get in a short interview. Prepare a 60-second summary of what the project does and why you built it, then a deeper explanation ready for the tech stack, the specific problems you hit, and one thing you'd do differently now.

The "what would you do differently" question comes up often enough that having a real, specific answer, not a vague "add more tests," is worth preparing in advance.

Waterfall is sequential, requirements, design, build, test, release, each phase finishing before the next starts, which works when requirements are genuinely stable and well understood upfront. Agile breaks work into short iterations with continuous feedback, which fits better when requirements are expected to change as you learn more, which is most software projects.

A concrete answer beats the definition alone: mention a real project where scope changed mid-build and how a sprint-based process let the team adjust without a full replan, or, if you've only worked in a waterfall shop, be honest about that and explain what you understand about why teams move away from it.

"Tell me about yourself" is open-ended and lets you choose the narrative. "Walk me through your resume" expects you to follow the actual chronology on the page in front of the interviewer, education, then each role or project in order, briefly explaining the "why" behind each transition, not just restating the bullet points they can already read.

Prepare both separately. A résumé-walkthrough answer that just re-reads your bullet points out loud wastes the interviewer's attention on information they already have in front of them.

A generic answer name-drops "growth" and "learning opportunities" without anything specific to Genpact. A credible one references something concrete, the specific business area you'd be working in, a client industry Genpact serves that you have real interest in, or the scale of process and technology work the company does across its client base, and connects it to something specific about your own background.

The fastest way to sound credible here is genuinely just reading the actual job description and company page for ten minutes before the call and referencing one specific detail from it.

Group your skills into two or three categories and give one concrete proof point per category instead of listing technologies. "I'm comfortable with backend APIs, I built and deployed a Node service handling authentication for a class project" is a stronger answer than reciting a list of languages and frameworks with no evidence attached.

This question is often a soft segue into whether you can communicate technical work to a non-technical evaluator, since HR interviewers frequently aren't from an engineering background themselves.

These sections lean on the parts of JavaScript that behave differently from what a Java or C++ background would predict: hoisting, closures capturing a loop variable by reference instead of value, type coercion in loose equality, and the order operations actually run in with promises versus synchronous code.

for (var i = 0; i < 3; i++) {
 setTimeout(() => console.log(i), 0);
}
// prints 3, 3, 3 with var, because var is function-scoped
// and all three callbacks share the same i by the time they run

for (let j = 0; j < 3; j++) {
 setTimeout(() => console.log(j), 0);
}
// prints 0, 1, 2 with let, because each iteration gets its own binding

If you've never written production JavaScript, spend an hour on exactly this list before the assessment: var versus let scoping, == versus ===, and how a Promise resolves relative to a synchronous console.log sitting right after it.

It usually means the constraints or the required output changed just enough that copy-pasting a memorized solution fails silently. A classic example: instead of "return the indices of two numbers that add to a target," the modified version asks for all unique pairs, or asks you to return the pairs sorted, or changes the array to allow duplicates and asks you to dedupe the result.

The fix isn't memorizing more variants, it's understanding why the original solution works so you can adapt the loop condition or the data structure when the spec shifts under you mid-test.

Push every opening bracket onto a stack. On a closing bracket, the top of the stack has to be its matching opener, or the string is invalid. At the end, the stack has to be empty, otherwise there were unmatched openers left over.

def is_valid(s):
  pairs = {')': '(', ']': '[', '}': '{'}
  stack = []
  for ch in s:
    if ch in "([{":
      stack.append(ch)
    elif ch in pairs:
      if not stack or stack.pop() != pairs[ch]:
        return False
  return not stack

The two mistakes candidates make most: forgetting to check the stack is non-empty before popping, and forgetting to check the stack is fully empty at the end (a string like "(()" passes every individual character check but still isn't valid).

A single pass to build a frequency count, then a second pass over the original array (not the count structure, which doesn't preserve order) to find the first element whose count is exactly one.

from collections import Counter

def first_unique(arr):
  counts = Counter(arr)
  for x in arr:
    if counts[x] == 1:
      return x
  return None

The reason for the two-pass approach over a dictionary alone: a hash map doesn't guarantee insertion order in every language you might be asked to use, so re-scanning the original array is what actually guarantees you return the first occurrence, not just any occurrence with count 1.

Dequeue every element from the queue and push it onto a stack, which naturally reverses the order because a stack is last-in-first-out. Then pop everything off the stack back into the queue, and the queue comes out reversed.

from collections import deque

def reverse_queue(q):
  stack = []
  while q:
    stack.append(q.popleft())
  while stack:
    q.append(stack.pop())
  return q

The question is really testing whether you understand that a stack's LIFO order is exactly the reversal you need, not testing whether you know the syntax for a deque.

Two-pointer swap from both ends is the standard O(n) time, O(1) space approach. The alternative, building a new reversed array and copying it back, is also O(n) time but uses O(n) extra space for no real benefit, so it's the wrong answer in an interview unless you can justify why in-place mutation isn't safe for your specific use case (shared references elsewhere in the program, for example).

def reverse_in_place(arr):
  left, right = 0, len(arr) - 1
  while left < right:
    arr[left], arr[right] = arr[right], arr[left]
    left += 1
    right -= 1

Naming the space complexity trade-off unprompted is usually what separates a pass from a borderline answer on this one.

Jumping straight to code without stating the edge cases out loud first, empty input, single-element input, all-duplicate input. On a round this short, an interviewer who sees you silently handle an edge case in your code without ever mentioning it out loud has no way to know you did it on purpose rather than by accident.

Say the edge case, then handle it. It costs ten seconds and it's usually the difference between a technical pass and a "solid code, but I'm not sure they understood why" writeup on the interviewer's scorecard.

Normalization is the process of organizing tables to reduce redundant data and avoid update, insert, and delete anomalies, done through a series of normal forms (1NF removes repeating groups, 2NF removes partial dependencies on a composite key, 3NF removes transitive dependencies).

It comes up because a lot of Genpact's technology roles sit adjacent to data-heavy business processes, finance, supply chain, claims data, where a poorly normalized schema causes real reporting bugs downstream. The interviewer isn't testing textbook recall, they're testing whether you'd notice a schema is storing the same customer address in five tables and flag it before it becomes a production data-integrity issue.

Atomicity means a transaction either fully completes or fully rolls back, no partial state left behind. Consistency means a transaction moves the database from one valid state to another, respecting every constraint. Isolation means concurrent transactions don't see each other's uncommitted intermediate state. Durability means once a transaction commits, it survives a crash.

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
-- if the second UPDATE fails, atomicity means the first one rolls back too,
-- so money never disappears from account 1 without appearing in account 2

The money-transfer example works because it makes atomicity concrete: nobody wants a system where a debit succeeds but the matching credit silently fails.

Abstraction is the concept: hiding implementation detail and exposing only what's necessary. An interface is one specific mechanism a language gives you to achieve that concept, a contract of method signatures with no implementation, that any implementing class has to fulfill.

The distinction that trips people up: abstraction can also be achieved through an abstract class, which can have some concrete methods alongside abstract ones, while a classic interface (pre-default-methods) has none. If your interviewer asks "what's the difference between an abstract class and an interface" as the actual follow-up, that's the answer they're steering toward.

When an exception is thrown, the runtime stops normal execution and walks back up the call stack looking for a matching catch block, a process called stack unwinding. Any finally block along that path still runs regardless of whether an exception was thrown or caught, which is why finally is the right place for cleanup code, closing a file handle or a database connection, that has to happen either way.

try {
  riskyOperation();
} catch (IOException e) {
  log(e);
} finally {
  connection.close(); // always runs, exception or not
}

The follow-up worth anticipating: what happens if the catch block itself throws. Stack unwinding continues from there, finally still runs, and the new exception propagates instead of the original one.

First-Come-First-Served is simple but can cause long wait times behind one slow process (the convoy effect). Shortest-Job-First minimizes average wait time but needs to know job length in advance, which is rarely true in a real system. Round-robin gives every process a fixed time slice and cycles through, good for interactive systems where responsiveness matters more than throughput. Priority scheduling runs the highest-priority job first but risks starving low-priority jobs unless it's paired with aging.

A concrete answer: round-robin is what most general-purpose operating systems actually use for interactive workloads, because a user typing at a terminal cares about responsiveness, not raw throughput.

Paging splits physical memory into fixed-size frames and a process's logical memory into same-sized pages, with a page table mapping one to the other. It solves the problem of external fragmentation you'd get if you tried to allocate memory to processes in contiguous variable-size chunks, since fixed-size pages can be scattered across physical memory and still be addressed correctly through the page table.

It also enables virtual memory: a process can reference more memory than physically exists, with pages swapped to disk and back as needed, which is why a process's logical address space can be larger than the machine's actual RAM.

A subquery excluding the maximum is the classic approach, though a window function handles ties more predictably.

SELECT MAX(salary) AS second_highest
FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

-- alternative using DENSE_RANK to handle ties correctly
SELECT salary FROM (
 SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS rnk
 FROM employees
) ranked
WHERE rnk = 2;

The subquery version silently breaks if two employees share the top salary and there's genuinely no third distinct value, worth mentioning if the interviewer pushes on edge cases.

Order descending by salary and limit the result set, with the exact syntax depending on the database engine.

-- MySQL / PostgreSQL
SELECT * FROM employees
ORDER BY salary DESC
LIMIT 10;

-- SQL Server
SELECT TOP 10 * FROM employees
ORDER BY salary DESC;

Knowing that LIMIT and TOP aren't interchangeable across engines is a small detail that signals you've actually worked across more than one database, worth mentioning if you have.

Flip the sort direction from descending to ascending and keep the same LIMIT.

SELECT * FROM employees
ORDER BY salary ASC
LIMIT 10;

The reason interviewers ask both the top-N and bottom-N version back to back isn't complexity, it's checking that you actually understand ORDER BY direction rather than having memorized one specific query pattern by rote.

Open with a clear stance, then immediately concede the strongest point on the other side before explaining why your position still holds despite it. "Remote work clearly helps with focused individual output, but a lot of the coordination cost that gets cut from commute time comes back as coordination overhead across time zones" is a stronger opening than a flat "office is better" or "remote is better," because it signals you can hold two ideas at once instead of arguing a slogan.

When someone interrupts or talks over you, the composed move is a short, calm redirect, "let me finish this point and then I'd like to hear your take," rather than raising your voice to be heard over them.

"Why does a chat feature need WebSockets instead of the regular HTTP requests the rest of your app probably uses?" A tutorial-only candidate usually answers with something vague like "it's faster." A candidate with real experience explains that HTTP is request-response, the server can't push a new message to a client without the client asking first, while a WebSocket keeps a persistent, bidirectional connection open so the server can push a message the instant it arrives.

const io = require("socket.io")(server);

io.on("connection", (socket) => {
 socket.on("message", (msg) => {
  io.to(msg.roomId).emit("message", msg); // pushed to all clients in the room instantly
 });
});

A good follow-up to have ready: what happens if a client's connection drops mid-chat, and how you'd handle reconnection without losing messages sent in the gap.

You should be able to explain what you actually used and why, not the entire AWS catalog. If you deployed on EC2, you should be able to explain what an instance is, roughly how you configured security groups, and why you picked EC2 over a managed option like Elastic Beanstalk or Lambda for that specific project.

The honest answer to a question past your depth is genuinely fine here: "I set that up following documentation and haven't gone deeper into the networking side yet" reads better than guessing and getting caught in a follow-up.

Cover the basics honestly rather than bluffing: the accounting equation (assets equal liabilities plus equity), the difference between a debit and a credit, and the purpose of the three core statements, income statement, balance sheet, and cash flow statement. You don't need to explain amortization schedules to pass this question at an entry level.

If the role genuinely requires finance domain knowledge and you don't have it, the more useful answer is naming what you do understand clearly and being upfront that deep GAAP or IFRS knowledge isn't your background yet, rather than overreaching into territory you can't defend under a follow-up.

Be specific about the boundary between what you built and what a library did for you. "I fine-tuned a pretrained classifier on a labeled dataset I put together and got it to 84 percent accuracy on a held-out test set" is honest and defensible. "I built an AI system that predicts X" without any of that detail invites a follow-up you probably can't answer.

Have one number ready (accuracy, F1, latency, whatever's relevant) and one honest limitation of the model ready too. Interviewers who work in ML-adjacent roles specifically probe for whether a candidate understands the model's failure modes, not just its headline metric.

Give a direction, not a rigid title-and-timeline plan. Interviewers asking this are usually checking two things: whether your stated goals are realistic given the role you're interviewing for, and whether there's a plausible path at this specific company for you to get there, not whether you can predict your career with false precision.

A reasonable structure: name the skill or domain depth you want to build in the next couple of years, connect it to something the role actually offers, and be honest that the exact title or team five years out is less certain than the direction.

These usually sound like "if we don't move forward with you today, what would you do next?" The interviewer is checking for resilience and whether you'd take feedback constructively rather than getting defensive. A steady answer names that you'd ask for specific feedback if offered, keep applying elsewhere, and revisit the gap the feedback pointed to.

Avoid over-rehearsed positivity here ("I'd just keep smiling and try again!"). A grounded, specific answer about what you'd actually concretely do reads as more mature than forced optimism.

Answer honestly rather than performing loyalty you don't feel yet. A fair answer: you'd be transparent with Genpact about the timeline and the other offer rather than going silent, and you'd make the decision based on the actual role, growth, and fit, not just whichever number is higher.

What interviewers are actually screening for is whether you'd ghost them if a better offer showed up mid-process. Communicating proactively, even about a competing offer, is the answer that reads well, silence is the one that doesn't.

Say what you do know, then admit the gap directly instead of guessing and hoping it lands. "I know Genpact works across finance, supply chain, and increasingly AI-driven operations for large enterprise clients, but I haven't dug into the specifics of this particular business unit yet" is a stronger answer than a confidently wrong guess.

Interviewers generally read an honest "I don't know, but here's what I do know" better than a vague, evasive non-answer that tries to dodge the fact that you didn't prepare enough.

Floyd's cycle detection (the "tortoise and hare"): two pointers move through the list, one advancing one node at a time, the other advancing two nodes at a time. If there's a cycle, the faster pointer eventually laps the slower one and they meet. If there's no cycle, the faster pointer hits the end of the list first.

def has_cycle(head):
  slow, fast = head, head
  while fast and fast.next:
    slow = slow.next
    fast = fast.next.next
    if slow == fast:
      return True
  return False

The follow-up worth having ready: why does this run in O(n) time and O(1) space, compared to the more obvious approach of storing every visited node in a hash set, which also works but costs O(n) space. Being able to name that trade-off unprompted is the actual signal here.

Say your approach out loud before you write a single line, including the brute-force idea even if you already know you'll improve on it. Genpact's technical rounds reportedly include exactly this format, sharing your screen and solving a problem in real time while explaining your reasoning as you go, which is a different skill than solving the same problem silently on a judge.

Narrate the trade-off you're making at each decision point (why a hash map instead of nested loops, why a stack instead of recursion) rather than narrating the syntax you're typing. Interviewers running this format are grading your reasoning process at least as much as whether the code compiles.

A deadlock is a set of processes each waiting on a resource held by another process in the same set, with none able to proceed. It requires all four of: mutual exclusion (a resource can only be held by one process at a time), hold and wait (a process holds one resource while waiting for another), no preemption (a resource can't be forcibly taken away), and circular wait (a cycle of processes each waiting on the next).

Process A holds Resource 1, waits for Resource 2
Process B holds Resource 2, waits for Resource 1
-> circular wait, neither can proceed

The reason interviewers ask for all four conditions specifically: breaking any single one of them prevents deadlock, which is the actual basis for real deadlock-avoidance strategies (a resource ordering protocol breaks circular wait, for instance, without needing to touch the other three conditions).

A self join joins a table to itself, treated as if it were two separate tables, useful when a row needs to be compared against other rows in the same table. It becomes necessary for salary problems when the requirement isn't a flat rank (like "top 10 overall") but a comparison within groups, for example "the second highest salary per department" rather than per table.

SELECT e1.department, e1.salary
FROM employees e1
WHERE 2 = (
 SELECT COUNT(DISTINCT e2.salary)
 FROM employees e2
 WHERE e2.department = e1.department AND e2.salary >= e1.salary
);

Most candidates can write the flat top-N query without hesitation. The per-group version is what actually separates someone who's written production reporting SQL from someone who memorized one interview pattern.

Genpact staffs a mix of client-facing delivery teams, some with fixed shifts tied to a client's time zone, some hybrid, some fully remote. This question is a genuine logistics check, not a trick, but a hedgy or evasive answer ("I'm flexible, whatever works") reads worse than a direct one, because the interviewer needs to know now whether to keep moving you forward for a role with constraints you can't actually meet.

Answer directly with your real constraints, and if there's a hard limit (can't do a specific shift, need to stay remote for a specific reason), say so early rather than after an offer, since mismatches here cause a meaningful share of early attrition on delivery teams.

Direct, with a real range rather than a dodge. Vague answers like "I'm flexible, whatever the company thinks is fair" weaken your negotiating position and also slow the process down, since recruiters generally need a workable number to move an offer forward. Research a realistic range for the specific role and location beforehand and state it plainly.

On notice period, give the actual number your current employer requires, and if you have any flexibility (unused leave you could apply, a negotiated early release), say so directly rather than making the recruiter ask a follow-up to get the real number.