KPMG Interview Questions (2026): Real, With Answers

Candidate reports describe three timed sections: roughly 30 quantitative aptitude questions, 30 logical reasoning and verbal questions, and two coding problems rated medium difficulty, usually completed on a proctored platform in one sitting. There's no separate "DSA round" before this stage, so weak coding here can end the process before a human reviews your resume.

Treat the aptitude and verbal sections as a speed test, not a knowledge test. The math itself, percentages, ratios, time and work problems, is high school level. What actually eliminates candidates is running out of time on the reasoning section because they spent too long double checking arithmetic on the earlier questions.

Pattern printing questions test whether you can translate a visual shape into nested loop bounds without overthinking it. For an inverted pyramid of height n, row i (starting at 0) should print n minus i characters, so the outer loop runs n times and the inner loop runs n-i times.

def inverted_pyramid(n):
  for i in range(n):
    row = n - i
    print("*" * row)

inverted_pyramid(5)
# *****
# ****
#  ***
#  **
#   *

The "then sort" part of the question is usually a second, unrelated ask, sort the array of row lengths or a given input array. Don't overthink it by trying to generate the pyramid from a sorted structure. Answer the two parts separately and say so out loud, that's exactly what the interviewer wants to hear.

This shows up almost verbatim in candidate reports, sometimes framed as "remove vowels" or "remove duplicates from your own name." The clean approach uses a seen-set to track characters you've already emitted, which keeps the solution at O(n) time and avoids the O(n²) trap of checking the output string for membership on every character.

def dedupe(s):
  seen = set()
  result = []
  for ch in s:
    if ch not in seen:
      seen.add(ch)
      result.append(ch)
  return "".join(result)

dedupe("mississippi") # "misp"

Reported as one of the more basic array questions in the coding section, usually as a warm-up before the harder of the two problems. In-place reversal with a two-pointer swap is the expected answer, not creating a second array.

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
  return arr

The two-pointer merge is the entire answer here, and it's also literally the merge step of merge sort, worth pointing out if the interviewer follows up asking where else this pattern shows up.

def merge_sorted(a, b):
  i = j = 0
  result = []
  while i < len(a) and j < len(b):
    if a[i] <= b[j]:
      result.append(a[i]); i += 1
    else:
      result.append(b[j]); j += 1
  result.extend(a[i:])
  result.extend(b[j:])
  return result

Sort both strings and compare, O(n log n), works but isn't the strongest answer. Counting character frequencies with a fixed-size array or dictionary and comparing the two counts gets you O(n) and shows you know when sorting is the lazy solution rather than the right one.

from collections import Counter

def is_anagram(a, b):
  return Counter(a) == Counter(b)

A stack is the entire trick. Push every opening bracket, and when a closing bracket appears, check that it matches whatever's on top of the stack. If the stack is empty when a closing bracket shows up, or the types don't match, the string is unbalanced. A non-empty stack at the end also means unbalanced, some opening bracket never got closed.

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

Compile-time (static) polymorphism is resolved by the compiler before the program runs, method overloading is the standard example, where multiple methods share a name but differ in parameter list. Runtime (dynamic) polymorphism is resolved during execution based on the actual object type, method overriding through inheritance and virtual dispatch is the example.

class Shape {
  double area() { return 0; }
}
class Circle extends Shape {
  double radius;
  Circle(double r) { radius = r; }
  @Override
  double area() { return Math.PI * radius * radius; }
}

Shape s = new Circle(5);
s.area(); // resolved at runtime to Circle's area(), not Shape's

A process is an independent execution unit with its own memory space, file handles, and address space, isolated from other processes. A thread is a lighter-weight execution unit within a process, and threads in the same process share memory and resources with each other. That shared memory is exactly why threads are cheaper to create and switch between than processes, and also exactly why they need synchronization to avoid corrupting shared data.

Seven layers, physical (raw bits over a medium), data link (framing and MAC addressing, switches operate here), network (routing and IP addressing, routers operate here), transport (TCP or UDP, end-to-end reliability or lack of it), session (managing connections between applications), presentation (encryption, compression, format translation), and application (the protocols users actually interact with, HTTP, FTP, DNS).

The layer most candidates get wrong under pressure is placing TCP or encryption at the wrong level. TCP is transport, layer 4. Encryption like TLS is usually described as spanning presentation and session, though in practice it's implemented closer to the application layer in most real stacks, which is a fair nuance to raise if asked directly.

