Stripe · Phone screen → Onsite
In processStripe New Grad 2026 Interview Coding Patterns: What Phone Screens and Onsites Test
Scope: January 5–September 22, 2026 · Stripe New Grad · Phone/Onsite only
The questions that repeated most
Invoice / Payment Reconciliation — 7 dates
2026-08-13, 2026-08-10, 2026-07-28, 2026-02-20, 2026-02-09, 2026-02-07, 2026-01-05
This was the clearest repeat. The task is to match one payment to the right invoice, but the match has a strict priority: invoice ID in the memo first, then an amount-based fallback, then tolerance and due-date rules. The common failure is finding a valid match without noticing that a higher-priority match should have won.
Financial Account Ledger — 4 dates
2026-09-14, 2026-09-11, 2026-09-10, 2026-09-08
All four dates landed in one week in September. The ledger mixes funding methods, cutoff hours, business days, settlement delays, and balance queries. The data structure is ordinary. The hard question is: at this exact time, which money is actually available?
Transaction Fee Calculator — 4 dates after merging its parts
2026-02-17, 2026-02-13, 2026-01-12, 2026-01-08
This one shows the usual progression well. Start with CSV and fee arithmetic. Then add successful-payment checks and country rates. After that come volume discounts or a waiver tracked separately for each merchant/provider pair. If parsing, fee lookup, history, and rounding all live in one loop, the later parts become painful.
Account Balance Manager — 3 dates
2026-05-11, 2026-02-09, 2026-01-15
First calculate balances. Then reject withdrawals that would go negative. Then let a platform account cover negative accounts. A small implementation detail matters a lot here: a rejected transaction cannot partially update anything, because every later answer depends on the current balance.
Email Subscription Scheduler — 3 dates
2026-02-20, 2026-02-13, 2026-01-28
At first it looks like date arithmetic plus sorting. Plan changes and renewals turn it into a mutable timeline. Some future emails keep their date, some need a new plan, and some must be rebuilt from a new expiration date.
Six more families appeared twice: WebSocket Load Balancer, Weighted Linked Merchants, Business KYC Verification, Ordered Action Rules, Linked Merchants Within Two Hops, and the Shipping Cost Calculator.
Patterns in 2026 questions
1. A lot of the work happens before the “algorithm”
The Six-Column Business CSV, KYC Verification, Timestamped Records, Contact Domain Filter, and Project and Filter Records all start in the same place: raw records that are not ready to use yet.
You need to trim fields, normalize case only where the rules allow it, keep empty fields visible, check field counts, preserve input order, and decide what malformed input should do. The safest shape is boring on purpose: parse once into a clean record, then let the business rules use that record. Re-splitting raw strings inside every rule is where follow-up bugs begin.
2. Rule priority is part of the solution
Ordered Action Rules, Invoice Reconciliation, Shipping Cost, Transaction Fees, and Fraud Reporting all punish vague rule order.
The details to settle before coding are concrete:
- first match or best match?
- first failure or every failure?
- is the range inclusive?
- does the transaction that crosses a threshold get the discount?
- what happens exactly at the cutoff hour?
- if two candidates match, which tie-break runs first?
A solution can have the right overall idea and still miss most hidden tests if one of those answers is left implicit.
3. State has to move in one direction
The Financial Ledger, Email Scheduler, Account Balance Manager, Transaction Fee Waiver, and WebSocket Load Balancer are all event-processing questions in different clothes.
Before coding, name the state: settled and unsettled money, current balances, active connections, object affinity, remaining capacity, or cumulative merchant/provider volume. Then process the events in order and give each command one clear transition. Duplicate, missing, or rejected actions should be deliberate no-ops, not half-finished updates.
4. The graph is hiding inside the records
Direct Record Linkage, Weighted Linked Merchants, and Two-Hop Linked Merchants look like data-cleaning questions until the links start expanding.
The actual work is to normalize fields, index shared attributes, score a possible link, deduplicate the result, and sometimes walk one or two hops. Under the merchant names and emails, this is weighted similarity plus a small graph traversal. Stripe just does not hand you the graph as an adjacency list.
5. Part 1 has to survive the follow-up
This is probably the most useful pattern to practice. The progression is very consistent:
- basic fee → conditional fees → volume rules
- fixed shipping price → tiers → mixed fixed/incremental tiers
- account totals → reject overdrafts → platform coverage
- least-loaded routing → disconnect → affinity → capacity → shutdown
- scheduled emails → plan changes → renewals
- basic validation → risk rules → behavior matching → prioritized errors
You do not need a framework for Part 1. You do need somewhere sensible to put Part 2. A small parser, a clear state object, and separate rule functions are usually enough. One giant loop is not.
Phone screen versus onsite
The raw page tags are 20 Phone, 8 Onsite, and 2 Phone/Onsite. That is a page count, so a multi-part family can contribute more than one page.
Phone screens lean toward parsing, validation, reconciliation, pricing, and record matching. The function is usually contained, but the interviewer can still learn a lot from how you clarify priority and boundaries before writing code.
The clearest onsite questions are longer stateful exercises: WebSocket routing, account balances, subscription events, and BitFont encoding. They leave more room for a new requirement and make it obvious whether the original structure is holding up.
The split is not absolute. URL compression appears in both stages, and there are small onsite tasks too. It is just the direction the 2026 set leans.
The mix changed during the year
January and February were heavy on fees, shipping, subscription schedules, BitFont, fraud checks, balances, and record validation.
By July through September, more reports were about reconciliation, ledgers, entity linkage, ordered rules, KYC, structured records, and WebSocket routing.
That later group feels more focused on priority, identity matching, financial state, and small infrastructure state machines. The wrapper changed. The core test did not: turn product language into deterministic behavior and be able to explain every boundary.
Related: 47-problem recency and frequency ranking · 2025–2026 interview reports Part 1 · Part 2
Comments
0No comments yet — be the first to share what you know.