Guidewire Developer Interview Questions 2026

Last updated: September 26, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

Useful Guidewire developer interview questions make the candidate read Gosu, trace a single commit through bundles and pre-update rules, and explain what a messaging destination does when one claim’s message fails and the retries start. Definitions of PCF files and typelists can stay on the phone screen. The panel is for hearing about a commit the candidate caused, a message they got moving again, and a duplicate they had to clean up, with dates attached.

In April a regional auto and farm insurer in Des Moines, Iowa, hired a ClaimCenter developer who had worked on two implementations and knew the platform better than most of the people interviewing him. He could explain how a PCF file binds to an entity, when a Gosu enhancement beats a utility class, and how a typelist gets extended. Clean answers, every one. The vote was unanimous.

Five weeks later a hailstorm crossed Polk and Dallas counties on a Tuesday afternoon. The carrier opened a catastrophe in ClaimCenter so the storm’s losses could be reported to its reinsurers as one event, and the new developer was asked to write a nightly batch process that would attach the open Iowa claims to it.

He wrote it the way a good Java developer writes a loop over a list. One query that pulled every claim, a filter in memory for open claims with an Iowa loss location, and a single bundle holding all of them, roughly 31,000 claims. The first night the job ran for fifty minutes and then failed at commit with a ConcurrentDataChangeException, because adjusters working the storm had edited a few hundred of those same claims while the job was running, and the whole transaction rolled back. Nothing was saved. The second night went the same way. So did the third.

For eight days not one claim was tagged. The carrier’s first loss report to its reinsurers went out late and incomplete, and an outside Guidewire consultant billed a little over $23,000 to rebuild the job as a work queue that processed each claim in its own small bundle. It has run cleanly every night since.

He was not a weak developer. He had simply never worked through a catastrophe, and nothing in the interview gave him a reason to say so.

That is the trouble with most Guidewire developer interview questions in circulation. Search for them and you get long lists written for candidates studying the night before. What is Gosu? What does BillingCenter do? What is a PCF? The answer is printed right under every question. Those lists test recall, and recall is not what failed in Des Moines. A bundle far too big for a night when people were using the system is what failed.

Carrier IT searches have been on my desk at KORE1 since before most of our insurance clients had heard the phrase Guidewire Cloud. These days most of them come to us through our insurance IT staffing practice, and the urgent ones tend to follow a week a lot like the one in Des Moines.

About my own stake in this. KORE1 earns a fee when a carrier hires a developer we introduced. The Des Moines team did not need us for the next one. Their claims director knew a ClaimCenter developer from a previous job, the panel screened her with the questions below, and she started in June. The questions do the same work no matter who sends you the resume.

What the Job Touches Inside InsuranceSuite

A Guidewire developer writes and maintains the custom code inside Guidewire InsuranceSuite, the core platform many property and casualty insurers use to run policy, billing, and claims. Most of that code is Gosu classes and rules, PCF screens, data model extensions, batch processes, and the integrations that move policy and claim data to other systems.

Gosu is the part people outside the platform underestimate. Guidewire describes it as the open-source language behind more than 700 P&C core implementations, and because it runs on the JVM, a strong Java developer can read it on the first day. Writing it well takes longer. Property paths in Gosu return null instead of throwing, blocks and enhancements change where logic lives, and every entity a developer touches belongs to a bundle, whether or not anyone is thinking about that at the time.

Most carriers run some mix of PolicyCenter, BillingCenter, and ClaimCenter, the policy, billing, and claims applications. The questions below are not sorted by application. On purpose. A bundle commits the same way in all of them. A stuck message blocks the same way too. Why carriers keep adding these seats at all is its own story, told in our look at insurtech hiring trends for 2026, so I will leave it there.

The rest of the search lives elsewhere on our site. Scoping the seat and running the process are covered in our guide to hiring a Guidewire developer. What the posting should say is in our Guidewire job posting template, and pay by level and city is in the Guidewire developer pay guide. This page is only the technical interview.

Fourteen Lines of Gosu, Before Anything Else

I ask clients to open the technical round with code instead of ending with it. Put the snippet below on the shared screen, tell the candidate it came from a real carrier and has been lightly simplified, and ask what they would write in the code review. Then stop talking.

uses gw.api.database.Query
uses gw.transaction.Transaction

function tagHailClaims(cat : Catastrophe) {
  var openClaims = Query.make(Claim).select()
      .where(\ c -> c.State == ClaimState.TC_OPEN
                and c.LossLocation.State == State.TC_IA)
  Transaction.runWithNewBundle(\ bundle -> {
    var hail = bundle.add(cat)
    for (c in openClaims) {
      bundle.add(c).Catastrophe = hail
    }
  })
}

