IBM Interview Questions (2026): Most Asked, With Answers

Most professional-hire loops run three to five stages. A recruiter screen first, fifteen to thirty minutes, mostly logistics and a light background check on fit. Then one or two technical rounds, which for engineering roles usually means a coding or design conversation with an engineer or two from the team, and for consulting roles means a case-style conversation with a senior consultant or manager. A behavioral round with the hiring manager typically follows, sometimes combined with the technical round rather than separate. Some business units add a final "meet the team" or panel conversation before an offer goes out, which is less an evaluation and more a two-way check that both sides still want this.

The recruiter is confirming three things: that your background roughly matches the requisition, that your compensation expectations aren't wildly out of range for the level and location, and that you understand which part of IBM you're actually interviewing for. That last point matters more at IBM than most companies, because "IBM" covers Software, Consulting, Infrastructure, and Research, and each has different pay bands, different travel expectations, and different day-to-day work. A recruiter who senses you think you're interviewing for a research scientist role when the requisition is actually a delivery-focused consulting role will flag that mismatch before it wastes a technical interviewer's time.

An iterative solution walks the list once, reversing each node's next pointer as it goes, using three tracking pointers, previous, current, and next, so you don't lose the rest of the list when you flip a pointer.

class ListNode {
  int val;
  ListNode next;
  ListNode(int val) { this.val = val; }
}

ListNode reverse(ListNode head) {
  ListNode prev = null;
  ListNode curr = head;
  while (curr != null) {
    ListNode next = curr.next;
    curr.next = prev;
    prev = curr;
    curr = next;
  }
  return prev;
}

O(n) time, one pass, O(1) extra space since you're only reassigning pointers on the existing nodes rather than allocating a new list.

A brute-force nested loop checks every pair, O(n squared) time. The better answer uses a hash map: walk the array once, and for each number check whether the target minus that number already exists in the map before adding the current number in.

int[] twoSum(int[] nums, int target) {
  Map<Integer, Integer> seen = new HashMap<>();
  for (int i = 0; i < nums.length; i++) {
    int complement = target - nums[i];
    if (seen.containsKey(complement)) {
      return new int[]{seen.get(complement), i};
    }
    seen.put(nums[i], i);
  }
  return new int[]{-1, -1};
}

O(n) time, O(n) space, checking the complement before inserting the current value handles duplicates correctly without an extra pass.

Reliability and throughput at a scale that's genuinely hard to replicate elsewhere. IBM Z systems are built for extremely high transaction volumes with strict consistency guarantees and uptime measured in the range of five nines, and a lot of that core business logic, banking cores, insurance claims systems, has been running correctly for decades. Rewriting decades of correct, battle-tested COBOL business logic carries real risk of introducing new bugs, and the cost of that risk, for a bank's core ledger say, is much higher than the infrastructure savings from moving off Z. The honest answer isn't "mainframes are technically superior forever," it's "the cost of rewriting outweighs the benefit for this specific class of workload," which is a narrower and more defensible claim.

watsonx is IBM's enterprise AI and data platform, built around three pieces: watsonx.ai for building and tuning foundation models, watsonx.data for a hybrid data lakehouse that feeds those models, and watsonx.governance for tracking model risk, bias, and compliance across whatever models an organization deploys. The positioning IBM leans on isn't "our models are the biggest," it's governance and hybrid deployment, letting a regulated client run models on their own infrastructure or a private cloud instance rather than sending sensitive data to a third-party API, with an audit trail attached to every model decision.

Day-to-day work skews heavily toward workshops with client stakeholders, documentation (requirements, architecture decisions, status reports), and coordinating across whatever mix of IBM team members and client staff is actually delivering the work, more than it skews toward heads-down individual technical work. A candidate who describes the role purely in terms of writing code or building architecture, without mentioning client communication as a core part of the job, signals they haven't actually talked to anyone currently doing the role.

The answer interviewers actually want to hear isn't the mistake itself, it's what happened in the ten minutes after you found out. Did you tell someone immediately, or did you quietly try to fix it first and hope nobody noticed. A strong answer names the mistake plainly, without minimizing it, describes the immediate corrective action you took, and names one concrete thing that changed afterward, in a process or in your own habits, so the same mistake doesn't repeat.

