Stripe Software Engineer VO Interview Experience (2026) - Fraud Sliding Window & Refund Service Design, Offer

My first instinct was the naive scan: for each transaction, sweep every earlier transaction by the same user and count how many fell in the window. I started coding that before I realized it was quadratic and obviously too slow at production transaction volume. The interviewer did not jump in, which made me suspicious. I paused, and said out loud that I wanted to switch approaches.

The clean answer is a per-user deque of timestamps. Each time a transaction arrives, I push its timestamp onto that user's deque, then pop from the front while the head is older than 60 seconds before the current time. The size of the deque after pruning is exactly the count of transactions in the current rolling window. If that count crosses three, the user is flagged. That gives amortized O(1) per event, with memory proportional to the number of active users plus their windowed transaction counts.

The follow-up was a classic one: what if the stream is distributed across several workers? I talked about sharding by user id so each user's state stays local to one worker, with a stateless router upstream hashing on user id . The interviewer pushed on clock skew. For that I suggested using the event timestamp embedded in the transaction rather than worker wall-clock time, and accepting a small bounded out-of-order tolerance by delaying output by a few seconds.

Round 2: System Design — Payment Refund Service (20 min)

Problem: Design a refund service that supports high-concurrency refund requests, guarantees idempotency, and reaches eventual consistency with the downstream ledger. The user can click the refund button multiple times, the network can drop, and multiple refunds on the same charge must never double-debit the merchant.

I opened far too naively. I sketched a simple POST /refunds endpoint that wrote a row to a refunds table and then called the ledger. The interviewer listened politely and then asked "what happens if the network blips between the refund write and the ledger call." I realized I had skipped the whole point of the question.

I backed up. The right shape is a refund request landing in a durable queue rather than being applied synchronously. The endpoint accepts an idempotency key provided by the client, persists the request row, returns 202 Accepted , and enqueues a refund job. A worker consumes the queue, calls the ledger with the same idempotency key, and updates the refund row on completion. Retries replay the same key so the ledger collapses duplicates server-side. Failures that cannot be retried land in a dead-letter queue with enough context for a human to inspect.

The piece I had to be prompted toward was bounded staleness. You cannot promise a refund is immediately visible across the entire system, but you can promise that it is durable the moment you return 202 and that it is eventually reflected in the ledger within a tight SLO. The interviewer was clearly checking whether I would claim impossible consistency or if I would name the tradeoff explicitly.

Practice it: [[problem/199?company=13|Payment Webhook System]]

Round 3: Behavioral (10 min)

The behavioral segment was shorter than I expected but more pointed. The question was a standard conflict prompt: tell me about a time you had to resolve a disagreement inside your team. I opened too abstractly, saying our team had architectural disagreements that we worked through, and the interviewer visibly wanted more structure.

I restarted with STAR. The situation was a deadline crunch on a ledger reconciliation project where two engineers disagreed on whether to build on top of our existing RDS cluster or spin up a new Postgres instance dedicated to the reconciliation workflow. My task, as the most senior engineer on the feature, was to drive a decision quickly enough not to slip the deadline. The action I took was a 45-minute meeting where I whiteboarded the cost and operational overhead of each option side by side. The result was we picked the existing cluster with a separate logical schema, shipped on time, and avoided a second on-call rotation.

The interviewer asked one follow-up: what did you learn about when to defer to the team versus when to drive a call. My answer was that the signal is how reversible the decision is. Reversible choices should be delegated to the person doing the work. Irreversible ones, like spinning up new infra, need the fastest reasonable decision maker to step in.

Result

Offer came back four business days after the VO, at L3. The recruiter told me the fraud detection round was the strongest signal, which surprised me because I had felt rushed on it.

Tips

1. Pause and switch approaches out loud when you feel a brute force coming. In the fraud round my biggest signal was saying "this is quadratic, I am going to stop and switch to a deque." Stripe interviewers are listening for that self-correction more than for a clean first-try solution.
2. Memorize the per-user sliding window pattern cold. It is the single most reused Stripe coding motif: fraud detection, rate limiting, and abuse detection all reduce to the same deque-of-timestamps structure. If you have not implemented it in under five minutes in the last week, drill it.
3. For the refund system design, lead with idempotency and a queue. Never describe a synchronous write-then-call-ledger flow. Every mutating payment endpoint at Stripe is idempotent and durable-before-acknowledge. Saying 202 Accepted and mentioning the dead-letter queue in your first 90 seconds saves the round.
4. Use STAR even if you think you do not need it. The behavioral segment is short and unstructured answers burn the clock. Practice a 90-second STAR delivery for conflict, failure, and deadline pressure stories so you can ship them fast and have time for follow-ups.
5. Name bounded staleness explicitly when discussing eventual consistency. Stripe interviewers listen for whether you will overclaim consistency. Saying something like "refunds are durable at 202 and reflected in the ledger within a 30 second SLO" is the phrasing that lands.
6. Do not skip the sharding follow-up prep. Stripe loves asking how your single-host solution scales to many workers. Know hash partitioning by user, know why state-locality matters, and know how to talk about clock skew versus event timestamps without stumbling.