Frontend interview guide
Stripe
The payments platform. A frontend culture built around trust, correctness, and dense product surfaces.
Frontend engineers interviewing at Stripe — React/TypeScript across the dashboard, docs, checkout, and public API console.
Last reviewed 2026-10-04
What they emphasise
- Correctness-first — a payments company treats bugs as a trust problem, not a sprint point.
- Dense UI craft — Stripe's dashboard and docs are both reference-grade products.
- Writing — the hiring loop and the day job both expect clear, long-form written argument.
- Pragmatic system design — rendering strategy, state at scale, and specifically what fails as a product grows.
The loop, round by round
6 rounds. Durations and formats are typical, not guaranteed — confirm the loop shape with your recruiter in the screen.
Round 1
Recruiter screen
~30 minCallWhat it covers
- Resume walk-through, level alignment, loop orientation.
What they're looking for
- A specific, product-aware answer for why Stripe.
Round 2
Technical phone screen
60 minLive coding in a shared editorWhat it covers
- A medium-difficulty problem — often a focused UI build (e.g. a search box with debounced results, a toast system) or a correctness-sensitive JS idiom (deep-equal, immutable updates).
What they're looking for
- Correct, well-tested code within the hour.
- A visible stance on edge cases without being prompted — payments culture.
Round 3
Onsite: integration
90–120 minPaired, longer-form build using a real codebaseWhat it covers
- An integration-shaped problem — pull an API, build a small component, write a test, document the behaviour.
- A real repo, real tooling, real tests. The feel of actual production work.
What they're looking for
- Reads unfamiliar code quickly and asks the right questions.
- Testing isn't an afterthought — behaviour tests show up with the code.
- A clean PR-shaped submission, with a thoughtful description.
Round 4
Onsite: system design
60 minWhiteboard / shared docWhat it covers
- A frontend-shape prompt — the Stripe dashboard filters, a receipt-rendering surface, a two-way webhook debugger.
- Scale, consistency, and the operational realities of a product real users depend on.
What they're looking for
- Trade-offs stated in terms of what breaks and when.
- Explicit scope-out — 'I'm not solving X here, which would need…'.
Round 5
Onsite: 'Sell Stripe to Stripe'
45 minPresentation + conversationWhat it covers
- The famous Stripe round. Present a product (anything — can be a Stripe product you don't work on, or something unrelated) to the interviewers and defend your design choices.
- The point is to see how you reason about products, not to catch you on specifics.
What they're looking for
- A clear thesis — 'this product's job is X; here is how the UI reflects that'.
- Comfort with the back-and-forth. The round is explicitly a conversation.
Round 6
Onsite: behavioural / values
45 minConversationWhat it covers
- Writing-sample follow-up (Stripe sometimes asks for one), hard-decision stories, cross-team collaboration.
What they're looking for
- Written and verbal clarity in equal measure.
- Specific 'this is why I made the call' answers.
What each level expects
The bar you're being measured against — plus the failure modes candidates most often trip on at that level.
SDE 2 / mid
~2–4 yearsL3 (Stripe's own ladder) — ships features end to end with mentorship.
What they expect
- Writes correct, testable React/TypeScript.
- Can read an unfamiliar codebase under light time pressure.
- Communicates in writing well enough to review a non-trivial PR.
Common failure modes
- No tests on the integration round — Stripe's culture takes testing as a baseline.
Senior
~5–8 yearsL4 / L5 — technical lead on an area, mentor to mids.
What they expect
- A system-design round that treats operational realities as co-equal with the happy path.
- A 'Sell Stripe to Stripe' round that reads as a thoughtful product conversation.
Common failure modes
- A system design that is a textbook pattern without adaptation.
- In the writing-sample round, prose that is correct but not direct.
Staff
~8+ yearsL6+ — technical direction across teams.
What they expect
- Peer-level system-design discussion.
- A writing sample that reads as something you'd publish externally.
- Visible multi-team leverage.
Common failure modes
- Senior+ output rather than Staff leverage. The Staff bar at Stripe explicitly rewards multiplying others.
How to crack it
Day-of advice. The specific moves that separate offers from no-offers when the content is already in your head.
- 1Read the Stripe dashboard and docs carefully. Both are reference-grade. Form specific opinions you can discuss.
- 2In the integration round, write at least one test per behaviour you implement. The expected baseline is tested code, not demo code.
- 3For 'Sell Stripe to Stripe', pick a product you genuinely use (doesn't have to be Stripe's) and have a one-paragraph thesis for why its UI is the way it is.
- 4Write a public blog post or long-form README before the loop. The writing-sample round is easier when you already have the muscle.
- 5In every round, lean into correctness over cleverness. Payments culture.
How to master it (over months, not days)
The longer-horizon work. These are the habits that pay off at Senior+ bars where cramming visibly fails.
- Ship something real with real users. The 'Sell Stripe to Stripe' round rewards someone who has shipped and reflected, not just studied.
- Read Stripe's engineering blog and press ('Increment' magazine, before it ended). The culture of thoughtful writing is explicit.
- Build the testing muscle. A habit of 'behaviour tests before merge' changes how you code, and shows up in interviews.
- Pick one dense product domain (billing, invoicing, taxes) and go deep. Depth in one area beats breadth of surface knowledge.
- Practice writing. Blog, PRs, RFCs. The Staff path at Stripe is written-artefact-heavy.
Resources
On-site content for the technical prep, plus short-list of external links worth your time.