Look for a specific starting condition, a missed deadline before you joined the project, a previous vendor's failure, a stakeholder who was openly skeptical in the first meeting, and a specific action that changed the relationship, not just "I worked hard and it got better." Trust usually gets rebuilt through small, kept commitments accumulating over weeks, not one grand gesture, so a credible answer often names a series of small delivered promises rather than a single dramatic turnaround moment.

IBM, like most large enterprise employers, uses banded compensation tied to job level and location, and the recruiter screen is typically the point where you're asked for your expectations before the band gets shared back. Come into that conversation with your own researched range for the specific role, level, and location, rather than answering with a vague "open to whatever," since a vague answer gives the recruiter no anchor to negotiate from on your behalf internally.

IBM does sponsor visas for a portion of its roles, but sponsorship availability varies by specific requisition, business unit, and year depending on internal quotas and budget. This is a fair, direct question to ask the recruiter in the first screen rather than assuming and finding out three rounds in, since visa sponsorship for a given role is often decided at the requisition level before the role is even posted, not something a hiring manager can simply grant later in the process.

Policy varies by business unit and role rather than a single company-wide rule, and it has shifted more than once in recent years, so treat whatever you read online as a starting point to confirm directly with the recruiter, not a fixed fact. Client-facing consulting roles in particular often carry travel expectations tied to a specific client site regardless of the broader remote-work policy, so ask specifically about travel percentage for the role you're interviewing for, not just "is this remote."

Both show up, and which one you get depends on the team and level. Early-career and new-grad roles more often use a timed online assessment, frequently through HackerRank, covering standard data structures problems before you ever talk to a human. Mid-level and senior engineering roles are more likely to get a live coding round over a shared editor, sometimes paired with a short design discussion in the same session rather than as a separate round. A live round tells the interviewer more about how you think under pressure and how you respond to a hint, which matters more the more senior the role gets.

IBM Consulting interviews test a different muscle. Instead of a coding round, expect a case-style conversation: a client has a problem (a legacy system that needs modernizing, a merger that needs two ERPs reconciled, a compliance deadline that needs a data migration finished on time), and you're asked to talk through how you'd structure the engagement, who you'd need on the team, and how you'd communicate risk to a client executive who doesn't care about your architecture diagram. Technical depth still gets probed, but it's probed in service of "can this person run a workstream," not "can this person write a balanced binary tree from scratch."

Standard fare for the format: two or three problems, usually array manipulation, string processing, or a graph or tree traversal, solvable in Python, Java, or a handful of other common languages, with a fixed time window and automated test cases. Nothing IBM-specific shows up at this stage, it's closer to a generic screening filter than a test of enterprise knowledge. The bar is passing enough test cases in the time given, not writing the most elegant solution, so a working brute-force answer that passes is worth more here than an elegant one you don't finish.

A process has its own isolated memory space, so processes can't directly read or write each other's variables, only communicate through explicit channels like sockets or files. Threads within the same process share that memory space, which makes communication between them cheap and fast but also means one thread's bug, a race condition, an unsynchronized write, can corrupt data another thread depends on.

On IBM's Java-heavy enterprise stack, this distinction shows up constantly in production incident reviews: a JVM process handling a high-throughput transaction service typically runs many worker threads sharing connection pools and caches, so a synchronization bug in one thread pool doesn't crash the whole process the way an unhandled exception in a single-process architecture might, but it can silently corrupt shared state across every thread using that pool.

A portable way to do this, one that works the same in Db2 as it does in most other SQL dialects, is a correlated subquery counting how many distinct salaries are strictly greater than each row's salary.

SELECT salary
FROM employees e1
WHERE 1 = (
  SELECT COUNT(DISTINCT salary)
  FROM employees e2
  WHERE e2.salary > e1.salary
);

This returns the salary where exactly one distinct salary is higher than it, which is the second-highest by definition, and it handles ties (two employees earning the top salary) correctly, unlike a naive MAX-then-exclude approach that can return the wrong row depending on how ties are handled.

An abstract class can hold shared state and partially implemented methods, and a subclass extends exactly one of them. An interface (since Java 8) can hold default methods too, but no instance state, and a class can implement as many interfaces as it needs. Pick an abstract class when subclasses genuinely share implementation and state, a base class for different payment processors that all track a shared transaction log, say. Pick an interface when you're defining a contract that unrelated classes need to satisfy, something like Comparable or Serializable, where the implementing classes have nothing else in common.

