2016–2026 Stripe SWE Intern Technical Screen (R1): 55 Experiences

This summary brings together every R1 report in our current intern collection.

Coverage: 55 deduplicated Software Engineer or Software Development Engineer intern experiences. Candidates used names such as technical screen, team screen, phone screen, or first live coding round. The reports span the United States, Canada, and unspecified locations from October 2016 through October 2026.

For a fren, thank them for their patience! And good luck.

The short version

Stripe R1 is usually a practical implementation round with connected parts. It is much closer to building and extending a small program than solving one isolated LeetCode problem.

1. Expect one problem to grow. At least 31 of the 55 reports describe multiple connected parts, numbered phases, or a follow-up that changes the earlier code.
2. Strings, maps, lists, CSV, JSON, and state show up often. The work is usually data handling or business logic. Heavy graph or dynamic-programming tricks are not the main pattern in this intern set.
3. Write code that can survive the next requirement. Later parts often reuse the old behavior. One six-part screen even asked the candidate to rebuild earlier functions through shared comparators and helpers.
4. Testing is part of the interview. Ten reports explicitly mention candidate-written tests, interviewer-run tests, provided tests, or debugging against examples.
5. The timer is real. The seven reports with a usable time signal cluster around 45 or 60 minutes. One candidate said the coding and testing took about 35 minutes.
6. There is no proven completion cutoff. Candidates moved forward after partial solutions, while other candidates were rejected after strong completion. The evidence does not support a rule such as “finish three parts and pass.”

A practical preparation formula: take one business-style problem, solve it in 60 minutes, add two changing requirements, write your own tests, and explain every assumption while you code.

Repeated R1 question families through out the past 10 years

01: Toy database / row selection — 6×

The oldest repeated R1 family asks the candidate to choose a whole record, not just a value.

1. Select a row using the minimum value for one key.
2. Add minimum or maximum direction.
3. Compare rows by several ordered keys.
4. In some versions, build the earlier functions from a comparator or ordering helper.

Missing fields counted as zero in two reports. One report allowed any tied row. Other tie, empty-input, and return-order rules were not consistent enough to generalize.

To work through the same progression, try Toy Database — Select a Row by Ordered Keys — Last seen: 2020-10-13 · 2019-11-12 · 2019-10-22 · 2019-10-18.

02: Shutdown or closing-time penalty — 4×

This family appeared from 2021 through 2023.

1. Score a proposed shutdown time.
2. Find the time with the smallest penalty.
3. Parse a larger string containing valid BEGIN / END sections.
4. Run the same best-time calculation for every valid section.

The reports disagree on whether the states were written as 0/1 or Y/N, and not every source preserved a possible fourth part.

The matching practice path starts by scoring one shutdown time — Last seen: 2023-09-23 · 2021-12-08 · 2021-10-24 · 2021-10-11 · 2021-09-27 · 2021-09-17 · 2021-08-26, then finding the best time — Last seen: 2021-09-17, and finally processing valid log blocks — Last seen: 2021-09-17.

03: Shipping cost — 4×

One report preserves the full three-part progression. The others name shipping cost or describe only part of the model.

1. Multiply each product quantity by a country-specific unit price.
2. Replace the single price with quantity tiers.
3. Support both per-unit tiers and flat charges for a bracket.

The clearest report used Python dictionaries and let a null upper bound represent the last unbounded tier. Another report described graphs and dictionaries but did not show what the graph represented, so it stays a partial sighting.

You can solve the three versions in the same order: fixed per-unit prices — Last seen: 2026-02-17 · 2026-01-16 · 2025-12-22 · 2025-11-19 · 2025-11-16 · 2025-11-12 · 2025-11-08 · 2025-10-29 · 2025-06-24 · 2025-01-02 · 2024-12-23 · 2024-10-05, volume tiers — Last seen: 2026-02-17 · 2026-01-16 · 2025-12-22 · 2025-11-19 · 2025-11-16 · 2025-11-12 · 2025-11-08 · 2025-10-29 · 2025-06-24 · 2025-01-02 · 2024-12-23 · 2024-10-05, then mixed fixed/incremental tiers — Last seen: 2026-02-17 · 2026-01-16 · 2025-12-22 · 2025-11-19 · 2025-11-18 · 2025-11-16 · 2025-11-12 · 2025-11-08 · 2025-10-29 · 2025-06-24 · 2025-01-02 · 2024-12-23 · 2024-10-05.

04: Accept-Language — 2×

Both candidates matched browser language preferences against languages supported by a server.

1. Match exact language tags.
2. Let a generic tag such as en match regional forms.
3. Expand * into the remaining supported languages without duplicates.
4. One candidate also sorted by preference weights, with missing weights defaulting to 1.

Case handling, equal-weight ordering, and zero-weight behavior were not preserved.

The first three reported phases are covered in HTTP Accept-Language Matching — Last seen: 2025-01-02 · 2021-11-05 · 2021-09-27 · 2021-09-10 · 2021-07-23 · 2021-05-10.

05: Invoice / payment reconciliation — 2×

The clearest version had three parts:

1. Match a payment to an invoice ID found in its memo.
2. If no usable ID exists, choose the earliest invoice with the same amount.
3. Accept an amount within a tolerance and still choose the earliest match.

One candidate completed all three parts and later received an offer. The other report confirms the same progressive family but does not preserve its exact extensions.