IPv4 uses a 32-bit address space, roughly 4.3 billion possible addresses, which the internet has effectively exhausted given the number of connected devices worldwide. IPv6 uses a 128-bit address space, which is large enough that address exhaustion isn't a realistic concern again. Beyond size, IPv6 also simplifies header processing, drops built-in fragmentation support at routers (it's handled at the source instead), and includes native support for auto-configuration that IPv4 needed DHCP to bolt on.

A regular constructor initializes a new object's fields, typically from arguments passed at creation time. A copy constructor initializes a new object as a duplicate of an existing object of the same type, copying its field values rather than accepting fresh ones. In Java this is conventionally hand-written since Java doesn't generate one automatically the way C++ does by default.

class Point {
  int x, y;
  Point(int x, int y) { this.x = x; this.y = y; }
  Point(Point other) { // copy constructor
    this.x = other.x;
    this.y = other.y;
  }
}

DELETE removes rows matching a WHERE clause (or all rows if you omit one), is logged row by row, can be rolled back within a transaction, and doesn't reset auto-increment counters. TRUNCATE removes every row in a table in one operation, is minimally logged, is typically not row-rollback-friendly the way DELETE is, and does reset identity columns. DROP removes the entire table structure itself, not just the rows, the table no longer exists afterward.

An INNER JOIN returns only rows where the join condition matches in both tables. A LEFT JOIN returns every row from the left table regardless of whether a match exists in the right table, filling in NULLs for the right table's columns when there's no match.

SELECT c.name, o.order_id
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id;
-- includes customers with zero orders, order_id is NULL for them
-- an INNER JOIN here would drop those customers entirely

A primary key uniquely identifies each row in its own table and can't contain NULLs, a table has exactly one, though it can be composite across multiple columns. A foreign key references a primary (or unique) key in another table to enforce referential integrity, and a table can have as many foreign keys as it has relationships to other tables.

Whether it's waterfall, agile sprints, or something hybrid, the answer that lands is specific: how requirements got translated into tickets, who wrote tests and when relative to the code, and how a bug found in production got traced back and fixed. A vague "we did agile" answer without a concrete example of a sprint ceremony or a specific bug triage doesn't hold up to a single follow-up question.

Interviewers can tell the difference between "I want a Big Four name on my resume" and an actual reason. A specific answer names something about audit work itself, exposure to a range of industries early in a career, the structured path to a CPA, working directly with financial statements rather than abstractions, and ties KPMG specifically to something you can point to, a service line, an industry group, a person you've spoken with.

Busy season is the subtext of this question, whoever asks it wants to know if you have a real system rather than a vague "I just work hard" answer. Naming a concrete prioritization method, urgency versus importance, which deliverables blocked someone else's work versus which didn't, and a specific instance where you had to renegotiate a deadline rather than silently miss one, is what makes this answer memorable instead of generic.

Assets equal liabilities plus equity, and every transaction has to keep that equation balanced. A cash sale increases the asset cash and increases equity (through revenue, which eventually flows into retained earnings), the two sides move together and the equation stays balanced. This is genuinely entry-level content for the role, but candidates from non-accounting backgrounds trip on it under interview pressure specifically because it feels too basic to have prepared.

The trap is treating this as an invitation to recite your resume chronologically. A tighter answer picks a through-line, the specific type of problem you're drawn to, one or two concrete accomplishments that support it, and lands on why that trajectory points at this specific role. Thirty to sixty seconds, not three minutes.

A generic "great culture, great people" answer is instantly forgettable to an interviewer who's heard it a hundred times this recruiting season. Naming something specific, a service line, an industry vertical KPMG serves that matches your background, a person you've spoken with, or a piece of KPMG's actual work you found genuinely interesting, is the difference between a memorized line and an answer that sounds like you did the homework.

Interviewers aren't expecting a rigid five-year plan, they're checking whether your stated ambitions are plausible given the role and whether you have any awareness of the career path KPMG actually offers. Naming a realistic next step or two, associate to senior associate, or growth into a specialization you're already showing interest in, beats an overly specific answer ("partner by year five") that can come across as naive about how the actual path works.

Passing on this is the single most avoidable mistake candidates make in a final round. A question that shows you've thought about the specific team or engagement, not a generic "what's the culture like," signals genuine interest. Asking the interviewer something about their own path at KPMG also tends to land well, since most interviewers enjoy talking about their own trajectory more than reciting a rehearsed pitch about the firm.