Three levels of isolation to choose from, in order of increasing cost and increasing guarantee: shared database with a tenant_id column on every table, separate schema per tenant within a shared database, and fully separate databases per tenant. Shared-table is cheapest to run and easiest to maintain, but every single query has to correctly filter by tenant_id, and one missed WHERE clause anywhere in the codebase becomes a cross-tenant data leak.

For enterprise clients with strict compliance requirements, which is most of IBM's actual client base, separate databases per tenant is often the answer even though it costs more to operate, because it makes data isolation a structural guarantee rather than something every engineer has to remember to enforce correctly on every query, forever.

CAP theorem says a distributed system can't simultaneously guarantee consistency, availability, and partition tolerance, all three, once a network partition happens, you have to give up one of consistency or availability, since partition tolerance isn't really optional in a system spread across multiple regions.

For inventory specifically, the honest answer depends on the item. Overselling a low-stock, high-demand item during a network partition is a real business problem, so that path might lean toward consistency, rejecting a sale rather than risk it. A general product catalog page showing slightly stale stock counts during a brief partition is a much smaller problem, so that path can lean toward availability. A good answer doesn't pick one side for the whole system, it identifies which parts of the system actually need which guarantee.

Start with what "available" actually needs to mean for this specific system, since the answer changes the design significantly. Active-active across regions, where every region serves live traffic and data replicates both ways, gives the best availability and the lowest latency for users near each region, but it forces you to deal with conflict resolution when the same record gets written in two regions before replication catches up. Active-passive, where one region serves traffic and a second stands by to take over, is simpler to reason about and avoids write conflicts entirely, but it costs you failover time during an actual regional outage and leaves the standby region's compute mostly idle.

For most enterprise clients I've seen IBM design for, active-passive with a fast, tested failover process is the practical answer, since the operational complexity of active-active conflict resolution is rarely worth it unless the system is genuinely global-scale with latency-sensitive users on every continent.

JCL, Job Control Language, tells z/OS what program to run, what datasets to allocate as input and output, and what to do if a step fails, similar in purpose to a shell script but structured very differently. Where a shell script is a sequence of imperative commands, JCL is declarative: you define job steps, each naming a program and its data definitions (DD statements), and the system handles resource allocation and scheduling around that declaration.

//MYJOB  JOB (ACCT),'RUN REPORT',CLASS=A,MSGCLASS=X
//STEP1  EXEC PGM=SORT
//SORTIN  DD DSN=MY.INPUT.DATA,DISP=SHR
//SORTOUT DD DSN=MY.OUTPUT.DATA,DISP=(NEW,CATLG)
//SYSIN  DD *
 SORT FIELDS=(1,10,CH,A)