The runnable version is Invoice / Payment Reconciliation — Last seen: 2026-10-06 · 2026-10-01 · 2026-09-29 · 2026-08-13 · 2026-08-10 · 2026-07-28 · 2026-02-20 · 2026-02-09 · 2026-02-07 · 2026-01-05 · 2025-12-08 · 2025-04-09 · 2025-03-18.

06: Rate limiter — 2× technical-screen sightings

The detailed 2025 screen lasted 45 minutes. It used hit(key, timestamp) to record traffic and allowed(key, timestamp) to check the recent count. The interviewer accepted either a fixed or sliding window and asked about many keys, cleanup, bursts, missing keys, out-of-order timestamps, long idle periods, concurrency, and complexity.

The 2019 report names a rate limiter as its second live screen but does not preserve the policy. These two sightings support the family, not one universal prompt.

For a concrete version of that discussion, use Sliding-Window Rate Limiter — Last seen: 2025-10-16 · 2023-11-17 · 2021-04-23.

Other R1 tasks reported once

1. Server number allocation — Last seen: 2016-10-24. Find the first missing positive number, then use it to allocate the smallest free server number per server type. Deallocation returns a number only to the matching type.
2. HTTP request replay. Work in a private Java/Maven repository, read HTTP requests described by JSON, send them, and validate responses. The schema and endpoints were not shared.
3. Mutual wishlist rankings — Last seen: 2021-09-27 · 2021-09-03. Check whether two people rank each other first. Broader swap and ranking rules were not preserved.
4. HTTP URL decomposition — Last seen: 2021-10-01. Break a URL into required pieces. The grammar and exact output fields were not shared.
5. Indexed proximity search — Last seen: 2024-01-20. Find positions of the first query word when the other words are nearby, then preprocess the document for faster repeated queries. The discussion used inverted indexes, two pointers, and binary search.
6. Length-prefixed card strings. Parse cards that start with a two-digit length, keep supported cards, then expand generic prefixes into an ordered result without duplicates.
7. Merchant receivables — Last seen: 2024-11-08 · 2024-10-21 · 2023-12-21. Aggregate transactions by merchant, card type, and payout date, then replace matching merchant receivables with contract values.
8. Fraud detection. The candidate named the domain and advanced, but the rule, input, and output were not preserved.
9. Merchant transactions. One Toronto candidate described three progressive parts but did not share the event types, fees, balances, or result format.
10. Discount calculation — Last seen: 2025-10-29. The report names the calculation but not its formula.
11. Currency conversion and balance checks — Last seen: 2025-12-22. Process financial records, convert currencies, and check balances while requirements change.
12. Key-value validation — Last seen: 2025-12-03. Validate records against a schema across three parts. The original schema and failure rules were not shared.
13. CSV parsing and queries. Parse one CSV string and answer queries over it. The candidate finished two parts and discussed the third; the schema and query language were not preserved.
14. eKYC low-level design — Last seen: 2026-03-27. Model an electronic know-your-customer flow. The report did not preserve the entities, operations, validation rules, or output.
15. Load-balancer-style coding. A three-part interview in 2026; the candidate finished two parts. The source did not confirm whether this was the team screen or a later round, and it did not preserve routing or tie-breaking rules.

What the incomplete R1 reports still tell us

Twelve reports did not preserve a usable prompt, but they still add useful structure:

1. Three candidates described an unnamed three-part screen. One finished about two and a half parts, one reached Part 3, and one only said that each part added a new requirement.
2. One problem unlocked parts one at a time and added edge cases to the existing implementation.
3. One screen used maps and practical implementation similar to the OA.
4. Two screens contained two unnamed tasks or parts.
5. One candidate finished two array/map/string parts and explained the third.
6. One one-hour C++ screen used arrays and strings and required the candidate to write the functions, input handling, and tests from scratch.
7. One process used classes, strings, and API requests, but the report did not separate the team-screen prompt from later work.
8. One Bucharest process focused on strings and basic implementation without preserving the task.
9. One candidate remembered only that code quality, product judgment, and ambiguity mattered.

Nine more reports confirm the process but not the R1 question. Together they preserve these points:

• R1 sat between the OA and onsite in reports from 2018, 2021, 2024, 2025, and 2026.
• One Toronto report calls it a 60-minute engineer screen before two 45-minute onsite sessions.
• Three 2021 timelines place the screen roughly one to three weeks after the OA.
• A 2024 timeline recorded an OA on September 9, R1 on September 19, onsite on October 18, and manager interview on October 21.
• One candidate later accepted an offer, one declined an offer, and others were waitlisted, rejected later, or still waiting. Those final outcomes do not isolate the R1 score.
• One 2026 candidate was told not to use AI. Other interview cycles used AI in later rounds, so this is not a universal R1 policy.

Do candidates need to finish every part?

The reports do not show a fixed rule.

• A 2022 candidate reached Part 3 and still advanced to the onsite.
• A 2024 candidate passed the simple Part 3 examples with little time left and advanced.
• Another candidate completed about 2.5 of 3 R1 parts and reached the onsite.
• A 2025 candidate finished two parts, explained the third, and later reached the manager round.
• Candidates who completed all three parts also advanced and sometimes received offers.
• One 2026 candidate completed two of three load-balancer parts and did not receive an offer, but the source did not confirm the round label or the rest of the evaluation.

Completion matters, but clean code, correct behavior, tests, communication, résumé review, later rounds, and hiring capacity can all affect the final result. The public reports cannot turn that into a scoring formula.

For the full current practice catalog, see Stripe interview questions and practice paths.