Most of what is wrong with it sits on two lines.

Line 6 is the expensive one. By the time where() runs, select() has already asked the database for every claim the carrier has. Open or closed. Every state. The block then filters them one at a time inside the application server, which is a bit like asking the records room to deliver every file in the building so you can pick out the Iowa ones yourself. That filter belongs in the query, as compare() calls on the claim state and the loss location, so the database throws away the rows nobody wanted. Anyone who has tuned a Guidewire batch job spots it before they finish reading. One candidate this summer read line 6 out loud, stopped, and said “oh, no” before she said anything else. The panel liked her immediately. So did I.

The single bundle is the second problem, and it is the one that cost Des Moines eight days. When the block that starts on line 8 finishes, everything in that bundle commits as one database transaction. One. If anyone else changed even a single one of those claims after the job read it, the commit fails and every other change goes down with it. Batch work over thousands of records belongs in a work queue, where each item gets its own bundle, or at the very least in small chunks that commit separately. A smaller problem hides in the same block, too. Nothing checks whether a claim already has the catastrophe on it, so a rerun rewrites every row from the top, which most people discover at six in the morning with a claims VP on the phone.

Then there is the trap. A developer who comes from Java will often point at c.LossLocation.State and call it a NullPointerException waiting to happen. In Gosu it is not. A property path like that evaluates to null when LossLocation is null, and the comparison quietly comes back false. So the candidate who knows this has written a lot of Gosu, and the candidate who adds three defensive null checks has mostly written Java. Not disqualifying. It tells you where the ramp starts, that is all.

Give it ten minutes. Strong candidates find the first two problems fast and then start asking questions back. How many claims does the carrier carry? Do adjusters work nights during a catastrophe? Honestly, those questions are the best part of the exercise, and I would take the candidate who asks them and misses the trap over the one who finds the trap and asks nothing.

Questions About What Happens at Commit

Everything a Guidewire developer writes ends, sooner or later, with a bundle being committed. These two questions find out whether the candidate knows what that moment costs.

Your job has to update 31,000 claims. How many bundles does it use, and why?

Not one. That is the floor, and most experienced candidates get there quickly.

Listen for what comes next. Guidewire checks at commit time whether another transaction changed a row after this one read it, and if so the commit fails, which is where most developers first meet the ConcurrentDataChangeException. The bigger the bundle and the longer it stays open, the more likely that collision gets, and when it happens everything in the bundle is lost with it. A strong candidate talks about a work queue, where a writer finds the claims and workers process each one in its own transaction. Then they talk about the claims that fail anyway. Some always do. The best ones raise rerun safety on their own.

The weak answer is “wrap it in a try-catch and retry.” Retrying a 31,000-claim commit while adjusters are working those same claims reproduces the failure. Every time.

Walk me through everything that runs between your code committing and the row being saved.

This one sorts people fast.

A complete answer covers roughly this. Pre-update rules run first, against the entities in the bundle that changed, and because they are allowed to change data they come before validation. Validation rules run next. Then the database write happens in a single transaction, and any messages created by Event Fired rules are saved inside that same transaction, so a change that rolls back never leaves a message behind for some downstream system to act on.

Candidates who have looked after a ClaimCenter or PolicyCenter configuration for a few years add the part that matters for performance. Pre-update rules run on every save, for every user. Every one. A rule that runs a query for each exposure on a claim makes every adjuster’s save slower, all day long, and nobody files a ticket because each individual save is only a little slow. Ask whether they have ever moved logic out of a pre-update rule, and what made them do it.

A weak answer describes one step called “save.” A worrying answer puts validation first.

Questions for the Query and the Screen

An adjuster’s activity list takes nine seconds to open. Where do you look first?

A workers’ compensation carrier in Milwaukee lived with exactly this for most of last year. Adjusters opened their desktop activity list forty or so times a day, and every time it took eight to ten seconds. The cause turned out to be one column. Someone had added a “days since last claimant contact” column to the list. Useful number. It was computed by a Gosu property that queried the claim’s notes, once per row, so four hundred activities meant four hundred queries, and because PCF expressions can be evaluated more than once while a page renders, the real count was higher than that. Fifty-one adjusters, forty opens a day, eight seconds each. Somebody finally did the arithmetic in March. Roughly ninety-five hours a month, spent watching a loading indicator.

Strong candidates open the Guidewire Profiler, which shows how many queries a page fired, before they touch any code. That order matters. Then they move the per-row work out, either into one query for the whole list or into a stored field that gets updated when a note is saved. The ones with real list-view experience also ask how many rows the list shows by default. Paging often fixes half the problem for free.

