Integration Engineer Interview Questions 2026

Last updated: August 30, 2026

By Tom Kenaley, President & Senior Partner, KORE1

Integration engineer interview questions in 2026 should test contract reading, duplicate delivery, schema drift, credential expiry, and partial batch recovery, not definitions of REST, SOAP, or middleware that any candidate can recite. The published question lists are written for the person being interviewed. Not your job. Yours is to find the thirty minutes of conversation that separate an engineer who has carried a broken integration from one who has only drawn them.

A distributor outside Grand Rapids sent 4,100 duplicate purchase orders into their ERP over a Saturday. Their trading partner had a bad deploy, the partner’s own retry logic replayed a batch it had already delivered, and the integration on our client’s side accepted every line of it without complaint. Nobody was watching. By Monday the buyers were looking at a purchase order queue that had quadrupled overnight and a receiving team that had already cut two POs loose to suppliers.

Six weeks earlier they had hired an integration engineer. Strong resume. MuleSoft, some Kafka, eleven years, four panelists, everyone left the loop happy.

Not one person in that loop had asked him what his code does when the same message shows up twice.

Here is my angle so you can discount it appropriately. KORE1 places integration talent and we get paid when the placement is still there a year later, which is a long enough horizon that I would rather hand you a loop you can run without us than sell you a search you did not need. Run the questions below yourself. I mean it. Nothing here is gated. Where we do get pulled in, the work runs through our integration engineer staffing desk, which sits under IT staffing services, and plenty of these reqs end up touching ERP consultant staffing as well, since the systems being connected usually include somebody’s ERP. One caveat before you keep going. Everything below assumes you already have a req and an approved number. Where either of those is still an internal argument, our walkthrough on scoping and pricing the role settles it faster than this page will.

Read the Req Back Before You Write a Single Question

Three companies sent us reqs titled Integration Engineer in the same month last year, and if you had put the three job descriptions side by side with the titles removed, nobody in our office would have guessed they were the same search. One wanted somebody to own 60 EDI trading partner maps. One wanted a person to build and version public REST APIs for a product team. The third wanted NetSuite talking to Shopify and a warehouse system by the end of Q3. Three jobs. One title. Almost no overlap in what a good hire looks like.

Sort yours before you build a loop. The sorting decides which artifact you put in front of the candidate, and that artifact does more screening work than any question you can write down. If the req itself is still vague, the integration engineer job description template is the faster way to pin the seat down before you get here.

Two of those rows is normal. Most reqs land there. If it touches all four, you are writing an architect search, not an engineer search, and the pay band you have approved is probably wrong by thirty thousand dollars. Our solutions architect interview questions cover that version of the loop.

Start With a Contract They Have Never Seen

Open the technical screen by handing over a document. Not a question. A document. Paper, ideally.

One page is plenty. An OpenAPI fragment, a WSDL, a partner’s implementation guide, a JSON sample with three nested arrays in it. Sanitize it, print it, and slide it across. Then ask the only question that matters here. What would you want to know before you built against this?

Weak candidates describe the document back to you. They name the fields, note that it is REST, observe that the dates look like ISO 8601, and stop there. That is reading comprehension. Not the skill.

Strong candidates start interrogating it. Is that field always present or only sometimes. What happens if I send the same request twice. Where is the pagination. Is this a total or a delta. Who owns this spec and how do I find out when it changes. Nobody teaches that list. It comes from having built against a document that turned out to be wrong, at some cost, in front of people.

The best answer I heard to that question last year was four words long. The candidate looked at the page for maybe fifteen seconds, then asked whether it was the current version. That question alone was worth the screen.

Ask About the Redelivery, Then Stop Talking

The Grand Rapids failure was a duplicate delivery problem. That is what makes it the right thing to ask in round one, before anybody spends an afternoon.

Ask it plainly. Your consumer processes a message, then the process dies before it acknowledges. So what happens next, exactly?