/*

Candidates without mainframe background rarely know this syntax cold, and interviewers generally don't expect it, but being able to explain the concept, declarative job and dataset definitions instead of imperative commands, signals you've at least been exposed to how the platform actually runs work.

At the SQL level the differences are smaller than people expect, all three are relational databases with broadly similar SQL. The practical differences show up in the operational layer: Db2 for z/OS is built to run on the mainframe alongside the transaction workloads it serves, tightly integrated with z/OS's own resource management, security, and recovery tooling, in a way that's simply not applicable to Postgres or MySQL running on commodity Linux servers. Db2 also has a long history of specific optimizer behavior and locking semantics (row-level versus page-level locking configurations) that a DBA moving from an open-source database needs to relearn rather than assume transfers directly.

OpenShift is Red Hat's enterprise Kubernetes distribution, adding developer tooling, built-in CI/CD pipelines, and security defaults on top of raw Kubernetes so an enterprise doesn't have to assemble that tooling itself from scratch. IBM's $34 billion acquisition of Red Hat in 2019 was explicitly framed as building "the world's number one hybrid cloud provider" (IBM Newsroom, 2019), because OpenShift can run identically across on-prem data centers, IBM Cloud, and other public clouds, letting a client with regulatory constraints or legacy investments run the same containerized applications wherever the workload needs to live, without a full rewrite for each environment.

watsonx.governance tracks model behavior across its lifecycle, monitoring for drift, bias, and fairness metrics, and keeping an audit trail of what data trained a model and what decisions it's made in production. Enterprise clients in regulated industries, banking, insurance, healthcare, care because a regulator can ask them to explain and justify an automated decision months or years after it happened, and "the model said so" isn't an acceptable answer to a banking regulator asking why a loan application got denied. Governance tooling exists to make that explanation possible after the fact, not just to make the model itself more accurate.

Start by pushing back on the framing that this is purely a technical migration problem, it's a risk-management problem first. The practical approach is a strangler-fig pattern: build the new system alongside the old one, route a small, low-risk slice of traffic or functionality to the new system first, verify it behaves correctly against the old system's known outputs, and expand the slice gradually rather than attempting a single cutover weekend.

The part clients actually need reassurance on isn't the migration pattern itself, it's the rollback plan for each slice. Every phase needs a clear, tested way back to the old system if something goes wrong, and being able to describe that rollback path concretely, not just gesture at "we'll monitor closely", is usually what separates a consultant a client trusts from one they don't.

Scope creep isn't inherently a problem, unmanaged scope creep is. The fix is a change-control process agreed on before the engagement starts: any new requirement gets documented, estimated for impact on timeline and budget, and explicitly approved (or declined) by the client sponsor before it gets built, rather than quietly absorbed into the existing plan and discovered as a delay later. That conversation is uncomfortable in the moment, telling a client a request they consider minor actually adds two weeks, but it's far less damaging to the relationship than missing a deadline the client never knew was at risk.

Translate the tradeoff into terms of cost, time, and risk, the three things every business stakeholder already understands, rather than terms of architecture. Instead of "we could use eventual consistency or strong consistency," the version that actually lands is "we can make this feature update instantly everywhere for more engineering cost and complexity, or update within a few seconds for less cost, and here's what a few seconds of delay would actually mean for your customers." Naming the concrete business consequence of each option is what makes the conversation productive, jargon just makes the stakeholder nod along without actually deciding anything.

The phrase "innovation that matters" is deliberately doing work here, IBM's framing distinguishes innovation with real client or business impact from novelty for novelty's sake. A strong answer names the specific problem the innovation solved, quantifies the impact if you can (time saved, cost reduced, an error rate that dropped), and is honest that the idea probably wasn't entirely original, most real innovation adapts an existing idea to a new context rather than inventing something from nothing.

Interviewers are listening for whether you can describe the other person's perspective fairly, not just your own side of the story. A one-sided account where the other person is simply wrong and you were simply right reads as a lack of self-awareness. The stronger version names what the other person's position actually was, why it made sense from where they sat, and what specifically changed, a compromise, new information, a decision escalated to someone else, to resolve it.

This one comes up constantly at IBM specifically, given how much delivery work spans teams in the US, India, and Europe on the same engagement. A strong answer names a concrete coordination mechanism you used, overlapping core hours, asynchronous written status updates instead of relying on live meetings everyone has to attend, a clear single owner for decisions that can't wait for a synchronous conversation, rather than a vague claim that you "communicated well."

A generic answer, "I want to work at a big impactful company," fits literally any large employer and signals you didn't research this one specifically. A stronger answer names something concrete about IBM's actual position, its hybrid cloud bet since the Red Hat acquisition, its specific client base in regulated industries, the scale of legacy enterprise systems it works with that most cloud-native companies never touch, and connects that to something real about your own background or interest, not just a fact you looked up an hour before the interview.

Pick a failure where you had real accountability, not one where blame conveniently lands entirely on someone else, a client who changed requirements, a vendor who missed a deadline. The strongest version names a decision you made that, in hindsight, contributed to the failure, and describes concretely what you do differently now because of it. "I learned to communicate better" is too vague to be believable. "I learned to get a written sign-off on requirements before starting build, because I once spent three weeks building the wrong thing based on a verbal agreement that got remembered differently by both sides" is specific enough to actually land.

IBM is large enough that internal transfers between business units, moving from Consulting into Software, say, are genuinely common and often easier than the equivalent external job search would be, since you're already a known quantity internally. The tradeoff candidates should know before asking this in an interview: internal mobility usually still requires interviewing for the new role like an external candidate would, it's not an automatic lateral move, so "internal mobility exists" doesn't mean "moves happen without effort."

It's fair to acknowledge you're aware of it rather than pretend you aren't, interviewers generally respect a candidate who's done real research over one who recites only the positive talking points. A credible "why now" answer names the specific part of the business you're joining and why that part looks stable or growing (a specific product line's momentum, a specific client base's demand) rather than making a blanket claim about the whole company's health, since the whole company's health isn't actually the relevant question for whether your specific team is a good bet.

Scope varies by team, but a common pattern is a small backend service, a REST API with a handful of endpoints, backed by a database, with a prompt that explicitly says to prioritize correctness and clear structure over building every feature you can think of. Interviewers reviewing these are generally looking for clean separation of concerns and reasonable test coverage over cleverness, a straightforward, well-organized solution beats an overengineered one that tries to demonstrate every design pattern the candidate knows.

Detailed enough to show your reasoning process, not detailed enough to read like a full consulting deliverable. The reviewer wants to see how you structured the problem, what assumptions you made explicit, and what tradeoffs you considered and rejected, not a polished slide deck with every section a real client engagement would eventually need. A two-to-three page writeup that clearly shows your thinking beats a fifteen-page document that buries the actual reasoning under formatting.

Most take-homes state an expected time budget, commonly somewhere in the two-to-four-hour range, and it's a completely reasonable move to email the recruiter if the assignment as written genuinely can't be done well in that window, rather than either silently burning eight hours or turning in something rushed. Recruiters would rather hear "this seems bigger than the stated scope, can you confirm what depth you're expecting" than receive a half-finished submission with no context about why.

Candidates commonly report anywhere from two to six weeks for professional-hire roles, longer for roles requiring a security clearance or specific client-facing background checks, and it can stretch further around fiscal quarter transitions when hiring freezes or budget re-approvals slow things down. IBM is a large, decentralized organization, so the actual pace depends heavily on how quickly the specific hiring manager and their calendar move, not on some company-wide SLA. If a stage goes quiet for a week and a half, that's more often a scheduling backlog on the hiring team's side than a signal about your candidacy, though it's still fair to follow up with the recruiter directly rather than guess.

Start with a heap dump taken while the service is under the memory pressure, not after a restart wipes the evidence. Tools like Eclipse MAT or the heap analysis built into IBM Support Assistant will show you the dominator tree, which objects are holding the most retained memory and, more importantly, what's still referencing them and preventing garbage collection.

The usual suspects in a Java enterprise service are static collections that grow without an eviction policy, listener or callback registrations that never get unregistered, and thread-local variables that outlive the thread pool's assumptions about cleanup. The fix is rarely a code rewrite, it's usually adding a bound (a max size, a TTL, an explicit unregister call) to whatever collection or registry was silently growing. I've seen this exact pattern, an event listener list that only ever grew, take down a service after eleven days of otherwise-clean uptime, which is long enough that nobody suspects a leak until it's already an incident.

A deadlock needs two threads each holding a lock the other one needs, waiting on each other forever. Classic setup: thread A holds lock 1 and wants lock 2, thread B holds lock 2 and wants lock 1, neither can proceed and neither releases what it's holding.

// Deadlock-prone: locks acquired in different orders
synchronized (lock1) {
  synchronized (lock2) { /*... */ }
}
// meanwhile, another thread does:
synchronized (lock2) {
  synchronized (lock1) { /*... */ }
}