“Add an index” is the answer to worry about. The query was already fast. There were just four hundred of them.

When would you use AtMostOneRow instead of FirstResult?

Short question. Revealing answer.

FirstResult asks for the first row, and to make “first” mean something the query is typically ordered by ID, which on a large table can mean far more reading than anyone expected. AtMostOneRow says you expect one row or none and throws if the database finds more, which doubles as a free data-quality check. A candidate who has been burned by FirstResult on a big table explains it in two sentences. One who has not says they are the same thing.

Questions About the Message That Never Left

One account’s message has been in error for nine days. What else is stuck behind it?

A personal lines carrier in Columbus, Ohio, found out the expensive way. Its PolicyCenter instance sends policy changes to a print-and-mail vendor through a messaging destination. In February one account’s message failed because the vendor rejected the mailing address, an apartment number longer than the vendor’s field allowed, and every later message for that account waited behind it. The destination kept sending for every other account, so the dashboard looked healthy. Nobody looked closer. Not for nine days. One of the waiting messages was a nonrenewal notice, and it reached the policyholder after the state’s notice deadline had passed, so the carrier had to renew a policy it had already decided to drop.

That behavior is by design. Guidewire’s own glossary defines safe-ordered messages as messages grouped by their primary object for each destination and sent in creation order, with delays or errors blocking further sending for that same primary object on that same destination. In PolicyCenter the default primary object is the account. In ClaimCenter it is the claim.

So the right answer is every later message for that account, on that destination, and nothing else. Strong candidates then ask what is watching the error count per destination. They also know the difference between retrying a failed message after fixing the data and skipping it, which throws the message away and leaves the vendor’s copy of the account out of step with PolicyCenter. The weak answer is “the whole queue is stopped.” It is not. And a developer who believes it is will never go looking for the one account that actually is stuck.

A call fails on a claimant’s medical bill. What does your integration write to the log?

Plenty of developers have never been asked this one. That is the reason to ask it.

Claim payloads carry names, dates of birth, policy numbers, diagnoses, and bank details. Regulators noticed a while ago. The NAIC’s Insurance Data Security Model Law dates to October 2017, and it makes licensed insurers keep a written information security program for exactly this kind of nonpublic information. In the cases it covers, an insurer has 72 hours from determining that a cybersecurity event occurred to notify the insurance commissioner. By August 2025 the NAIC counted 28 jurisdictions that had implemented it, Iowa, Ohio, Alabama, and Wisconsin among them. An error log stuffed with claimant payloads and readable by everyone with support access turns any later breach of that log into a far bigger one.

A good answer logs the message ID, the public ID of the claim or policy, the destination, and the error, and it leaves the payload out or masks it. The best answers mention checking where the logs actually end up and who can read them. The worrying answer is “we log the whole request so we can debug it.” Honest, at least.

Questions About the Second Copy

The FNOL call timed out and the caller retried. How many claims exist now?

A regional carrier in Birmingham, Alabama, takes first notice of loss from a partner’s intake app through Cloud API. During a line of spring storms ClaimCenter slowed down, the partner’s client gave up after thirty seconds, and it retried automatically, even though ClaimCenter had already created the claim on the first attempt. Over one weekend that produced 212 duplicate claims. Two hundred and twelve. Some of the duplicates were assigned to a second adjuster, and on one loss both adjusters authorized a rental car. Two claims supervisors spent most of a week cleaning it up.

The strong answer names the GW-DBTransaction-ID header. According to Guidewire’s Cloud API documentation, the caller sends a globally unique transaction ID of up to 128 characters, Cloud API records it, and if the same ID arrives again the call is rejected with a 400 status and an AlreadyExecutedException. The candidate worth hiring knows the fine print as well. It only works for calls that commit once, and only if the commit happens before any other side effect, such as a notice going out to an external system. The retry does not get the original response back, either. It gets the 400, so the caller has to go and find the claim the first request created.

Weak candidates say the partner should raise its timeout. That makes duplicates rarer. It does not make them impossible.

Your consumer processed the same App Event twice. Whose bug is that?

The consumer’s, and someone who has built on App Events should say so without hesitating. Guidewire’s integration training material states that App Events are delivered at least once and are safe-ordered by the primary object they relate to. At least once means sometimes twice. Safe-ordered by primary object means two events about the same claim arrive in order, while two events about different claims can arrive in any order at all.

A good answer puts a duplicate check wherever the event is consumed, keyed on something that identifies the event, and treats ordering as per claim or per policy, never across the whole feed. Candidates who have written Integration Gateway routes, which run on Apache Camel outside InsuranceSuite, sometimes name Camel’s Idempotent Consumer pattern outright. I like hearing it. I do not require it. The answer to be wary of is “Guidewire should guarantee exactly once.” It does not, and it says so in writing.