Then say nothing. The silence is the instrument here, and most interviewers cannot stand it for more than four seconds. Somebody who has carried this will fill it with an incident, a date, and a person they had to go argue with. Somebody who has not will fill it with vocabulary. The vocabulary is usually correct, which is exactly the problem, because correct vocabulary is free.

That whole exchange takes five minutes. Nobody acquires this model during an interview. What a strong answer actually contains is worked through properly in the 2026 integration engineer hiring guide, and the architectural version of the same test is how we screen the integration architect bench.

When the Payload Changes and Nobody Told You

Every integration that has been in production for two years has survived at least one unannounced change on the other side of the wire. A field went from optional to required. A vendor started sending a decimal where an integer used to be. Somebody renamed a status code from ACTIVE to Active and the string comparison that had been running fine since 2023 quietly stopped matching anything.

Ask how they found out about the last one. Not how they fixed it. How they found out.

That, verbatim, is the question. The abstract version, how do you handle schema changes, gets you an abstract answer about versioning strategy. The concrete version gets you a story, and the story tells you whether they were the person who found it or the person who got the ticket after finance found it.

Good follow-ups here, and you only need two of them:

• What broke first, the integration or something downstream of it?
• After you fixed it, what did you change so the next one would be louder?

The second question separates seniority. A mid-level engineer fixes the mapping. Then moves on. A senior one adds a schema validation step at the boundary, or a contract test that runs against the partner’s sandbox nightly, or an alert on an unexpected enum value. They put a tripwire in. Ask what the tripwire was. Then ask whether it ever fired.

Candidates who have worked in event-driven estates should be able to talk about schema registries and compatibility modes without being prompted. If they mention CloudEvents or a registry with backward compatibility enforcement, that is a real signal, not a buzzword, and it is worth two more minutes of your time.

Credentials Are the Silent Killer

Ask any engineer who has run integrations for five years what has woken them up most often and you will not hear about throughput. You will hear about a certificate. Or a rotated key.

This is the least glamorous part of the interview and it correlates better with real experience than almost anything else in it. The questions are boring on purpose. Ask them anyway.

How do you handle an OAuth refresh token that gets rotated by the provider? Where do the credentials for the sandbox live versus production, and who can see them? What happens on the day a client certificate expires, and how do you know that day is coming before it arrives? If a partner uses IP allowlisting, what breaks when your infrastructure team moves the NAT gateway?

Somebody who has lived through this has opinions about all four and probably a grievance about at least one, usually delivered with the specific flatness of a person who has already explained it to an auditor. The grievance is the signal. Candidates who have only built integrations in a lab talk about secrets managers in the abstract. Candidates who have operated them tell you about the time a cert expired on a holiday weekend because the renewal notice went to a mailbox belonging to somebody who left the company in March.

Half the Batch Landed. Now What?

Here is a scenario worth reading out loud, word for word, in every one of these interviews.

You push 500 invoices to a downstream system in a nightly batch. The job fails partway. The vendor’s API returns a 500 and no body. You have no idea how many of the 500 posted. The finance close is tomorrow. Walk me through the next hour.

You are testing one thing. Does the candidate reach for a rerun, or for the truth? Reruns feel productive. A rerun on a partially applied batch is how you get the Grand Rapids problem.

The answer you want goes somewhere near this. Stop the job so nothing else moves. Find out what actually landed, either by querying the target system by document number or by pulling their transaction log, and if neither of those exists, that is the real finding and it goes in the post-mortem. Reconcile before you replay. Always. Then, when it is fixed, make the batch resumable so the next failure is a smaller conversation.

There is a bonus signal buried in this one. Some candidates will complain, unprompted, about the empty 500 response body. Let them. Encourage it. An engineer who has spent time on the receiving end of undocumented vendor errors will often know that RFC 9457 standardized a problem details format for exactly this reason, and that most vendors ignore it. That is not a trivia win. It tells you they have thought about what a good error actually looks like, which usually means the errors they emit are better than average.

