Top 15 Stripe Coding Interview Problems: Patterns and What Each Teaches

Stripe's interview is a different game. Not "reverse a linked list" and call it done. More like: here's a payment log, parse it, now extend it to handle refunds, now make it idempotent, and by the way the timestamp format changed between Part 1 and Part 2.

The algorithm underneath is familiar. The wrapper is Stripe's actual product, and that wrapper is load-bearing.

This guide covers the 15 most common Stripe coding interview problems, the pattern each one represents, and the specific insight Stripe is testing. For a full breakdown of how all five rounds are structured, see The Stripe Onsite Interview Loop.

Why Stripe's Interview Feels Different

Three things set Stripe apart from a standard tech interview.

Multi-part problems. Every problem has 2-4 follow-ups that add constraints or extend scope. Part 1 is usually easy. Part 4 is technically a bonus. The real test is whether your Part 1 code can survive what follows. If you wrote a 200-line monolith in Part 1, Part 3 is a rewrite. You're not debugging your code at that point. You're grieving your architecture.

Production code expectations. Named variables, modular functions, edge cases surfaced before you start coding. A readable brute force often scores higher than a clever solution that's impossible to extend. The interviewer needs to read your code. So does Part-3 you, who will be staring at it under time pressure 20 minutes later and wishing you'd named that variable something other than temp2.

No graph or DP gauntlet. You won't get Bellman-Ford or a 2D knapsack. Stripe's problems are medium difficulty, grounded in data processing, scheduling, and system behavior. That's the product space they operate in.

Stripe Coding Interview Problems: The Full List

Quick Reference

#	Problem	LeetCode	Pattern	Difficulty
1	Logger Rate Limiter	359	HashMap + timestamps	Easy
2	Transaction Balance Parser	Custom	HashMap + string parsing	Medium
3	Merge Intervals	56	Sort + greedy merge	Medium
4	Top K Frequent Elements	347	Min-heap / bucket sort	Medium
5	Meeting Rooms II	253	Min-heap + intervals	Medium
6	Design Hit Counter	362	Circular buffer / queue	Medium
7	Group Anagrams	49	HashMap with canonical key	Medium
8	Subarray Sum Equals K	560	Prefix sum + HashMap	Medium
9	LRU Cache	146	HashMap + doubly linked list	Medium
10	Decode String	394	Stack-based parsing	Medium
11	Task Scheduler	621	Priority queue + greedy	Medium
12	Min Arrows to Burst Balloons	452	Greedy interval scheduling	Medium
13	Subscription Billing Simulator	Custom	Sorting + state tracking	Medium
14	Sliding Window Maximum	239	Monotonic deque	Hard
15	Word Break	139	Bottom-up DP	Medium

1. Logger Rate Limiter (LeetCode 359)

Stripe is a payments company. Rate limiting isn't a toy problem for them. It's load-bearing infrastructure. Every API call a merchant makes goes through rate limiting. They can't not ask this.

The setup: a logging system where each unique message prints at most once every 10 seconds. You receive a timestamp with each call.

A HashMap from message to last-printed timestamp is the entire solution. On each call, if timestamp - last_printed >= 10, print and update. If not, skip. The core algorithm is two lines.

What Stripe watches for: do you pull the timestamp comparison into a named helper? Do you handle the cold-start case without a special branch? Do you bring up what happens when two messages arrive at the exact same timestamp?

Follow-ups: cap stored messages, add per-user limits, make it thread-safe with concurrent access.

2. Transaction Balance Parser

This one is distinctly Stripe-flavored and shows up frequently in phone screens. You receive a list of transactions in some string format, like "alice sent 25 to bob" or tuples like ["alice", "bob", "25"]. Compute the net balance for every participant.

The pattern is HashMap accumulation. For each transaction, add the amount to the sender and subtract from the receiver.

The bug most candidates write: they quietly drop users with a negative balance. If alice sent more than she received, her balance is negative and still belongs in the output. The sign is data, not a filter. Silently removing it is, technically speaking, embezzlement.

Follow-ups: filter by region, handle refunds (reverse the direction), support multiple currencies with a conversion table.