This one comes up specifically in GeeksforGeeks-documented KPMG experience reports, and it's a genuine step up from the string basics above. Brute force checks every substring for palindrome-ness, O(n³). The expand-around-center approach is the practical answer in a 45 minute round: for each index, treat it as a potential palindrome center and expand outward while both ends match, doing this once for odd-length centers and once for even-length centers.

def longest_palindrome(s):
  def expand(l, r):
    while l >= 0 and r < len(s) and s[l] == s[r]:
      l -= 1
      r += 1
    return s[l+1:r]

  best = ""
  for i in range(len(s)):
    odd = expand(i, i)
    even = expand(i, i+1)
    best = max(best, odd, even, key=len)
  return best

longest_palindrome("babad") # "bab" or "aba"

That gets you to O(n²) time with O(1) extra space, which is enough for the input sizes these OAs use. Mentioning Manacher's algorithm as the O(n) upper bound if pushed shows depth, but don't lead with it, it's overkill for what's being tested here.

Floyd's cycle detection, two pointers moving at different speeds, is the answer an interviewer wants, and it's also the answer that demonstrates you understand why it works, not just that it does. A slow pointer moves one node at a time, a fast pointer moves two. If there's no cycle, the fast pointer reaches the end. If there is a cycle, the fast pointer eventually laps the slow one and they occupy the same node.

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

Worth mentioning unprompted: this runs in O(n) time and O(1) extra space, versus the hash-set approach that also solves it correctly but costs O(n) space. That trade-off comparison is usually what separates a pass from a borderline result on this question.

Array rotation is one of the recurring topics candidates report from KPMG's DSA questions. The naive approach rotates one step at a time k times, which is O(n*k). The reversal trick gets it to O(n) total: reverse the whole array, then reverse the first k elements, then reverse the remaining n-k elements.

def rotate(arr, k):
  n = len(arr)
  k = k % n
  arr.reverse()
  arr[:k] = reversed(arr[:k])
  arr[k:] = reversed(arr[k:])
  return arr

rotate([1,2,3,4,5,6,7], 3) # [5,6,7,1,2,3,4]

Walking through why three reversals produce a correct rotation, not just that they do, is what turns a memorized trick into a demonstrated understanding of the underlying index math.

A single pass to build a frequency count, then a second pass over the original string to find the first character whose count is exactly one, gets you an O(n) answer that also preserves the original order, which a plain dictionary iteration in older language versions wouldn't guarantee.

def first_unique(s):
  counts = {}
  for ch in s:
    counts[ch] = counts.get(ch, 0) + 1
  for ch in s:
    if counts[ch] == 1:
      return ch
  return None

first_unique("swiss") # "w"

Paging divides memory into fixed-size blocks (pages) that map to physical frames, which eliminates external fragmentation but can waste space through internal fragmentation when a process doesn't fully use its last page. Segmentation divides memory into variable-size logical units that match how a programmer actually thinks about a program, code, stack, heap, data, which avoids internal fragmentation but reintroduces the external fragmentation problem paging was built to solve.

Most modern operating systems use paging, or a hybrid of the two, because fixed-size blocks make the memory management unit's hardware translation simpler and faster than variable-size segment lookups.

A firewall filters traffic based on rules, allowing or blocking packets by source, destination, port, or protocol, it's a gatekeeper deciding what's allowed in and out of a network. A VPN encrypts traffic between two endpoints over an otherwise untrusted network, it's about confidentiality and integrity of the data in transit, not about filtering what's allowed through.

They solve different problems and are routinely used together: a VPN gets a remote employee's traffic securely onto the corporate network, and the firewall then decides what that traffic is actually allowed to reach once it arrives. Neither one substitutes for the other.

Multitasking is a single processor rapidly switching between multiple tasks, giving the appearance of simultaneous execution through time slicing, but only one instruction actually executes at any given instant. Multiprocessing uses two or more physical processors (or cores) so multiple instructions genuinely execute at the same instant, actual parallelism instead of the illusion of it.

The classic trap here is a naive subquery that breaks the moment there are duplicate top salaries. A DISTINCT-aware version handles ties correctly, and it's the version worth leading with even before being asked about edge cases.

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

An equally valid alternative uses DENSE_RANK() over a window if the interviewer wants the nth-highest generalized rather than hardcoded to second.

Atomicity means a transaction either fully completes or fully rolls back, no partial writes left behind. Consistency means a transaction moves the database from one valid state to another, respecting all constraints. Isolation means concurrent transactions don't interfere with each other's intermediate state. Durability means once a transaction commits, it survives a crash immediately afterward.

