What do interviewers evaluate in API Craft & Operational Excellence questions?

Interviewers listen for signals like: Have you designed an interface others depend on - and did you design for failure modes, retries, and evolution before shipping? Have you carried a breaking change or deprecation without breaking consumers - migration tooling, dual-running, staged cutover? What did you do when you got a contract wrong?

gitGood.dev

StripeAdvanced Premium

API Craft and Operational Excellence (Stripe Culture)

Stripe treats APIs as products and reliability as a feature - backward compatibility, idempotency, and boring operational rigor. Interviewers test whether you've built things other people could bet on.

About this theme

Stripe's engineering reputation rests on two intertwined disciplines. The first is API craft: Stripe treats its API as the product, with the care that implies - resource shapes designed to age well, errors designed to be diagnosed, idempotency keys so retries are safe, and a backward-compatibility posture so strong that API versions from over a decade ago still work. The second is operational excellence: when your product moves money, 'mostly works' is a defect, and the company's writing about itself emphasizes reliability as a feature users buy. These are cultural values precisely because they're expensive - compatibility constrains every future change, and operational rigor is invisible when it works. Behavioral rounds probe whether you've actually paid these costs, not whether you can recite the vocabulary. On the craft side: have you designed an interface that others depend on, thought about its failure modes and evolution before shipping, and carried a deprecation without breaking consumers - the strongest signal being what you did when you got a contract wrong and had to fix it without punishing the people who'd built on it. On the operations side: have you owned a service in production in the full sense - error budgets, on-call, postmortems that changed something, the graph you checked because you were accountable, not because someone asked. Interviewers listen for the tell that separates builders from operators-of-what-they-build: whether your stories end at 'shipped' or at 'ran reliably for years.'

What interviewers are evaluating

→Have you designed an interface others depend on - and did you design for failure modes, retries, and evolution before shipping?
→Have you carried a breaking change or deprecation without breaking consumers - migration tooling, dual-running, staged cutover?
→What did you do when you got a contract wrong? Fixing your own API mistake without punishing consumers is the strongest craft signal.
→Do your stories end at 'shipped' or at 'ran reliably' - do you know your service's failure modes, error budget, and worst incident?
→Has a postmortem you ran or wrote actually changed something durable - a design, an alert, a process?
→Do you treat reliability as a feature with a cost you've argued for, or as a tax someone else should pay?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Walk me through an API or interface you designed that other teams or customers built on. What did you get right and wrong?
?Tell me about deprecating or changing an interface that had real consumers. How did you avoid breaking them?
?Describe a design decision you made specifically so the system would fail safely.
?Tell me about the worst incident on a system you owned. What changed because of it?
?How have you made a service you owned more reliable? How did you know it was working?
?Tell me about a time you argued for reliability or compatibility work over a feature.
?What's a contract you shipped and later regretted? What did you do about it?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: fixing my own broken contract without breaking anyone

Prompt: "What's a contract you shipped and later regretted? What did you do about it?"