Ask How They Test Against a System They Do Not Control

Integration work has a structural problem that most software roles do not. Half of the system belongs to somebody else, and that half has a sandbox that is stale, rate-limited, occasionally down, and not quite the same as production.

So the question is short. How do you test?

Listen for specifics. Recorded fixtures from real production payloads. Contract tests. A mock that gets rebuilt from the vendor’s actual responses rather than from their documentation. A staging trading partner that the vendor agreed to set up, which usually means the candidate had to go negotiate for it, which is its own kind of signal about whether this person can operate outside the codebase.

The weak version of this answer is that they tested in the sandbox and then watched production carefully after deploy. Everybody has done that. If it is the whole answer, they have been handed environments rather than built them.

Who Finds Out First When It Breaks

An integration that silently stops is worse than one that fails loudly. Most panels never test for this.

The integration stops working entirely at 4 a.m. Who learns about it first, and how?

A good answer names a mechanism. A heartbeat, a staleness alert on a table that should have grown, a dead letter queue with an alarm on its depth, a scheduled reconciliation that compares record counts across both sides. A great answer names the mechanism and then tells you what it costs, because every alert like this has a false-positive rate and somebody has to tune it.

The answer that should worry you names a person. Not a mechanism. A person. If the way anybody finds out is that the warehouse calls, you are hiring somebody who has worked in an environment where the users were the monitoring. They can learn better. Most do. Just know that is what you are buying, and price the ramp accordingly.

Ask one follow-up about the dead letter queue specifically. Who owns it, and what happens to a message that lands there? In a lot of companies the honest answer is that nothing happens, ever, because the queue was set up by somebody who has since left, the alarm on it was muted during an unrelated incident in 2024, and there are now 40,000 messages sitting in it that nobody has opened. A candidate who admits that about a previous job is being honest with you about something unflattering, and that is worth more than a polished answer.

The Exercise Worth Building Once

Nothing in this loop needs a take-home. The pool for this role is small, good people have options, and a four-hour unpaid assignment filters out strong candidates faster than weak ones. It is a bad trade.

Run this instead. Not a scenario you describe out loud. A printed page.

Prepare one artifact ahead of time and reuse it for every integration search you run from now on. A sanitized log from a real integration failure you actually had, twenty or thirty lines, with the timestamps intact and a couple of red herrings left in. Give it to the candidate at the start of a working session, share the target system’s documentation, and spend forty-five minutes on one question. What happened here, and what would you check next?

You are not grading whether they get it right. Watch the order of their questions instead. People who have done this work start narrow and go wide only when they have to. They will ask about the timestamp gap. They will ask whether the retry was ours or theirs, and whether the retry interval was fixed or backed off, and whether anything in the log tells them the difference between a call that never arrived and one that arrived and never answered. They will want to know whether anything downstream moved. Somebody who has not done this work starts with the architecture diagram, which is the same instinct that makes a person redeploy before they diagnose.

Build the artifact once. One afternoon. You will use it for years.

Price the Seat Before the First Call

Set the band before the first conversation, not after the finalist asks. Integration engineer is one of the noisiest titles in compensation data because the title covers those four seat shapes and the aggregators do not separate them.

Read the gap between those rows rather than picking a favorite. Payscale reports base salary only. Glassdoor reports total pay. Neither is wrong and the two are not measuring the same thing, which is how a single title ends up with a forty thousand dollar spread in its average before anybody has discussed a candidate. Our 2026 pay benchmarks for the role take that apart by level and by interface count, and it is the right page to open before you approve a number.

For interview purposes you only need one thing out of it. The band you are holding has to survive the seat shape you picked at the top of this page. A candidate who runs a partner estate or an event platform at scale prices above a general integration req, and a seat that requires a named iPaaS platform in production narrows the pool in a way that turns up in every offer conversation. That is why MuleSoft developer and Boomi integration developer searches do not price like a general one.

