← Back to Directory

Stripe interview notes, page 17 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

May 2026
Stripe system design round that extended a worker-task-assignment problem across multiple parts, with this one adding account-based sticky routing on top of the existing type-aware scheduling logic. Genuinely tricky because the edge cases compound fast and the interviewer wanted you to reason through all of them out loud.
  • You have a worker-task-assignment system where each task now carries an account field. Tasks from the same account should always route to the same worker (sticky routing), unless that worker doesn't support the task's type, in which case you fall back to the earliest-free eligible worker. Design this system, discuss the data structures needed, and walk through a sample stream of tasks.

“This one built on two prior parts so by the time we got here I thought I had a handle on it.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe Android Engineer interview with a billing/interval-union coding problem. Pretty algorithmic for a mobile role, which surprised me a bit, but the problem itself was well-defined once I slowed down and read it carefully.
  • Given a stream of chat session events with timestamps and user IDs, compute the total billable seconds per user. Sessions can overlap, so you need to count the union of intervals rather than summing durations naively. Malformed sessions where the end is before the start should be discarded.

“I started by just summing end minus start for each session and almost submitted that before catching the overlap issue.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round, software engineer role. They gave me a scheduling problem that looked deceptively simple but had enough edge cases to trip you up if you rushed in.
  • Build an email notification scheduler: given a list of user accounts with creation and expiration days, and a set of notification rules with different trigger types, output all emails that should be sent on a given day.

“My first instinct was to just nest two loops and call it done, which works but I spent way too long second-guessing whether they wanted something fancier.”

View Post

Stripe·Data Scientist·Onsite - Product Sense / Strategy

May 2026
Stripe DS interview focused entirely on Stripe Capital, their lending product. Four questions, all case-style, all interconnected. Felt more like a product strategy session than a data science interview, which threw me off a bit.
  • Design a dashboard for Stripe Capital. What metrics would you include across merchant acquisition, loan performance, repayment, credit risk, merchant outcomes, and unit economics? Which are leading vs. lagging indicators, and how would you segment or cohort them?
  • How would you decide whether Stripe should not offer a pre-qualified loan to a merchant, or flag an existing loan as increasingly risky? What early warning signals and features would you use, and how do you think about thresholds, calibration, and fairness?
  • Should Stripe present merchants with a single recommended loan amount or multiple loan options? Walk through the product, risk, operational, and measurement tradeoffs of each approach.
  • Stripe Capital profit has declined over the past two quarters. How do you diagnose what's driving it? Structure your analysis across demand, underwriting quality, repayment behavior, pricing, portfolio mix, and macro conditions.

“This one felt deceptively open.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round, probably mid-level, focused on a banking simulation problem that kept getting layers added to it. The platform account fallback twist was the part that actually required some thought.
  • You're given a list of transactions, each with a source account, an amount, and a platform account ID. If the source account can't cover the transaction, pull the shortfall from the platform account. If that also fails, reject the transaction. Return all final balances.

“The base version of this problem isn't bad, just simulate debits and track balances.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding screen, payments domain, one algorithmic problem about matching payments to invoices. Pretty clean problem once you see the indexing trick, but I spent too long second-guessing the fallback logic.
  • Given a list of payments and a list of invoices, write a matching algorithm: first try to match each payment to an invoice by its invoice ID, and if that fails, match by amount (picking the earliest-dated invoice with that amount). Return all matched pairs and flag any unmatched payments.

“I got the exact-ID lookup immediately, that part was fine.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round focused on extending a transaction processing system to include validation logic. Pretty involved problem that builds on a prior part, so context matters a lot going in.
  • Given a list of transactions between accounts, add validation logic that determines whether each transaction is legal before applying it. A transaction should be rejected if the sender has insufficient funds, either account isn't registered, or the amount isn't positive. Return the final account states and optionally a list of rejected transactions with reasons.
  • How do you handle the case where the legality of a later transaction depends on whether an earlier transaction was applied or rejected?
  • What edge cases would you test for when inputs include invalid or malformed transactions?

“The tricky part isn't the validation itself, it's that earlier transactions affect whether later ones are valid.”

View Post

Stripe·Machine Learning Engineer·Technical Phone Screen

May 2026
ML coding round at Stripe with a regression-focused problem that had a sneaky preprocessing catch. Nothing flashy, but the question had more depth than it looked at first glance.
  • You have a multi-task regression problem where one set of labels is negative and the other is positive, and the ranges are very different. How do you handle training both tasks together effectively?

“The regression framing threw me a bit since I was expecting classification.”

View Post

Stripe·Product Manager·Onsite - Product Sense / Strategy

May 2026
Stripe case question about fraud at the merchant level. Pretty open-ended, no obvious right answer, which I both liked and found stressful.
  • One of our merchants is seeing a spike in fraudulent transactions. How do you approach solving this?

“I went straight into triage mode: figure out what kind of fraud, where in the payment flow it's happening, whether it's isolated to one merchant or a pattern.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe SWE interview built up a banking account system across four progressive parts, each adding more complexity. The design discussion kept going deeper than I expected, especially around data structures and time complexity for each operation.
  • Implement the core of a banking account system: creating an account, depositing funds, and retrieving the balance.
  • Add a transfer function between accounts that takes a timestamp and enforces balance checks before moving funds.
  • Given all transfers made so far, return the top N accounts ranked by total outgoing transfer volume.
  • Extend the transfer system to support scheduled transfers that execute at a future timestamp, and handle balance queries that can either include or exclude pending transfers.

“Felt easy at first, just a hashmap from account ID to balance.”

View Post