These matter most in exactly the scenario an interviewer is likely to probe: a funds transfer that debits one account and credits another. Without atomicity, a crash between the two operations leaves money vanished. Without isolation, a concurrent read could see the debit applied but not yet the credit.

This is reported as one of the most consistent questions across KPMG technical rounds, and it's graded less on the project's polish than on whether you can explain a trade-off you actually made and would make differently with hindsight. A weak answer describes what the system does. A strong answer names a specific decision, the database choice, a synchronous call that should've been async, a missing cache layer, and explains what it cost you.

Have one real trade-off ready before the interview, not a rehearsed "we used microservices" talking point. Interviewers in this loop specifically probe for whether you understand the downside of choices you made, not just the upside.

Synchronous processing blocks the caller until the operation completes and returns a result before moving on. Asynchronous processing lets the caller continue without waiting, and the result arrives later through a callback, promise, or message. The real-world choice usually comes down to whether the caller has useful work to do while waiting and whether the operation's latency is unpredictable enough that blocking would hurt user experience.

// synchronous-feeling, but actually async internally
async function getUserOrders(userId) {
 const user = await fetchUser(userId);    // waits
 const orders = await fetchOrders(user.id); // waits, but doesn't block other requests
 return orders;
}

A record synchronization question specifically, keeping two systems' data consistent when updates can happen on either side, is reported directly in KPMG interview experiences. The honest answer usually involves picking a source of truth, a reconciliation job or event stream to propagate changes, and a strategy for what happens when both sides change the same record before the sync runs.

In a candidate-led case, you drive the direction after the interviewer gives you the prompt, deciding what questions to ask, what framework to structure the problem around, and when to move from one line of analysis to the next. The interviewer answers your questions and nudges you if you're stuck, but doesn't hand you the next step. An interviewer-led case, by contrast, walks you through a fixed sequence of exhibits and questions regardless of what you'd choose to explore.

The practical implication: memorizing a rigid framework and reciting it top to bottom reads poorly here. What KPMG is testing is whether you can structure an ambiguous problem on the fly and adapt when the data doesn't fit your first hypothesis.

Market sizing questions test whether your assumptions are reasonable and your arithmetic is clean under time pressure, not whether you land on the "right" number, there isn't one. Start from population, estimate the share that owns or will own an EV, estimate charging sessions per vehicle per week, then convert that into stations needed given an assumed utilization rate and charge time per session.

State every assumption as you make it rather than burying it in mental math. "I'm assuming 400,000 people, 8 percent EV adoption in this timeframe, roughly 2 charging sessions per vehicle weekly" gives the interviewer something concrete to push back on, which is exactly the conversation this question is designed to start.

KPMG's consulting interviews weight behavioral content heavily, often 50 percent or more of total interview time even in a case-focused round, and this question specifically tests whether you can hold a position under pushback without becoming either combative or a pushover (My Consulting Offer, KPMG Advisory Interview Guide).

A strong answer names the specific disagreement, the evidence you brought to the conversation, and, honestly, what you'd have done differently if the stakeholder still hadn't come around. Interviewers notice when a "conflict resolution" story ends with an implausibly clean win every single time.

Consulting work is built on exactly this constraint, so the question is really checking whether you can state your confidence level honestly rather than presenting a guess as certainty. A good answer names the specific gap in the data, what assumption you made to bridge it, and how you flagged that assumption to whoever was relying on your recommendation.

This is one of the most consistently reported audit interview questions, and it's testing professional skepticism balanced against diplomacy, not conflict avoidance. A strong STAR answer names the specific disagreement, walks through how you validated your position with evidence rather than just restating it more firmly, and describes the actual resolution, including if the resolution was that you were the one who had it wrong.

This tests whether integrity holds up under time pressure, which is directly one of KPMG's five stated values. The expected answer escalates the finding to a senior or manager rather than deciding unilaterally to let it slide because the deadline is tight, and documents the finding regardless of how the deadline conversation goes afterward. A candidate who says they'd "just note it for next time" is describing exactly the failure mode this question is designed to catch.

The trap in this question is a story that's really just complaining about a colleague. A stronger answer focuses on what you actually did, a direct conversation, redistributing work with the team lead's awareness, documenting the gap, rather than dwelling on the other person's shortcomings. Interviewers are listening for ownership of the resolution, not a grievance.