One more thing the trackers will not tell you. A seat carrying a real on-call rotation should carry a differential. The people who are good at this have been on call before. They will ask. If you want a fast sanity check against live market data before you post, our salary benchmark tool is free and does not require a conversation with anyone.

The market context underneath all of this is worth one sentence. Gartner put 2026 worldwide software spending growth at 14.7% and total software spending above $1.4 trillion in its February 2026 forecast, and every one of those purchases eventually becomes something that has to talk to a system the buyer already owns. The Bureau of Labor Statistics projects about 106,100 openings a year for software developers, quality assurance analysts, and testers across the 2024 to 2034 decade. Integration sits inside that number without having its own line, which is part of why the comp data is a mess.

Four Conversations, in This Order

Sequence matters more than question count. Run four. Then stop.

1. Recruiter or hiring manager screen, 30 minutes. Confirm the seat shape matches their history and that the band is not going to blow up in week three. Ask one technical question here, the duplicate delivery one, because it is fast and it is decisive.
2. Technical screen with the artifact, 45 minutes. Hand over the contract document. Spend the first fifteen minutes on what they would want to know before building against it, then move into credentials, schema drift, and testing against systems they do not control.
3. Working session with the broken log, 60 to 90 minutes. Two people from your side maximum. One should be whoever gets paged today when an integration fails, because that person can tell in ten minutes whether the candidate’s instincts are real.
4. Final conversation, 30 minutes, no new technical content. Scope, on-call reality, who owns the integrations after this hire, what the first ninety days look like. Then decide the same week.

Four rounds is the ceiling here. Three is often enough. Our average time-to-hire runs 17 days for IT roles, which is only achievable when the client can move from final conversation to offer inside a week. Add a fifth round and you are not gathering information anymore. You are buying the chance to lose a finalist to somebody who moved faster, which happens more in integration searches than in general backend searches because these candidates are rarely on the market by accident.

Answers That Sound Complete and Are Not

Some patterns worth slowing down on. None are automatic rejections. All deserve one more question.

A tool list with no failure attached to it. Somebody names six platforms and describes none of them behaving badly. Platforms behave badly. If nothing on the list ever misbehaved, they watched somebody else operate it.

Everything at the diagram layer. Boxes, arrows, patterns, no payloads. Ask what a record actually looks like in the system they described. The answer arrives fast or it never arrives.

A robust error handling framework, described in exactly those words and no others. Ask what was in the dead letter queue on their last day.

Blaming the vendor for every incident. Vendors do cause a lot of incidents, so this one is tricky. The thing to listen for is whether any of those stories ends with a change they made on their own side. If every story ends with the vendor fixing it, they were a ticket router.

And the one that costs the most. A candidate who has only ever built new integrations. Greenfield work is a genuinely different skill from inheriting 40 undocumented interfaces and figuring out which ones anybody still uses. If your environment is the second kind, and most are, ask directly what the oldest integration they have ever inherited was and what they did with it. We wrote up what that inheritance actually looks like in our point-to-point integration decoupling playbook.

What Lands in Our Inbox About This Search

Does an iPaaS certification tell us anything?

Very little on its own. A platform certification confirms somebody sat through the training and passed a test on the vendor’s own product, which is a floor rather than a signal.

Where it does carry weight is one narrow case. If your entire estate is one platform and the req is genuinely to operate that platform, a certification plus real production hours is a reasonable filter for a first pass through a large applicant pool. The certification alone is not. I have interviewed certified candidates who had never deployed to production. I have also met uncertified ones running 200 interfaces. What sorts people is how many interfaces they carried, what volume moved through them, and whether the estate was theirs from day one or handed over mid-life. No credential answers any of that.

Our platform team says they can absorb this work. When is that actually true?

When the integrations are few, internal, and stable, and when one named person on that team has integration ownership written into their goals rather than added to their week.

