Financial Crime
Why Actimize Upgrade Programmes Stall at the Tuning Stage
The gap is rarely the platform itself.
Read moreHIRING GUIDE
What to Ask a PolicyCenter Developer in the First Ten Minutes
Six questions that separate configuration experience from exposure, with the answers worth listening for — and the follow-ups that catch a rehearsed reply.
In this article
The short version
- Ask about decisions, not tools. Gosu and PCF appear on every CV. What the engineer chose to do with a bespoke product model does not.
- Rating and out-of-sequence work are the fastest filters. Both are hard to describe convincingly without having done them.
- Listen for the operational consequence. Strong candidates volunteer what broke, who complained, and what they changed afterwards.
- Certifications and years tell you very little. Weight them last.
Why ten minutes is enough
A CV that says “Guidewire” can mean four very different engineers. Someone who has versioned a product model and written rate routines is not interchangeable with someone who spent two years on ClaimCenter workflow, or who completed a training course and shadowed a delivery partner.
The good news is that the distinction surfaces quickly. Configuration work on a bespoke platform leaves a trail of decisions, and decisions are difficult to describe convincingly second-hand. Ten minutes of specific questions will separate the two groups more reliably than an hour of general technical discussion.
What follows is a screening structure, not an interview script. If a candidate clears this, the technical panel is worth booking. If they do not, you have saved everybody a morning.
The six questions
1. “Walk me through the product model you worked on”
Deliberately open. You are listening for whether they can describe structure — lines of business, coverage groupings, how terms were organised, where the model was awkward and why.
What to listen for
Strong: talks about specific structural choices and their consequences. “We modelled it that way because underwriting wanted the option at the coverage level, which meant rating had to look it up twice.”
Weak: describes the Product Designer interface rather than the product. If the answer is a tour of the tool, they have used it without owning it.
2. “What happened at the last rate revision?”
Rating is the single best filter on a PolicyCenter brief, because it is where most programmes get stuck and where nobody survives without genuine involvement. Ask what changed, who asked for it, how it was tested, and what went wrong.
An engineer who has been through a revision cycle will talk about rate tables and versioning without prompting, and will usually have an opinion about how the business hands over rate change. An engineer who has not will keep the answer at the level of “we updated the rates”.
3. “Tell me about an out-of-sequence endorsement problem”
This is close to a trick question, in the useful sense. Out-of-sequence handling is where policy transaction logic gets genuinely difficult, and anybody who has maintained a live policy platform has a story. If the candidate has never encountered one, they have not worked on a book that endorses much.
4. “What did you extend, and what did you override?”
You are testing upgrade discipline. Configuration that solves today's problem the wrong way arrives later as remediation cost, and the engineers worth hiring know the difference and can explain a time they chose the harder route to stay upgrade-safe.
On a cloud programme this matters more, not less. Ask specifically what they wanted to do and could not.
5. “What broke in the last upgrade?”
Nothing exposes real ownership faster. Candidates who have lived through an upgrade wave remember the specifics — a screen that had been customised three versions earlier, a rate routine that behaved differently, a regression pack that turned out to cover less than everyone assumed.
6. “Who used what you built, and what did they complain about?”
The last question is not technical, and it is often the most revealing. Underwriters and agents are the users of a policy platform. An engineer who cannot name a complaint has either built nothing that reached production or has never been close enough to the business to hear about it.
Follow-ups that catch a rehearsed answer
Prepared candidates handle first questions well. The follow-up is where you find out whether the experience is theirs.
- “Who decided that?” People describing their own work name the decision-maker easily, including when it was them.
- “What would you do differently?” Genuine ownership comes with regrets. A flawless retelling usually means distance from the work.
- “How long did that take?” Estimates from experience are specific and slightly awkward. Estimates from imagination are round.
- “What did the tester find?” Anyone who has shipped has been handed a defect that embarrassed them.
What not to weight heavily
Weak signals
Certifications. Useful evidence of intent, almost none of delivery. Plenty of certified engineers have never taken a change through a release cycle.
Total years on the platform. Four years of the same maintenance sprint is less valuable than eighteen months across two programmes and an upgrade.
Breadth across the suite. Sometimes real, often a sign of brief exposure everywhere. Probe depth in the module you actually need.
If you only have time for two
Ask about the last rate revision, and ask what broke in the last upgrade. Between them they cover product knowledge, testing discipline, upgrade awareness and whether the candidate was close enough to production to feel the consequences of their own work.
If both answers are specific, uncomfortable in places, and include something the candidate would now do differently, you are talking to someone who has done the job.