The standard fix is establishing a strict, consistent lock ordering across the whole codebase, every code path that needs both locks acquires them in the same order, so the circular wait condition can never form. A less code-heavy alternative is using tryLock with a timeout instead of a blocking acquire, so a thread that can't get the second lock backs off and retries instead of waiting forever.

Start with what the mainframe workload actually does well: extremely high transaction throughput with strict consistency guarantees, batch processing windows measured in the tens of millions of records overnight, and decades of business logic that's been correct for decades precisely because nobody's touched it. Moving that core transactional logic off Z rarely makes sense on its own, the risk of introducing a subtle correctness bug usually outweighs any infrastructure cost savings.

What usually does make sense to move: the presentation layer, reporting and analytics workloads that read from the mainframe but don't need its transactional guarantees, and new feature development that doesn't depend on the existing COBOL business logic. The pattern IBM sells here is exposing mainframe data and transactions through APIs, letting new cloud-native services on OpenShift consume that data without ever touching or rewriting the underlying core system. The mainframe stays the system of record, the cloud layer becomes the system of engagement.

A Cloud Pak is a bundled, pre-integrated set of enterprise software packaged to run on OpenShift, aimed at cutting the months of integration work an enterprise would otherwise spend wiring together middleware, security, and monitoring components by hand. Cloud Pak for Integration bundles API management, messaging, and event streaming together, for instance, already configured to work with each other and with OpenShift's security model, rather than an enterprise team hand-assembling each piece from separate vendors and discovering the integration gaps themselves.

The tradeoff candidates should be honest about: a Cloud Pak trades some flexibility for integration speed. A team that needs a specific configuration the Cloud Pak doesn't support has less room to customize than they would building the same stack from individual open-source components directly.