3. Merge Intervals (LeetCode 56)

Sort by start time. Walk the list. If the current interval's start falls within the previous interval's end, merge by updating the end to max(prev.end, curr.end). Otherwise push the previous interval and advance.

That max() call is not optional. Write curr.end instead and you break on cases where one interval completely contains another. That's the first edge case Stripe interviewers will test.

Stripe uses interval logic in subscription billing windows, scheduled payment processing, and fraud detection overlap analysis. See Merge Intervals: The Template Behind Every Scheduling Problem for the full implementation.

4. Top K Frequent Elements (LeetCode 347)

Build a frequency map first, then maintain a min-heap of size k. For each element, push it with its count. If the heap exceeds k elements, pop the minimum. What remains is the top k.

If k is close to n, bucket sort beats the heap. Create an array of buckets indexed by frequency (1 through n), place each element in its bucket, then read from the right.

Stripe asks this as a data analysis problem: find the top merchants by transaction volume, or which error codes appear most in the past hour. The framing is the tell. See Top-K Elements: The Heap Signal for the pattern recognition cues.

5. Meeting Rooms II (LeetCode 253)

Given meeting time intervals, find the minimum number of rooms required to hold them all concurrently.

Sort by start time. Use a min-heap of end times. For each new meeting: if its start is after the heap's minimum end time, reuse that room (pop, push new end time). Otherwise allocate a new one (just push).

The heap size at the end is your answer. The min-heap is the natural fit because you always want to reuse the room that freed up earliest. Stripe applies this to subscription slot allocation, concurrent API session limits, and resource-bounded scheduling.

6. Design Hit Counter (LeetCode 362)

Design a counter that tracks hits in the past 5 minutes (300 seconds). Support hit(timestamp) and getHits(timestamp).

A circular buffer of size 300 solves this in O(1) for both operations. Each slot stores the timestamp of the last write and the count for that second. On hit(t), check if times[t % 300] == t. If yes, increment. If not, a different timestamp has wrapped into this slot, so reset it. On getHits(t), sum counts for all slots where times[i] + 300 > t.

The circular buffer is production-ready and trivially explainable. That combination is exactly what Stripe rewards.

7. Group Anagrams (LeetCode 49)

The canonical key is sorted characters. "eat", "tea", and "ate" all sort to "aet". Build a HashMap where keys are sorted strings and values are lists of original strings. One pass at O(n * k log k) where k is max string length.

The follow-up Stripe adds: use a character-frequency tuple as the key instead of sorting. That brings lookup to O(n * k) and tests whether you can think about the tradeoff between key construction cost and correctness. Know both versions.

8. Subarray Sum Equals K (LeetCode 560)

Count subarrays that sum to exactly k.

Brute force is O(n²). The key insight: prefix[j] - prefix[i] == k means the subarray from index i to j has sum k. So as you build prefix sums, store them in a HashMap. At each step, check how many times prefix_sum - k has already appeared.

Initialize the map with {0: 1} before you start. Without it, subarrays starting at index 0 are invisible to the lookup. Missing that initialization is the single most common bug on this problem, and Stripe interviewers know to probe for exactly it.

9. LRU Cache (LeetCode 146)

O(1) get and put. The structure: a HashMap for lookup paired with a doubly linked list for O(1) move-to-front and O(1) eviction.

Sentinel head and tail nodes eliminate every null check. Every real node lives between them. On access, unlink the node and reinsert at the tail (most recently used). On eviction, remove the node just after the head (least recently used). The HashMap stores key to node, not key to value, so you can unlink in O(1).

See LRU Cache Implementation for the full walkthrough with code. Stripe asks this because LRU caches appear in session stores, idempotency key caches, and merchant config lookups throughout their stack.

10. Decode String (LeetCode 394)

Given "3[a2[c]]", decode it to "accaccacc".

Two stacks: one for counts, one for the in-progress string. Walk the input character by character. On a digit, build the number. On [, push the current count and current string, then reset both. On ], pop count and outer string, repeat the current string that many times, append it to the outer string.

If your Part 1 only handles one level of nesting, the follow-up is a complete rewrite. Clean stack management from the start is the only way out of that trap.

