What the round is like
One candidate said they got stuck trying to force a design they'd memorized for something else onto the question. The interviewer's feedback was to design around the actual requirements. Start from what the system needs to do.
What people have been asked
These come up in candidates' own write-ups of their interviews. We wrote the example prompts ourselves, so the wording you get will be different.
Build a feature flag platform
Let engineers turn features on and off and roll them out to a percentage of merchants, across every service.
Flag checks happen on every request, so they need to be nearly free. A big call is library vs service: evaluating flags in a client library that pulls a snapshot means no network call per check.
How it might be asked
Design a feature flag system for Stripe's engineering organization. Engineers can turn features on or off, roll them out to a percentage of merchants or users, and keep explicit include and exclude lists. It has to work across all of Stripe's backend services.
Key concepts to know
Try this Interview
Deliver webhooks to merchants
When something happens in a merchant's account, send an HTTP request to their server.
Merchant servers are slow or down all the time, and one bad merchant can't delay everyone else.
How it might be asked
Design the system that sends webhooks to merchants. When something happens in a merchant's account, like a payment succeeding, send an HTTP request to the URL they've registered. Deliver reliably, even when their servers are slow or down.
Key concepts to know
Try this Interview
Aggregate metrics and analytics events
Take in a lot of events or metric counts from many services, roll them up, and let people query the results.
The write volume is huge, so you can't store and scan every raw event. Your data model also has to answer the product questions the interviewer asks afterward.
How it might be asked
Design a system that collects analytics events or metric counts from lots of services, aggregates them, and lets people query the results. Then use your data model to answer a few product questions.
Key concepts to know
Try this Interview
Design an API rate limiter
Limit each API key's request rate across a whole fleet of API servers.
Every server has to agree on the count without adding much latency to each request. You also need a plan for when the limiter's store is slow or down.
How it might be asked
Design a rate limiter for Stripe's API. Each user or key gets a limit, like 100 requests a minute, and it has to work across many servers. How does it scale, and what happens when the limiter's store is slow or down?
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| API design | What does the API look like, and how does it handle retries? |
| Scale | Which path runs on every request, and how do you keep it cheap? |
| Failure | What happens when a step fails halfway through? |
| Requirements | What does this specific system actually need? |
How to work through a question
- Figure out what you're building. Who's using it, what does it need to do, and what can you ignore?
- Do some rough math. How many requests, how much data, more reads or more writes? Those answers decide a lot.
- Walk through one request. Draw the simplest thing that works before you add anything fancy.
- Pick storage last. Once you know what gets read, how often and how fresh it has to be, the choice gets a lot easier.
- Then try to break it. What happens in a traffic spike? What if a server dies?
Key concepts to know
If you're rusty on any of these, start here.
- WebhooksHow one system tells another that something happened.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Rate limitingStop too much traffic with token buckets and sliding windows.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Consistency and the CAP theoremWhat happens when copies of your data can't agree.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Stream processing and windowingCount things in data that never stops coming in.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
Sources
We pulled this together from candidates' own write-ups of their interviews. They don't always agree, and things change over time.
- Blind: Stripe SWE L3 loop with AI programming round
- Blind: Bug squash and integration thread with a Stripe interviewer (2022)
- Jointaro: Staff SWE Toronto, webhook design (2023)
- Jointaro: SWE Bengaluru, currency conversion (2025)
- Jointaro: SWE Berlin, rate limiter design (2024)
- Jointaro: SWE San Francisco full loop (2025)
- 1point3acres: Onsite with email subscription, bug fix, reconciliation
Practice Loop is an independent practice tool and isn't affiliated with or endorsed by Stripe.