The honest technical case, not the marketing version: before the acquisition, IBM's own cloud offering competed directly with AWS and Azure on their terms, hyperscale public cloud, and was losing that fight on scale alone. Red Hat's OpenShift gave IBM a different battlefield entirely, one where enterprises with existing on-prem and mainframe investments could run the same Kubernetes-based applications across any environment without picking a single cloud vendor to bet everything on.

That's a real technical answer, not just a business one: portability across environments is a genuine engineering property, not a slogan, and it's the specific gap that public-cloud-only vendors don't naturally fill, since AWS and Azure's business model depends on making their own cloud the easiest place to run, not the most portable one.

The honest, harder version of this answer includes what happened when you were overruled, not just the case where your pushback won. Interviewers are testing whether you can disagree professionally and then commit to the decision that gets made, even when it doesn't go your way, rather than quietly working around a decision you disagreed with. A candidate who only has stories where they were right and got their way hasn't demonstrated that second, harder skill at all.

Beyond whether the thing runs and passes obvious test cases, reviewers are typically weighing code organization and naming, whether edge cases got handled or just ignored, whether tests exist and actually test meaningful behavior rather than trivial getters, and how the accompanying README explains tradeoffs you made under the assignment's time constraint. That last piece matters more than candidates expect, a short note explaining "I skipped input validation on X because the prompt didn't specify expected behavior there, and here's what I'd add given more time" signals awareness of the gap, which reads very differently to a reviewer than a gap you never mention at all.

A hash map alone gives fast lookup but no ordering, and a linked list alone gives ordering but slow lookup. Combining a hash map with a doubly linked list gets both: the map gives O(1) access to any node, and the list tracks recency, with the most recently used item moved to the front and the least recently used item evicted from the back once capacity is hit.

class LRUCache {
  private final int capacity;
  private final LinkedHashMap<Integer, Integer> map;

  LRUCache(int capacity) {
    this.capacity = capacity;
    this.map = new LinkedHashMap<>(capacity, 0.75f, true) {
      protected boolean removeEldestEntry(Map.Entry eldest) {
        return size() > LRUCache.this.capacity;
      }
    };
  }

  int get(int key) {
    return map.getOrDefault(key, -1);
  }

  void put(int key, int value) {
    map.put(key, value);
  }
}

Java's LinkedHashMap already implements the access-order behavior you'd otherwise hand-roll with a map plus a manual doubly linked list, and interviewers usually accept either approach as long as you can explain why access is O(1) either way.

Token bucket is the usual answer, and it's the right one for most API rate-limiting needs: each client gets a bucket that refills at a fixed rate, and each request consumes one token, so bursts up to the bucket's capacity are allowed but sustained overuse gets throttled once the bucket empties.

The interesting part of this question in a distributed system is where the bucket state lives. A single-instance in-memory counter is trivial but breaks the moment you run more than one API gateway instance behind a load balancer, since each instance would track its own independent limit. The real answer is a shared store, Redis is the common choice, with an atomic increment-and-check operation so two gateway instances can't both approve a request that should have been the one over the limit.

The core pattern is a circuit breaker in front of each backend dependency: track failure rate for calls to that service, and once failures cross a threshold, stop sending traffic to it entirely for a cooldown period instead of letting every request time out slowly and pile up threads waiting. After the cooldown, let a small number of test requests through, and if they succeed, close the circuit and resume normal traffic.

Closed (normal) --failures exceed threshold--> Open (reject fast)
Open --cooldown timer expires--> Half-Open (test traffic)
Half-Open --test succeeds--> Closed
Half-Open --test fails--> Open

Pair that with sensible timeouts (a slow backend is often worse than a down one, since it ties up gateway threads without failing fast) and a fallback response, cached data, a degraded response, or a clear error, for the caller when the circuit is open.

Break the engagement into discovery, design, build, and stabilization phases, and estimate each separately rather than one lump number for the whole thing, since the uncertainty in each phase is different. Discovery is usually the hardest to estimate accurately because you don't yet know what you don't know about the client's existing systems, so it's worth padding that phase's estimate more generously than the build phase, where the scope is clearer by the time you get there.

The honest answer also names the biggest estimating trap directly: teams consistently underestimate integration work with existing systems, because it's invisible until you're actually inside the client's environment discovering undocumented dependencies. A good estimate builds in explicit contingency for that category specifically, rather than a flat percentage buffer applied evenly across every phase.