Situation: Early at a B2B platform, I designed and shipped our public payouts API. Under launch pressure I made a contract mistake: the 'status' field conflated two different concepts - whether we had accepted the payout instruction, and whether the bank had settled it. It worked fine in the demo. Eight months later we had 300+ integrations, and the flaw was surfacing as real damage: customers were treating 'completed' (we sent it) as 'settled' (money arrived), and reconciling their books wrong. One customer's finance team closed a quarter against numbers that were off by a day of float.
Task: The right contract required a semantic change to a field 300 integrations already depended on. I owned both the mistake and the fix, and the bar I set was Stripe-shaped: no existing integration breaks, no customer is forced to migrate on our timeline, and the new contract is one we can keep for a decade.
Action: I treated the fix as a product with its own design review, not a patch. First, I wrote the new contract properly - separate 'instruction_status' and 'settlement_status' fields with a documented state machine, plus a 'settled_at' timestamp - and circulated the design to five of our highest-volume integrators for written feedback before building anything; two of them caught an ambiguity in the returned-payout path I'd have shipped wrong a second time. Second, I versioned rather than mutated: existing API versions kept the old field with its old semantics forever, and the new fields shipped in a new version, with per-account version pinning so nobody moved until they chose to. Third, I built the migration path as if migration were the product: a side-by-side response diff tool in the dashboard sandbox, a migration guide that showed the exact code change for our four biggest SDK languages, and dual-emission so integrators could log both versions in production before switching. Fourth, the operational half: I added a reconciliation alert on our side that flagged any account whose polling pattern suggested they were still misreading settlement timing, and we proactively contacted the twelve accounts it caught. I also wrote the internal postmortem on how the flawed contract got shipped, which produced a durable rule: every new public field gets a 'what will this mean in five years, and what does it NOT mean' section in API review.
Result: Over 14 months, 280 of 300+ integrations migrated voluntarily - zero forced, zero broken; the long tail stayed safely on the pinned old version, which we still honor. Settlement-related support tickets and the misreconciliation reports went to zero among migrated accounts. The customer whose quarter-close had been wrong sent our CEO an unprompted note about the migration experience. Internally, the field-semantics review rule caught two similar conflations in other teams' API proposals within the next year - the postmortem outlived the incident. And the payouts API contract as redesigned hasn't needed a breaking change since.

Why this works

What makes this strong: (1) it's the hardest craft story - fixing your own contract mistake - told with full ownership and no deflection to launch pressure; (2) the mechanics are the actual discipline Stripe practices: versioning with pinning instead of mutation, consumer feedback before build, migration tooling as a product, compatibility honored indefinitely; (3) the operational half completes it - proactive detection of still-affected accounts and a postmortem that changed the review process durably. 'No forced migration, zero broken integrations' is the sentence the interviewer is listening for.

WEAK

Weak: 'we versioned it' without the care

Prompt: "Tell me about deprecating or changing an interface that had real consumers. How did you avoid breaking them?"

Situation: Our internal user-service API had a lot of legacy cruft and my team wanted to clean it up with a v2.
Task: I was in charge of shipping v2 and getting teams off the old version.
Action: We designed v2 to be much cleaner - better naming, more consistent responses. We announced it in the engineering all-hands and gave everyone a quarter to migrate, with the deprecation date in the announcement. I wrote a migration doc mapping old endpoints to new ones. Most teams moved over in time; a few didn't, and when we turned off v1 on the announced date their stuff broke, but honestly they'd had a full quarter and multiple reminders - at some point teams have to take responsibility for their own dependencies. The breakages got fixed within a couple of days.
Result: We got everyone onto v2 and the codebase is a lot cleaner. There was some grumbling about the teams that broke, but the deprecation date was communicated clearly, so I think we handled it by the book.

Why this is weak

Why weak: (1) 'they'd had a quarter' reveals the mindset - the burden was pushed entirely onto consumers, and breaking them on schedule is treated as their failure rather than the deprecation's; craft cultures measure a deprecation by consumer outcomes, not by whether the announcement was sent; (2) no mechanisms beyond a doc and a date - no usage telemetry to see who hadn't moved, no dual-running, no outreach to the stragglers before the cutoff, all of which would have cost little; (3) 'cleaner naming' as the driver means real breakage was spent on aesthetic improvement - a tradeoff the candidate never examines. 'By the book' here means the book was the problem.

Common pitfalls

