← Back to Directory

Stripe interview notes, page 29 of 35

Large Enterprises

Most of these Stripe write-ups come from Software Engineers (295), then Product Managers (22) and Data Scientists (20). The most reported rounds are the technical phone screen (206), the system design round (39), the behavioral / leadership round (22) and the product sense round (20).

342 interview notes · updated Oct 2026

Stripe·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Went through a system design round at Stripe for a software engineer role. The prompt was the feature flag design question that's been floating around on forums, so it wasn't a surprise. Felt like it went fine, nothing too painful.
  • Design a feature flag system.

“Pretty well-known prompt at this point, so I'd seen it before going in.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe technical screen focused on a multi-level relational data problem. The question was deceptively implementation-heavy and I underestimated how much the traversal logic would trip me up.
  • You have a two-level nested relationship: users own accounts, and accounts own sub-accounts or payment instruments. Design a data structure and write a traversal that lets you aggregate or look up data across all levels for a given user, without double-counting.

“I jumped straight to a hashmap and felt good about it for about two minutes.”

View Post

Stripe·Data Scientist·Technical Phone Screen

Jun 2026
Stripe DS interview with a single deep-dive case on predicting merchant subscription adoption. The whole thing was one long multi-part ML design question and it went places I did not fully anticipate.
  • Design a production-ready classification system to predict which non-subscription merchants will adopt Stripe's Subscription product within the next 60 days, covering labeling strategy, leakage prevention, feature engineering, modeling choices, evaluation, and post-deployment monitoring.

“This was basically six questions wrapped in one and I did not realize how deep it went until I was already three sub-parts in.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe SWE interview that included a debugging exercise around serialization logic. Did not go well.
  • You're given a serialization bug where empty lists and null-containing lists are treated differently when applying default values. How do you identify and fix the inconsistency?

“Completely fumbled this.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe technical phone screen for a software engineering role. Three-part coding problem that escalated pretty quickly from basic bookkeeping to something with actual edge cases worth thinking about.
  • You're given a list of transaction records as strings, each containing an account ID, timestamp, currency, and amount. Process all transactions and return the final non-zero balance for each (account, currency) pair.
  • Now process those same transactions in timestamp order and reject any debit that would push an account's balance for a given currency below zero. Rejected transactions have no effect. Return final non-zero balances.
  • Extend the solution so that when a debit would overdraw an account, a designated platform account can cover the shortfall in the same currency. If the platform account also can't cover it, reject the whole transaction. Credits always go through. Return final non-zero balances for all accounts including the platform account.

“Part 1 felt easy and I maybe moved too fast.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe interview that started with a classic shortest-path problem and then pivoted hard into distributed systems territory. The scale discussion is where it gets interesting and where I felt underprepared.
  • Given a flight network with n cities and a list of flights with prices, find the cheapest price from a source to a destination with at most k stops. Return -1 if no route exists.
  • The flight network is now very large and prices update in real time. How do you optimize the system to handle this efficiently?
  • When a single flight price changes, which cached or precomputed results get invalidated, and can you do that cheaply without recomputing everything?
  • How would you use hierarchical graph decomposition or contraction hierarchies to speed up point-to-point queries on a large flight graph?

“I knew this one.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe coding round for a software engineer role, one big multi-part problem about building an email notification scheduler. The question kept growing with each sub-part and by the end I was juggling plan changes, renewals, and tie-breaking logic all at once.
  • Given a send schedule and a list of user accounts (each with a name, plan, start date, and duration), generate all email notifications in chronological order. When multiple notifications land on the same timestamp, apply a specific deterministic ordering: state changes first (Changed, then Renewed), then start events, then relative-offset events sorted most-negative first, then end events, with lexicographic name ordering within each bucket.
  • Extend the scheduler to handle plan changes: given a list of change events (account name, new plan, change date), emit a '[Changed]' notification at the change date and make sure all notifications at that same timestamp and any future ones reflect the updated plan name.
  • Further extend the scheduler to support renewal events that push an account's end date forward by a given number of days. On renewal, emit a '[Renewed]' notification, recompute all future relative-offset and end-date events for that account, and handle the case where a renewal and a plan change happen for the same account at the same timestamp.
  • Describe the data structures you'd use and the time complexity of your solution for N accounts and M change or renewal events.

“The baseline part felt manageable.”

View Post

Stripe·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Stripe system design round for a software engineering role. The problem was about role inheritance across an account hierarchy, which sounds manageable until you actually have to think through the trade-offs live.
  • You have a list of (userId, accountId, role) assignments and an account hierarchy where roles inherit downward from ancestors. Given an accountId, return all users who have any role on that account or any of its ancestors. Then discuss the trade-offs between walking the ancestor chain at query time versus precomputing a reverse index.

“My first instinct was to just walk up the tree and union the user sets as I go.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Did a debug round for Stripe's software engineer role. One bug in particular tripped me up more than it should have.
  • Given a YAML configuration file parsed with SnakeYAML, debug why the value for a boolean-like key is not being interpreted correctly.

“The bug was that 'flag: on' was being read as a boolean true instead of the string 'on'.”

View Post

Stripe·Software Engineer·Technical Phone Screen

Jun 2026
Stripe coding round for a software engineer role, working through a transaction processing problem that kept adding layers. The core was straightforward but the borrow-from-platform twist at the end made me rethink a bunch of my earlier data structures.
  • You're processing a stream of transactions in timestamp order, each with a sender, receiver, amount, and id. Accounts have balances you maintain as you go. Given a set of validation rules (valid accounts, positive amount, sufficient balance), implement the transaction processor and return final balances.
  • Now relax the insufficient-balance rule: instead of rejecting a transaction when the sender can't cover it, let the transfer go through and have the platform cover the shortfall as a debt. Track these platform borrows per account and return them alongside final balances.

“This felt manageable at first.”

View Post