The Question About Base Files

Why does every field your team added end in _Ext?

So it never collides with something Guidewire adds to the base configuration in a later release. That is the whole answer, and it takes one sentence.

The follow-up is where you learn something. Ask what happens when somebody edits a base PCF file or a base rule directly instead of extending it. The honest answer is that the change has to be merged again, by hand, at every upgrade after that, and on Guidewire Cloud the updates keep arriving several times a year. A candidate who has carried a heavily modified configuration through an upgrade will usually tell you, with some feeling, how many changed base files turned up that nobody remembered touching. Those candidates tend to be careful. Hire for careful.

A Cheat Sheet for the Panelists Who Do Not Write Gosu

Claims managers, underwriting leads, and business analysts often sit on these panels, and they should, since they will live with whatever the developer builds. They do not need to grade Gosu. They need to know what the words mean when a candidate uses them. If the program is short on requirements people too, that is a separate search, and our business analyst staffing team runs it on its own track.

A candidate who uses three or four of these words correctly without prompting has very likely shipped Guidewire code. A candidate who uses none of them deserves the question again in plainer language before anyone decides anything. Some very good developers are terrible at vocabulary. I have placed a few.

Second Thoughts From the Debrief

Does it matter whether the candidate writes GUnit tests?

It matters more than most panels assume, because a developer who tests Gosu with GUnit has usually been burned by an untested change and learned to build test data instead of borrowing it.

Ask for one example and listen for the details. A good one sounds like a test for a work queue’s processing logic, the builder calls that created a claim with two exposures and a reserve line, and the bug it caught before a release went out. A weak one sounds like “QA handled that.” Somewhere in between is the candidate who wrote tests on one project because the lead insisted and has not written one since. Ask them why not. The answer is usually about deadlines, which is honest, and it tells you what they will do under yours.

We run on Guidewire Cloud. Do the self-managed questions still apply?

Bundles, rules, and safe-ordered messaging behave the same way on Guidewire Cloud, so most of this list carries over unchanged.

What moves is the integration code. Guidewire’s own training material describes integration logic moving out of Gosu inside the InsuranceSuite applications and into Integration Gateway. For a Cloud seat, then, lean harder on the Cloud API and App Events questions, and push on the base file question, because on Cloud the upgrades arrive on Guidewire’s calendar rather than yours.

How many of these fit in a one-hour panel?

Five, plus the code exercise, as long as the panel resists explaining the answers.

Both commit questions, one integration question that fits the seat, and the base file question. That is the hour.

How much should a junior Guidewire developer get right?

Short answer: the code exercise and the first commit question, at least in part.

Someone with a year on a Guidewire project should catch the in-memory filter and know that every entity lives in a bundle. The messaging and Cloud API questions are fair to ask, but do not hold a blank against them. What you want from a junior developer is curiosity, and the clearest sign of it is whether they asked what the batch job was for.

Should candidates see the questions ahead of time?

Send the topics, not the questions.

Tell them the panel will cover commits and bundles, one integration scenario, and a short piece of Gosu to review. Good candidates prepare by remembering real incidents, which is exactly what you want to hear about. Hand over the exact wording and you mostly learn who stayed up rehearsing. Which is a skill, I suppose. Not this one.

Start With the Commit

She started in June, the developer Des Moines hired the second time around. The fourteen lines took her under a minute. Then she put a question to the panel, how many adjusters work nights during a catastrophe, and nobody in the room could answer it. They went and found out. The work queue now kicks off at four in the morning, the one hour the claims floor is actually empty when a storm comes through.

I keep coming back to that question of hers. It was not on anybody’s list. It came from someone who had watched a batch job fight live users for the same rows, and hearing it cost the carrier nothing. A lot of what a Guidewire interview can tell you sits right there, in what the candidate asks after seeing your code.

We do this with carriers a few different ways. Sometimes we sit in on the first panel and read the fourteen lines with the team. Sometimes we run the early rounds ourselves and send over only the people who found the bundle. Our insurance recruiting team can tell you which fits your search. Upgrade pushes and fixed-scope integration builds tend to come through our contract staffing desk, often as contract Guidewire developers brought in for a release or a cutover, and the developer who will keep your configuration healthy for years is usually a direct-hire search.

When the systems integrator is close to leaving and the carrier needs its own people on the code, our recruiters who staff Guidewire teams around the integrator’s exit run that search. Carriers in Illinois can work with our Chicago Guidewire practice directly. KORE1 has filled technical seats through our IT staffing services since 2005. A year after each start date, 92 percent of those people are still in the job.