×Stories that end at 'shipped.' If you can't describe the system's life in production - incidents, error budget, evolution - you built it but never owned it.
×Deprecations 'handled' by announcement - a date and a doc, then blaming consumers who broke. Craft is measured in consumer outcomes.
×No regretted contract. Everyone who has designed real interfaces has one; claiming otherwise reads as either inexperience or lack of reflection.
×Reciting idempotency and versioning vocabulary without a story where you paid their cost - the words are cheap, the constraint is the signal.
×Postmortems that produced documents instead of changes. 'We wrote it up' without a durable design, alert, or process change is theater.
×Treating reliability work as a tax imposed on you rather than a feature you've argued for on its merits.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→Expect 'what did you get wrong?' about any interface you praise yourself for - lead with the regretted contract before they ask; it's the strongest material.
→If asked 'how do you know it was reliable?', answer with numbers you owned - error budgets, p99s, incident counts - not adjectives.
→If asked 'what would you change in v2, and how would you ship it?', walk the actual mechanics: versioning, pinning, dual-emission, migration tooling, telemetry on stragglers.
→If asked about your worst incident, structure it like a postmortem - impact, cause, fix, and specifically what's durably different now.
→If asked 'when is a breaking change acceptable?', show the judgment: when the old contract is actively harming users, and even then with the cost absorbed by you, not them.

Related behavioral themes

Insist on the Highest Standards

Amazon LP

Interviewers screen for a high bar you raised for others - not perfectionism on your own work. The trick is showing high standards without tanking delivery.

Dive Deep

Amazon LP

Leaders operate at all levels. The interviewer is testing whether you actually understand your own systems - or whether you summarize what your team built.

Users First

Stripe

Stripe's users are developers, and 'users first' means treating integration friction, confusing errors, and bad docs as product defects. Interviewers test whether you've genuinely served a technical audience.

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →

StripeAdvanced Premium

API Craft and Operational Excellence (Stripe Culture)

About this theme

What interviewers are evaluating

→Have you designed an interface others depend on - and did you design for failure modes, retries, and evolution before shipping?
→Have you carried a breaking change or deprecation without breaking consumers - migration tooling, dual-running, staged cutover?
→What did you do when you got a contract wrong? Fixing your own API mistake without punishing consumers is the strongest craft signal.
→Do your stories end at 'shipped' or at 'ran reliably' - do you know your service's failure modes, error budget, and worst incident?
→Has a postmortem you ran or wrote actually changed something durable - a design, an alert, a process?
→Do you treat reliability as a feature with a cost you've argued for, or as a tax someone else should pay?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Walk me through an API or interface you designed that other teams or customers built on. What did you get right and wrong?
?Tell me about deprecating or changing an interface that had real consumers. How did you avoid breaking them?
?Describe a design decision you made specifically so the system would fail safely.
?Tell me about the worst incident on a system you owned. What changed because of it?
?How have you made a service you owned more reliable? How did you know it was working?
?Tell me about a time you argued for reliability or compatibility work over a feature.
?What's a contract you shipped and later regretted? What did you do about it?

Sample STAR answers

Both strong and weak examples, with notes on what makes each work (or fail). Read the weak examples carefully - the patterns they show up are the ones interviewers are trained to spot.

STRONG

Strong: fixing my own broken contract without breaking anyone

Prompt: "What's a contract you shipped and later regretted? What did you do about it?"

Situation: Early at a B2B platform, I designed and shipped our public payouts API. Under launch pressure I made a contract mistake: the 'status' field conflated two different concepts - whether we had accepted the payout instruction, and whether the bank had settled it. It worked fine in the demo. Eight months later we had 300+ integrations, and the flaw was surfacing as real damage: customers were treating 'completed' (we sent it) as 'settled' (money arrived), and reconciling their books wrong. One customer's finance team closed a quarter against numbers that were off by a day of float.
Task: The right contract required a semantic change to a field 300 integrations already depended on. I owned both the mistake and the fix, and the bar I set was Stripe-shaped: no existing integration breaks, no customer is forced to migrate on our timeline, and the new contract is one we can keep for a decade.
Action: I treated the fix as a product with its own design review, not a patch. First, I wrote the new contract properly - separate 'instruction_status' and 'settlement_status' fields with a documented state machine, plus a 'settled_at' timestamp - and circulated the design to five of our highest-volume integrators for written feedback before building anything; two of them caught an ambiguity in the returned-payout path I'd have shipped wrong a second time. Second, I versioned rather than mutated: existing API versions kept the old field with its old semantics forever, and the new fields shipped in a new version, with per-account version pinning so nobody moved until they chose to. Third, I built the migration path as if migration were the product: a side-by-side response diff tool in the dashboard sandbox, a migration guide that showed the exact code change for our four biggest SDK languages, and dual-emission so integrators could log both versions in production before switching. Fourth, the operational half: I added a reconciliation alert on our side that flagged any account whose polling pattern suggested they were still misreading settlement timing, and we proactively contacted the twelve accounts it caught. I also wrote the internal postmortem on how the flawed contract got shipped, which produced a durable rule: every new public field gets a 'what will this mean in five years, and what does it NOT mean' section in API review.
Result: Over 14 months, 280 of 300+ integrations migrated voluntarily - zero forced, zero broken; the long tail stayed safely on the pinned old version, which we still honor. Settlement-related support tickets and the misreconciliation reports went to zero among migrated accounts. The customer whose quarter-close had been wrong sent our CEO an unprompted note about the migration experience. Internally, the field-semantics review rule caught two similar conflations in other teams' API proposals within the next year - the postmortem outlived the incident. And the payouts API contract as redesigned hasn't needed a breaking change since.

