The insurer: two conversations in discovery
“The customer asked for an AI assistant, but I first spoke to both users and compliance. I learned that safe access to data was the real problem, so I designed around that before building anything.”
By Sourav Banerjee · Last updated 11 Oct 2026 · Report an issue
A small set of real moments, each cut to one story you can tell in two minutes, with every behavioural question it can answer. Learn the stories, then pick by what the question tests.
Built from one candidate's engagements — adapt, do not recite
Start with the engagement that best fits the question, then use its detailed stories below to prepare a specific two-minute answer.
A short project to help insurance teams ask questions about sensitive company data safely.
A project to help an IT team investigate lead-routing issues without making risky automatic changes.
A small reference system used to prove that answers are safe, checked, and backed by evidence.
Stories about saying no safely, writing down known gaps, and sharing useful lessons with other teams.
You do not need a different story for every interview question. A few real moments can answer many questions. This page breaks those moments into sixteen short stories and shows you which questions each one can answer.
How to use this page: start with the short spoken answer. Then practise the full story out loud in about two minutes. In an interview, listen for what the question is really about: a setback, a difficult decision, ownership, or working with people. Choose the story that best shows that skill. You can use one story for several questions by changing the part you focus on.
Be honest. Only use results and numbers you can prove. If a story says it is partly grounded, add your own real detail before using it. Never pretend a missing detail is true.
These are anonymised example stories from someone else’s work. Use them to learn the format, not as your own answers. The final sections show which questions need your own example and how to build your own story bank.
Customer context: A short project to help insurance teams ask questions about sensitive company data safely.
Best interview use: Understanding a customer, keeping the first launch small, handling a problem, and earning trust.
“The customer asked for an AI assistant, but I first spoke to both users and compliance. I learned that safe access to data was the real problem, so I designed around that before building anything.”
“The sponsor wanted to launch everywhere at once. I explained the risk in their terms and helped them start with a smaller, safer first release that proved the value.”
“My first design failed in testing. I told the sponsor straight away, explained what was wrong, changed the design, and still delivered on time.”
“The first solution worked, but I could see where it would fail as the work grew. I delivered the short-term answer, then improved the design before it became a customer problem.”
“A platform feature we needed was not ready for the customer. I used managed tools where they fit and built the missing part myself, so the customer was not waiting on someone else’s roadmap.”
“The customer needed trustworthy answers, but the data layer was not ready. I worked with their data team and built the right foundation so every answer could be traced back to approved data.”
“The system could have used old permission data. I added one fast check and one final live check, then explained the design in simple terms so compliance could approve it confidently.”
Customer context: A project to help an IT team investigate lead-routing issues without making risky automatic changes.
Best interview use: Learning a new customer system, making safe choices, and being honest about results.
“Before building anything, I read real customer tickets. I found three different problems, not one, and built a solution that matched what the customer was actually seeing.”
“The fast demo would have let the AI change production settings on its own. I recommended a safer design where an engineer reviews every change, even though it was less flashy.”
Customer: A large Indian consumer lender. What you need to make your own: GROUNDED.
Say it in one line: "I shipped a working system, but I can't give you a client-confirmed before-and-after number, because I didn't instrument it from day one, and that's now the first thing I agree on any engagement."
What this shows the interviewer: honesty about limits, refusing to claim a number I can't prove, owning a shortfall, a lasting change in practice
Good interview questions for this story: Ownership, Standards, and Failure · Q1, Ownership, Standards, and Failure · Q5, Ownership, Standards, and Failure · Q9
Customer context: A small reference system used to prove that answers are safe, checked, and backed by evidence.
Best interview use: High standards, testing, owning mistakes, and explaining safety to non-technical people.
“For this customer, one data leak was one too many. I made that a hard release rule and used tests to prove it, instead of trusting the AI to make a security decision.”
“A security test looked like it found a leak. I treated it seriously, found that my test data was wrong, documented my own mistake, and added a check to stop it happening again.”
“The results looked perfect, but the test set was small. I chose the simpler option, and I was clear about what the numbers proved and what they did not prove.”
Customer context: Stories about saying no safely, writing down known gaps, and sharing useful lessons with other teams.
Best interview use: Making a difficult call, keeping people safe, and having impact beyond one customer.
“I shipped a useful first version with a known limit. I wrote that limit down clearly, explained the production fix, and proved exactly what the current version could do.”
“The customer wanted fully automated decisions. I tested the risky cases, showed them the evidence, and offered a safer option that kept the useful automation.”
“I noticed I was solving the same problem for different customers. I turned the useful parts into reusable tools and taught other people the pattern so they could use it too.”
If your interview loop is organised around leadership principles, this table shows where each of the thirteen below is practised, with a last row for staff-level and cross-cutting questions. Some questions appear under a principle because a question from that principle was folded into them; the worksheet shows it as an "Also asked as" line.
None of the stories above answers these honestly. Most are failure-shaped or about managing people, and a loop that hears only successes scores you as evasive. Find a real moment of your own for each.
Start with moments, not questions. Here's the method, in the order I'd do it.
Copy this template for each story:
## <Engagement>: <the moment, in a few words>
**Engagement:** <anonymised engagement>. **Grounding:** <GROUNDED, or PARTLY GROUNDED and what you still need to find>
**Say it in one line:** "<the whole story in one spoken sentence>"
- **Situation:** <what was broken, or what was at stake, in one or two sentences>
- **Task:** <what you had to achieve>
- **Action:** <what you did and why it worked: the mechanism, in two or three sentences>
- **Result:** <only what you can prove, and the limit if there is one>
**What it proves:** <three to five signals, in plain words>
**Answers:** <every question this story honestly answers>
Take a worksheet question, pick a story from its “Stories that fit” line and say it out loud in two minutes.