← Back to Directory

Stripe interview notes, page 12 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·Machine Learning Engineer·Onsite - System Design / Architecture

May 2026
Stripe ML engineer system design round, one big open-ended question about fraud detection that basically ate the whole session. Dense topic and they clearly wanted depth on every layer, not just the model part.
  • Design a machine learning system for fraud detection in an online payment platform that scores transactions in real time and supports approve, block, challenge, or manual review decisions.

“This is a beast of a question.”

View Post

Stripe·Software Engineer·Recruiter / HR Screen

May 2026
Behavioral screen for a software engineer role at Stripe, pretty light on technical content. Two questions, both career-focused, felt more like a recruiter chat than anything else.
  • Where do you see your career heading in the next few years?
  • When you're evaluating a job opportunity, what matters most to you and why? Things like impact, growth, pay, the team, the tech, the mission.

“Pretty standard opener.”

View Post

Stripe·Software Engineer·Onsite - System Design / Architecture

May 2026
Stripe EM interview with a system design question on distributed caching. Not a lot of context to go on but the problem itself is a classic that somehow still trips people up.
  • Design a distributed LRU cache system.

“This is the kind of question where you think you know it cold and then you open your mouth and realize you've been fuzzy on the details for years.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round for a software engineer role. The problem was framed around payment authorization and fraud detection, which makes sense given the company, but the scope kept expanding mid-question and I had to stay calm about it.
  • Given a list of authorization requests (each with a timestamp, unique ID, amount, card number, and merchant), write a function that outputs a chronologically ordered, human-readable report where each line shows the timestamp, ID, amount, and an APPROVE or REJECT label. Then extend it to consume a stream of fraud rules (time, field, value) so that any request after a rule's timestamp whose matching field equals the rule's value gets marked REJECT. Write unit tests too.

“Two parts and they hit you with the second one right after you think you're done with the first.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round for a software engineer role. The whole thing was one big table-filtering problem that kept getting extended with follow-ups, each one layered on top of the last. Less about algorithms, more about whether your code could absorb new requirements without a rewrite.
  • You're given a table of records (many rows, multiple attribute columns per row). Write a function that filters or transforms the table based on a stated requirement and returns the matching rows. Then be ready to handle an open-ended series of follow-ups that each build on the previous result, like adding filters, deriving new columns, grouping, aggregating, or sorting.

“The thing that trips people up here isn't the first step, it's that the follow-ups never stop and each one assumes your last output is the input.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round with a weighted merchant-matching problem. Solid question, took me a bit to fully internalize the scoring logic but it was a good problem overall.
  • You're given a target merchant ID, a list of merchants, a set of per-field weights (for fields like ID, name, email, and phone), and a score threshold. Two merchants are considered linked if the sum of scores from their matching fields exceeds the threshold. Return all merchants linked to the target.

“This is basically a weighted variant of a deduplication or entity-matching problem.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding round, one problem the whole session. The problem looked manageable at first glance but the objective function has this absolute-difference term that trips you up if you're not careful about what you're actually minimizing.
  • You have exactly 3 factories, each with a list of options where each option is a cost-distance pair. Pick exactly one option per factory to minimize the total selected costs plus the sum of absolute differences between consecutive picked distances. Return the minimum total, and discuss brute-force enumeration versus whether sorting by distance allows any pruning.

“Brute force is fine here since you only have 3 factories, just enumerate all triples and compute the objective.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe SWE interview with a KYC record validation problem that looked straightforward at first but kept getting new rules added mid-session. The follow-up discussion on scaling and data structures was where things got interesting.
  • Given a set of KYC records, implement a validator that checks multiple rules: no empty fields, a length constraint on one column, a forbidden-word check on another column, and a cross-column word membership rule where each word in column 2 must appear in at least one of two other columns.
  • How would you improve the implementation for performance and scale, specifically around word lookup, early termination, and handling large dictionaries across many records?

“The fourth rule is where I tripped up.”

View Post

Stripe·Data Scientist·Onsite - System Design / Architecture

May 2026
Stripe DS interview was a single deep-dive SQL/ETL design session. The whole thing was one sprawling problem about building a rerunnable pipeline on top of a fact table, and it went places I did not fully expect. Walked out unsure whether I nailed it or just survived it.
  • Write SQL CTEs that deduplicate events_raw by event_id keeping only the row with the highest ingested_at, and deduplicate orders_raw by order_id keeping the row with the highest updated_at. Then explain why deduping on natural keys like event_id is safer than using ROW_NUMBER over (u_id, event_ts).
  • Using your deduped CTEs, write a SELECT that produces one row per non-test user for a given date D, computing first_event_ts, events_cnt, paid_orders_cnt, and paid_orders_amt. Orders should only count if the latest status is paid, shipped, or completed, not refunded or canceled.
  • Records for date D can arrive up to 2 days late. Describe and write SQL for an incremental approach that recomputes partitions for a rolling window on each run date, then merges only the target partition. Show a MERGE or INSERT OVERWRITE example and explain how it stays idempotent on reruns.
  • Enumerate at least five edge cases your ETL must handle, such as partial writes, schema drift, null event timestamps, daylight saving time issues, and replayed backfills. For each, describe the defensive technique you'd use.
  • Write two reconciliation queries: one that compares counts and amounts between orders_raw (latest status) and the daily_user_metrics fact table for date D, and one that detects any duplicate event_ids that leaked into the D partition.

“The ROW_NUMBER angle is where I fumbled a bit.”

View Post

Stripe·Software Engineer·Technical Phone Screen

May 2026
Stripe coding screen for a software engineering role. One problem, but it had enough moving parts to keep me busy for the whole session.
  • You're processing a stream of bank transactions in timestamp order. Each transaction has an account name, timestamp, currency, and amount (positive for credits, negative for debits). There's also a special platform account: whenever a non-platform account's balance would drop below zero, the platform automatically lends just enough to bring it back to zero. Track the maximum total amount ever borrowed from the platform across all accounts at any single point in time, and return that value along with the final balance for every account. Do it in O(N) time.

“The running balance part was fine, I got that pretty fast.”

View Post