How Stripe interviews — correctness first

1. The shape of a Stripe loop

Stripe runs 60-minute rounds. Most other companies in this course run 45. The extra fifteen minutes matter — they exist because Stripe expects you to defend a design against failure cases the way a senior engineer at Stripe defends a code change in review. Quickly is not the point. Correctly is.

A typical onsite is four to six rounds for L3 through L6. Two coding (one of which is often a debug-existing-code round, not a leetcode round). One or two system design. One technical communication round (often called "bug bash" or "infra review"), where you read a real internal-shaped doc or PR and discuss it. One values-and-behavioral round.

The technical communication round is unusual and it's intentional. Stripe is famously a writing culture. Engineers write long internal memos before they ship. The interviewer wants to see whether you can read a doc, find the gap, and ask the right question. If you've never worked somewhere with a real RFC culture, this round is the one you should prepare for first.

2. What Stripe grades you on

The signal Stripe weights highest is one most companies don't even score for explicitly: do you expect edge cases unprompted? A weak candidate at Stripe waits for the interviewer to ask "what happens if the network times out?" A strong candidate brings up the timeout before drawing the box that has the timeout problem.

The second signal is correctness over cleverness. If you suggest a complicated optimization that saves 10ms but introduces an inconsistency window, you've lost. If you suggest the boring, slower design and explain why it never loses money, you've won.

The third is idempotency literacy. You'll be expected to use the word correctly, design for it on every mutating endpoint, and have an answer for what happens when the idempotency-key store itself fails. Most candidates have heard the word. Few can defend the design under three pushes.

3. What's different here

Longer rounds. 60 minutes instead of 45. Use them. Stripe interviewers expect a deeper third deep dive than other companies. If you've practiced for 45-minute rounds, you'll feel like you have "too much time" — that feeling means you stopped one push short.
Failure cases first. Stripe interviewers will ask "what happens if X fails" earlier and more often than other companies. Bring the failure case up before they ask. The grade improves by one notch when you do.
Money as a hard correctness constraint. Saying "eventually consistent" without naming the inconsistency window is a no-hire at Stripe in a way it isn't at, say, Meta. A user temporarily seeing the wrong like count is fine. A merchant temporarily seeing the wrong balance is not.
The double-entry ledger primitive. Stripe's whole internal accounting is double-entry. If you propose an inventory or balance system without an audit trail, you'll be pushed on it. Knowing the words debit, credit, journal entry, append-only and what they actually mean in code wins points.
No "we'd build that later" handwaves on observability. Stripe's culture is to ship the monitoring with the feature. If your design has no "and here's what we'd alert on" sentence, you skipped a graded beat.
Writing is a graded artifact. Stripe sometimes asks for a short written summary at the end of a design round — five minutes of you typing into a shared doc what you just discussed. The summary is graded. Practice writing tight prose under time pressure.

4. The level bar

How the bar shifts:

L3 (entry). Build a service with idempotency on writes. Know what a webhook is. Defend a single deep dive on the basics (database choice, simple retry logic).
L4 (mid). Two deep dives. Idempotency at the design layer (key generation, conflict handling, storage). Webhook delivery with retries. Defend against an interviewer's two pushes.
L5 (senior). Three deep dives, each surviving three pushes. The full failure model named: what fails, how you detect it, how you recover, what the user sees during the failure. Tradeoff sentences on every choice. The word ledger should appear somewhere in your design.
L6 (staff). Organization-shaped designs. How would multiple teams own this? What's the migration plan from the current state to your design? Reconciliation across asynchronous systems. The full picture, not just the happy path.

In this chapter, units 18.1 and the others target L5 to L6 by default. 18.1 (idempotency keys) is at L5 because every Stripe candidate at every level is asked about it. The rest are L6.

5. The Stripe-flavored mistakes

Watch for:

Treating idempotency as "a key in a hash table." It's a key in a hash table, plus a stored result, plus TTL, plus conflict handling on payload mismatch, plus a story for what happens when the idempotency store itself is slow. If you stop at the first thing, you'll be pushed to the second, and so on, until you run out of answers. Have all five ready.
Saying "we'd retry on failure" without specifying the retry semantics. "Exponential backoff with jitter, capped at 7 days for webhooks" is the right shape. "We'd retry" is not.
Forgetting that the consumer of a webhook is also untrusted. Merchants will write buggy webhook handlers. Stripe's design has to handle the consumer being slow, unavailable, or returning errors for days, without losing data and without retrying so aggressively that Stripe takes down the merchant.
Skipping the reconciliation step. Anything involving money has a reconciliation job somewhere — a batch that compares two sources of truth and flags discrepancies. If your design has no reconciliation, you're missing the seam that catches the bugs you didn't anticipate.
Designing the auth flow wrong. API keys, not user passwords. Webhook signatures (HMAC), not "trust the source IP." Know the conventions.
Not naming PCI scope. Anything touching the card number has a PCI compliance story. Saying "we'd store the card number encrypted in our database" without acknowledging the scope hit is a tell that you've never worked on a payment system.

6. The eight scenarios in this chapter

Each unit dissects one question end to end. The chapter covers:

18.1 Idempotency keys — the canonical Stripe question. Asked at every level.
18.2 Webhook delivery — retries, ordering, exactly-once-effect — how Stripe ships events to merchants without losing or duplicating them.
18.3 Card-on-file vault — PCI and tokenization — the merchant-side parallel to Apple Pay's device-side tokenization.
18.4 Double-entry ledger — Stripe's internal accounting. The primitive most candidates have never built.
18.5 Stripe Connect — multi-party transfers — platforms paying out to sellers. Per-account ledgers, fees, payouts.
18.6 Radar — fraud detection at transaction time — real-time scoring on every charge, fail-closed semantics.
18.7 Take-home: rate-limited API gateway with idempotency — code task. Build, test, ship.

7. The next page

The first scenario: idempotency keys. The single most-asked question in the Stripe loop, at every level.