Working code over whiteboard algorithms, plus API design and money-movement correctness at a genuinely high bar.
Stripe deliberately avoids whiteboard algorithm puzzles in favour of rounds that resemble the job. You will be given a real codebase or a real API and asked to make something work: implement a feature, fix a failing integration, handle the error cases properly. Tests, error handling and reading unfamiliar code quickly all count.
The integration round is the one candidates most often underestimate. You are handed API documentation and asked to build against it under time pressure. What is being scored is how you handle the unhappy path - a rate limit, a webhook that arrives twice, an ambiguous timeout - not how fast you can hit the happy path.
Money-movement correctness underpins the design round: idempotency, exactly-once effects on top of at-least-once delivery, and reconciliation. Stripe expects the same rigour it sells to its customers.
60 min
Implement a feature in a real codebase. Tests and error handling count.
60 min
Build against a real API under time pressure. Unhappy paths are the point.
60 min
Payment flow correctness, idempotency, webhook delivery, reconciliation.
45-60 min
Find and fix a defect in code you have never seen before.
45 min
Ownership, user focus and collaboration.
Largely no. The rounds are practical - implement a feature, integrate against an API, debug unfamiliar code. Preparation that consists only of algorithm drills transfers poorly to this loop.
Practise reading API documentation fast and handling the unhappy paths deliberately: rate limits, duplicate webhook deliveries, ambiguous timeouts, partial failures. Those cases are the scoring criteria, not the happy path.
No, it is relocated. The practical rounds are tightly timed and scored on working software, error handling and tests, which many candidates find less forgiving than a whiteboard round where partial reasoning earns credit.
Practise the rounds Stripe actually runs, and get scored on where you stand.