This is a deliberately harder version of the standard "which value resonates with you" question, and picking the easy, safe answer, "Excellence, I always try my best," reads as rehearsed. Naming a value you've genuinely struggled with, Courage is a common honest answer for candidates who avoid conflict, and giving a specific instance where you fell short and what you changed afterward, is a stronger and more memorable response than a values essay with no real example attached.

Picking a failure that's secretly a humblebrag, "I worked too hard and burned out," is transparent and doesn't land. A real failure, named honestly, with a specific and concrete change you made afterward that you can point to in later work, is what this question is actually fishing for. The change matters more than the failure itself.

The instinct to defend yourself immediately is the wrong instinct here, and interviewers can tell when a candidate is performing agreeableness rather than actually engaging with the feedback. A better answer describes actually sitting with the feedback first, asking a clarifying question to understand the specific behavior being flagged rather than the general impression, and only then explaining your view if you still disagree after that. Ending with an example where feedback you initially resisted turned out to be right is a stronger close than a story where you were simply, conveniently, correct all along.

Full sort gets you there at O(n log n) and is a fine baseline answer. The stronger response is a min-heap of size k: push elements onto a heap, and once the heap exceeds size k, pop the smallest. What remains at the top of the heap after processing the whole array is the kth largest, in O(n log k) time.

import heapq

def kth_largest(nums, k):
  heap = []
  for n in nums:
    heapq.heappush(heap, n)
    if len(heap) > k:
      heapq.heappop(heap)
  return heap[0]

kth_largest([3,2,1,5,6,4], 2) # 5

A quickselect-based approach gets average O(n) if the interviewer pushes for something even faster, but it's a reasonable amount of extra complexity to bring up only if asked, not to lead with.

A deadlock is a state where two or more processes are each waiting on a resource held by another, and none can proceed. The four necessary conditions, all of which must be true simultaneously: mutual exclusion (a resource can only be held by one process at a time), hold and wait (a process holding one resource waits for another), no preemption (a resource can't be forcibly taken from a process), and circular wait (a cycle of processes each waiting on the next).

Break any one of those four and deadlock becomes impossible, which is the whole logic behind the Banker's Algorithm and most practical deadlock avoidance strategies, they attack one of the four conditions directly rather than trying to detect and recover after the fact.

First normal form requires atomic column values, no repeating groups or comma-separated lists inside a single field. Second normal form requires every non-key column to depend on the whole primary key, not just part of a composite key. Third normal form requires every non-key column to depend only on the key, not on another non-key column.

-- violates 3NF: department_head depends on department, not on the key (order_id)
CREATE TABLE orders (
  order_id INT PRIMARY KEY,
  department VARCHAR(50),
  department_head VARCHAR(50) -- transitive dependency
);

Fixing it means pulling department_head out into its own departments table and referencing it by foreign key, which also removes the update anomaly where changing a department head requires updating every order row that mentions that department.

Start with authentication and authorization as separate concerns, verifying who's calling versus what they're allowed to do, typically OAuth2 or a signed token scheme rather than rolling your own. Layer on transport encryption (TLS everywhere, no exceptions for internal traffic), input validation at the boundary to prevent injection, and rate limiting to blunt abuse.

The detail that separates a checklist answer from a demonstrated one: audit logging of who accessed what data and when, which in a professional services firm handling client financials isn't optional, it's often a compliance requirement independent of the technical security posture. Mentioning that connection, security as both an engineering concern and a client-trust obligation, lands well in this specific interview.

Stable revenue with falling profit points the investigation squarely at cost, so the first clarifying question is whether it's cost of goods sold, operating expenses, or something one-time like a write-off or legal settlement. From there, a profitability framework, revenue minus cost, broken into cost categories, gives a defensible structure without forcing a memorized template onto a problem it doesn't quite fit.

What actually separates candidates here isn't the framework choice, most reasonable ones work, it's whether you state your hypothesis out loud before diving into a category ("my hypothesis is this is a fixed-cost issue tied to underutilized capacity, let me check headcount and facility costs first") rather than fishing through categories one by one without a stated reason.

A defensible structure weighs speed, cost, and risk against each other rather than treating "buy versus build" as a single binary decision. Building preserves control and avoids integration risk but costs time you may not have if a competitor is moving faster. Acquiring is faster and can bring talent and existing customer relationships, but adds integration cost, cultural risk, and due diligence overhead that's easy to underestimate.

The strongest answers name a specific factor that would tip the decision one way, time-to-market pressure from a competitor's product launch, for instance, rather than listing pros and cons on both sides and stopping there without a recommendation.