It stops being true faster than most engineering leaders expect. The tipping point, in my experience, sits around a dozen live interfaces or the first external trading partner, whichever comes first, because an external partner introduces a schedule you do not control and an escalation path that runs through somebody else’s support queue. What you usually see before anyone admits the absorption failed is a slow leak of senior engineering time into integration firefighting. Nobody logs it that way. It shows up as a roadmap that keeps slipping, for reasons that always sound unrelated.

Integration engineer or backend engineer, are we writing the wrong req?

If most of the work is building your own services and the integration surface is incidental, write a backend req. If most of the work is making systems you did not build agree with each other, write an integration req.

The overlap is real and plenty of people do both. The reason it matters is sourcing, not semantics. A backend req pulls a much larger candidate pool that is mostly wrong for this seat, and you will spend six weeks screening strong engineers with no patience for partner specs. We run both, through software engineer staffing and the integration bench respectively, and the searches do not look alike. Different channels, different screens, different close rates.

Is it fair to test someone on a system we run and they have never seen?

It is fair, provided you grade the approach rather than the answer and you say so before the exercise starts.

The framing takes one sentence. You have never seen this system, that is deliberate, and I want to watch how you get oriented. Then the exercise tests what you actually need, because nobody you hire will have seen your specific environment either. What you should not do is hold platform-specific trivia against somebody. Whether they know the exact name of a NetSuite saved search or a particular Boomi shape is not the job. Whether they know to ask what happens to records that were mid-flight when the last job failed absolutely is.

We lost our last two finalists to counteroffers. Is that a pay problem or a process problem?

Process, almost always, and specifically speed. Counteroffers land in the gap between a candidate deciding they might leave and your offer arriving, and that gap is something you control.

Look at your calendar before you look at your band. Count the days from final interview to written offer on both of those searches. More than five business days? That is your answer, and adding money will not fix it because the current employer can always add money too. The second thing to check is whether anybody on your side ever asked the candidate what would have to be true for them to say no to a counteroffer. That conversation, held before the offer rather than after the resignation, is worth more than another ten thousand dollars in base.

This is really one migration. Contract, contract-to-hire, or direct hire?

Contract, if the work genuinely ends. It rarely ends. What gets described as one migration usually leaves behind interfaces that need an owner for as long as both systems exist.

Be honest about which one you have. A true cutover with a defined finish, a data migration or a platform retirement, fits contract staffing and you should scope it that way rather than pretending it is permanent to make it easier to fill. If what you actually have is a permanent integration surface with a migration on the front of it, hire for the permanent version through direct hire staffing or run contract-to-hire and use the project as a long, well-paid audition. The failure mode is hiring a contractor for a migration, watching them build 15 interfaces, and letting them walk out the door with the only mental model of how any of it works.

Look for Scar Tissue

Every strong integration engineer I have placed has one story they would rather not lead with. A total that had been quietly wrong for six weeks. A file that started silently truncating after a release nobody connected it to. They found it, usually half by accident, and it rearranged the order in which they check things for the rest of their career.

That is not a line item on a resume and it does not surface in a loop built out of definitions. It surfaces when you put a broken thing in front of somebody and watch what they reach for first.

We hold 92% twelve-month retention on placements across 30-plus U.S. metros. No clever assessment sits behind that number. Our recruiters average 15 years on these desks and what they listen for is the incident, not the presentation. Run the same play with the questions above. You should. The only prerequisite is a panel that can hear the difference.

Prefer to hand it off? Talk to a KORE1 recruiter. Come with two counts and one name. How many interfaces are live, how many of those cross a company boundary, and the person who gets paged when one stops. That is enough to set a band and a sourcing plan inside one call.

Hiring one layer up, where the person owns the pattern decisions rather than the mappings? Start with integration architect staffing instead. Where the seat leans toward trading partners and B2B documents, run our EDI analyst interview questions instead. And where the real problem under this req is a synchronous call doing a job an event should be doing, read what a synchronous API actually costs in a pub/sub world before you write the job description at all.