Why this works

WEAK

Weak: 'we versioned it' without the care

Prompt: "Tell me about deprecating or changing an interface that had real consumers. How did you avoid breaking them?"

Situation: Our internal user-service API had a lot of legacy cruft and my team wanted to clean it up with a v2.
Task: I was in charge of shipping v2 and getting teams off the old version.
Action: We designed v2 to be much cleaner - better naming, more consistent responses. We announced it in the engineering all-hands and gave everyone a quarter to migrate, with the deprecation date in the announcement. I wrote a migration doc mapping old endpoints to new ones. Most teams moved over in time; a few didn't, and when we turned off v1 on the announced date their stuff broke, but honestly they'd had a full quarter and multiple reminders - at some point teams have to take responsibility for their own dependencies. The breakages got fixed within a couple of days.
Result: We got everyone onto v2 and the codebase is a lot cleaner. There was some grumbling about the teams that broke, but the deprecation date was communicated clearly, so I think we handled it by the book.

Why this is weak

Common pitfalls

×Stories that end at 'shipped.' If you can't describe the system's life in production - incidents, error budget, evolution - you built it but never owned it.
×Deprecations 'handled' by announcement - a date and a doc, then blaming consumers who broke. Craft is measured in consumer outcomes.
×No regretted contract. Everyone who has designed real interfaces has one; claiming otherwise reads as either inexperience or lack of reflection.
×Reciting idempotency and versioning vocabulary without a story where you paid their cost - the words are cheap, the constraint is the signal.
×Postmortems that produced documents instead of changes. 'We wrote it up' without a durable design, alert, or process change is theater.
×Treating reliability work as a tax imposed on you rather than a feature you've argued for on its merits.

Follow-up strategies

Interviewers will probe. Be ready for the follow-up questions that test the depth of your story.

→Expect 'what did you get wrong?' about any interface you praise yourself for - lead with the regretted contract before they ask; it's the strongest material.
→If asked 'how do you know it was reliable?', answer with numbers you owned - error budgets, p99s, incident counts - not adjectives.
→If asked 'what would you change in v2, and how would you ship it?', walk the actual mechanics: versioning, pinning, dual-emission, migration tooling, telemetry on stragglers.
→If asked about your worst incident, structure it like a postmortem - impact, cause, fix, and specifically what's durably different now.
→If asked 'when is a breaking change acceptable?', show the judgment: when the old contract is actively harming users, and even then with the cost absorbed by you, not them.

Related behavioral themes

Insist on the Highest Standards

Amazon LP

Interviewers screen for a high bar you raised for others - not perfectionism on your own work. The trick is showing high standards without tanking delivery.

Dive Deep

Amazon LP

Leaders operate at all levels. The interviewer is testing whether you actually understand your own systems - or whether you summarize what your team built.

Users First

Stripe

Companies that test this theme

Stripe

Backend Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. The AI mock interview probes your stories the way real interviewers do.

Start an AI mock interview →