11. Task Scheduler (LeetCode 621)

Given tasks and a cooldown n, find the minimum CPU time to execute all tasks. The same task type can't run within n intervals of its previous execution.

Use a max-heap to always pick the most frequent available task. After each window of n+1 slots, push tasks back with updated counts.

The formula (max_freq - 1) * (n + 1) + count_of_max_freq gives the minimum directly, but Stripe interviewers still want the simulation. They're confirming you understand the structure, not just that you memorized the shortcut. One without the other raises flags.

Stripe frames variants as payment processing jobs with a retry delay between attempts on the same merchant.

12. Minimum Number of Arrows to Burst Balloons (LeetCode 452)

Balloons span horizontal intervals. An arrow at position x bursts every balloon whose range includes x. Find the minimum arrows needed.

Sort by end coordinate. Fire each arrow at the current balloon's end as late as possible. If the next balloon starts after the current arrow's position, fire a new arrow.

Sorting by end (not start) is what makes greedy work here. Sorting by start leaves ambiguity about which balloon to target first. Sorting by end guarantees each arrow is used as efficiently as possible. This pattern shows up in Stripe's subscription overlap and deduplication problems.

13. Subscription Billing Simulator

This is the most Stripe-flavored problem on this list. Multiple candidates have reported it across onsites. You receive a list of events: a user subscribes to plan A at T1, upgrades to plan B at T2, cancels at T3. Compute what they owe.

Sort events by timestamp. Track the current plan and its start time. On each transition, compute the prorated charge for the period that just ended.

The algorithm is not the test. The multi-part structure is. Part 1: flat billing with no proration. Part 2: prorated charges on plan changes. Part 3: discount codes applied retroactively, which is when you discover your initial data model was wrong. Part 4: partial refunds with credit calculations, which is when you question your life choices.

Write functions with clear names and single responsibilities from the first part. If the billing logic is inlined in a loop, you'll be copy-pasting and praying for Parts 2 through 4.

14. Sliding Window Maximum (LeetCode 239)

Find the maximum value in every sliding window of size k.

Naive: O(n * k). Monotonic deque: O(n). Maintain a deque of indices in decreasing value order. For each new element, pop from the back while the back element is smaller than the current. Pop from the front if that index has left the window. The front is always the current window's maximum.

This is the hardest problem on this list and most likely to appear at senior level or as a follow-up. The sliding window technique is a prerequisite; the monotonic deque is the extension.

15. Word Break (LeetCode 139)

Given a string and a dictionary of words, determine whether the string can be segmented into dictionary words.

Boolean DP. dp[i] is true if s[0..i] can be segmented. For each position i, check all splits j from 0 to i: if dp[j] is true and s[j..i] is in the dictionary, set dp[i] = true. Store the dictionary as a set for O(k) lookup.

Stripe asks this as a transaction description parser: given a payment description string with whitespace stripped, can you identify the component parts? The business framing obscures the DP structure. That's entirely the point.

What Stripe Is Actually Testing

None of these problems are exotic. Every pattern here is medium difficulty.

The real test is how you build software. How you name things. How you structure functions so the follow-up is an addition, not a rewrite. How you surface edge cases before you write a single line. How you explain your reasoning while you code, not in a retrospective after you've already submitted.

The multi-part format makes this measurable. Your code has to evolve in front of them. There's no hiding behind a clean final solution if the path to get there was unmaintainable. Part 3 will find it.

The skills that win at Stripe, particularly explaining your reasoning in real time, are not trained by grinding LeetCode silently. SpaceComplexity runs voice-based mock interviews in Stripe's multi-part format, with rubric feedback on communication and code structure after every session.

What to Practice First

Stripe asks medium-difficulty problems wrapped in a payments or business logic context. Recognize the pattern under the wrapper.
Multi-part problems are standard. Write modular, named code from the first part. Interviewers watch how your code survives follow-ups.
HashMap, intervals, heaps, and sliding window dominate. Know them cold.
Production-quality code outscores clever-but-cryptic code every time.
The debugging and integration rounds test entirely different skills. See Stripe Phone Screen Interview for what the earlier rounds look like.