A two-part roundup of 22 firsthand Stripe New Grad engineering interviews. Part 1 contains the 19 reports published in 2026, newest first.

Some Patterns

1. Code and test. Candidates used HackerRank, another online IDE, or a local editor when allowed. They ran provided tests, wrote their own, or dry-ran examples.
2. Expect progressive requirements. Several prompts grew through three or four parts, often by adding business rules to working code.
3. Do not use part count as a pass mark. Candidates advanced or were rejected after different completion counts.
4. Explain bugs and tradeoffs. Reports mention fixing wrong output, discussing nested loops, suggesting graph cycle detection, and improving working code.
5. Response times varied. One candidate advanced within two hours; most reports did not give a decision interval.

19 candidate timelines and screens

01: AI-assisted coding and system design

Report date: August 30, 2026 · Role: Full-time new-grad SWE · Status: Not disclosed

The candidate had two phone rounds: coding and system design. The coding round used HackerRank's AI assistant for Evaluate Ordered Action Rules. Part one applied ordered rules such as BLOCK if fraud_flag and ACCEPT if trusted_partner. Part two added comparisons and AND/OR. Processing stopped at the first matching action. They found the setup and assistant speed harder than the rule logic and were unsure whether their light AI use was enough. They said the design round went well; the final outcome was not shared.

02: A short L2 payment-reconciliation account

Report date: August 10, 2026 · Role: L2 SWE · Result: Candidate said the interview went well

The candidate completed all three parts of Invoice / Payment Reconciliation and said the interview went well.

03: Three parts, a corrected bug, and rejection in Canada

Report and screen date: June 22, 2026 · Role: New-grad software engineering · Location: Canada · Result: Rejected

The candidate completed part one and dry-ran it. Their first part-two attempt gave wrong output; they changed approach, got a working result, and explained a nested loop after the interviewer asked. With little time left, they asked whether they could copy repeated code into part three. The interviewer allowed it, and the candidate said they finished in roughly four minutes. They later reported rejection. The actual prompt and decision rationale were not disclosed; in a reply they described the work as multi-part logic-building, not a named LeetCode problem.

04: Transaction-and-region tariff in Bengaluru

Report date: May 23, 2026 · Interview period: January 2026 · Role: Software Engineer (New Grad) · Location: Bengaluru, India · Overall result: No offer reported

After one 60-minute OA problem, the candidate described a 45-minute technical screen with three or four linked parts. The task determined a custom tariff using a user's transaction and region. No rule table, data format, platform, or screen-specific result was given. Later technical and debugging rounds belong to the same application, but this account supports only the narrow screen details above.

05: Four CSV requirements in a US online editor

Report submitted: April 13, 2026 · Role: Software Engineer (New Grad) · Location: United States · Difficulty reported: Moderate

The candidate wrote a function and ran their own tests in an online IDE. They validated headers, rejected empty row values, produced the third column for qualifying rows, used a set for a cross-column rule, and recognized the final field-dependency requirement as a directed-cycle problem. They explained a DFS plan but did not code that last part. They said extracting requirements and typing working logic quickly mattered more than an obscure trick. Their later repository/API integration interview was a separate stage.

06: Two questions in 45 minutes in India

Screen date: March 13, 2026 · Report date: March 14 · Role: New-grad SDE · Location: India

The candidate said they completed two questions within 45 minutes and then asked whether they would advance to virtual onsite. They did not disclose either prompt, the editor, the testing setup, or a later outcome. This report is evidence for the clock and question count, not a reconstructable question.

07: Three coding parts and a Stripe-interest discussion

Report date: February 21, 2026 · Role: New-grad full-time SWE · Location: Not disclosed

After an OA, the candidate described a one-hour phone screen with one problem that grew through three parts. They finished those parts and then discussed why they wanted to work at Stripe. They later described virtual onsite rounds, but did not disclose the phone prompt, platform, exact screen date, or final outcome. The discussion may depend on the interviewer; it is not a guaranteed segment for every screen.

08: A 2025 phone screen followed by a 2026 VO

Report date: February 20, 2026 · Role: Stripe 26NG SDE · Phone date: November 18, 2025 · Final result: Not reported

After an OA invitation in October 2025, the first interview was rescheduled or missed four times before the candidate completed the phone round on November 18. Their January 20, 2026 VO included three rounds. They finished two of three parts of Email Subscription Scheduler, about 3.5 parts of Bikemap JSON Integration, and two Mako debugging parts. An HM invitation arrived January 28, and the manager chat took place February 9. The candidate was still waiting roughly ten workdays later.

09: Three shipping-cost parts before a rejected VO

Report date: February 18, 2026 · Role: Full-time new-grad SWE · Team-screen date: December 22, 2025 · Result: Rejected January 27, 2026

The candidate completed Shipping Cost Part 1, Part 2, and Part 3. They fixed bugs while working and wrote tests for parts two and three. Part two took the most time. In the January 20 VO, Java coding was harder than expected and part two remained unfinished. A JSONParser debugging round also remained incomplete. Bikemap JSON Integration required reading a JSON file, sending the request, and checking the response. The rejection email gave no detailed reason.

10: A fee-calculator phone screen before an offer

Phone date: January 12, 2026 · Report date: February 14 · Role: Full-time new-grad SDE · Result: Offer reported February 13

This candidate received an OA in December 2025. The January phone screen covered Status Gate and Regional Rates, followed by Merchant Volume Discounts. They did not say exactly how many phone parts they finished. A January 28 virtual onsite included Email Subscription Scheduler coding 3/3, Bikemap integration about 3.5/5, and Mako debugging 2/3; they used Python. A February 9 hiring-manager round covered their resume, why Stripe, and a two-year outlook.

11: A payment phone screen, then bank transactions

Report date: February 10, 2026 · Role: Full-time new-grad SWE · Phone period: Before Christmas 2025 · Outcome: Rejected after the later loop

The candidate completed 3/3 parts of a payment phone problem. In VO they reported 3/3 on bank-transaction coding, about 2/3 on Mako debugging, and about 3.5/5 on Bikemap JSON Integration. A hiring-manager conversation followed, then a rejection about a week later.

12: Two team-screen parts and a fast US callback

Report date: February 8, 2026 · Role: New-grad SWE · Location: United States · Result: Offer reported in a later edit

The candidate said they completed two team-screen parts and were moved forward about two hours after the call. Their later virtual onsite included coding, integration, and debugging, followed by a hiring-manager conversation. They withheld the screen prompt and exact date. Their two-part advancement should not be read as a universal cutoff; other candidates had different outcomes after two or three parts.

13: Strings, arrays, and an improvement question in Dublin

Report date: February 4, 2026 · Interview period: January 2026 · Role: Software Engineer - New Grad · Location: Dublin, Ireland · Overall result: No offer reported

The candidate described the HackerRank OA as practical rather than LeetCode-like. Their first virtual interview involved manipulating strings and arrays; the interviewer helped as they worked and asked how the code could be improved. The post did not say whether that question followed a finished implementation, nor did it give the exact input, output, timer, or round-specific decision.

14: Roughly four CSV parts and a communication challenge

Report date: February 3, 2026 · Role: Software Engineer New Grad · Location: Not disclosed · Overall result: No offer reported

The candidate remembered string manipulation and CSV parsing across roughly four parts and said they finished three. The logic felt manageable to them; thinking aloud while implementing was harder. They did not give the CSV fields, required output, or exact screen date, so this is a report about work style and communication rather than a reproducible prompt.

15: Message input and malformed rows in a first screen

Report date: January 2026 · Role: New-grad SWE · Location and result: Not disclosed

This candidate described an engineering-style first interview, not a conventional LeetCode exercise. The program consumed input from a file or standard input, then processed messages. They said an expected five-token row and an empty name were edge cases to catch; knowing how to read and split input in the chosen language saved time. Their screenshot does not preserve the full message rule, output format, interview duration, or outcome.

16: A HackerRank screen with two engineers in India

Report date: January 16, 2026 · Role: Software Engineer (New Grad) · Location: India · Result: Rejected

Two engineers ran a 60-minute live HackerRank screen and explained the structure at the start. The main prompt was long and backend-flavored. The candidate implemented a solution, talked through it, and said it passed provided tests. A related follow-up also produced the expected output. The session ended before further optimization or parts; the candidate said they finished two of three expected parts and were rejected. They did not disclose the prompt or response interval.

17: Four unlocked fraud-detection levels

Report date: January 15, 2026 · Role: Full-time new-grad SWE · Result: Passed this screen

The candidate reported Four-Level Transaction Fraud Report in a 60-minute technical phone call with about 45 minutes for coding. One level unlocked the next. First came six-field CSV completeness checks. Next were amount-range and blocked-payment-method rules. The third level compared transaction behavior with a user's history and flagged matches below 50%. The last emitted at most two prioritized error codes, or OK, in an aligned report. The candidate did not give all original values or schemas; they described the long requirements as simpler in logic than in reading time.

18: A VO map built from coordinate data

Report screenshot: January 15, 2026 · Role level: Not confirmed · Stage: Virtual onsite

The coding round covered Account Balance Part 1 and Part 2: transaction fees, nonzero balances, and a rejection list. For Bikemap JSON Integration, the center was near latitude 47.579 and longitude -122.31, with a 400 × 600 map and zoom 13. Coordinates came from ride-simple.json. The first point became a start marker, the last became a Stripe marker, and the route alternated blocks of ten blue points and ten orange points. The candidate combined that with earlier data, sent a POST request, and saved the map. They also mentioned Mako debugging around a directory check and a node-visit method.

19: CSV transaction fees in a University SDE screen

Report date: January 8, 2026 · Role: General University SDE / full-time new grad · Reported status: Waitlist · Location: Not disclosed

The candidate described scheduling from open slots, then coding in a HackerRank sandbox without mandatory screen sharing; they said a local IDE could also be used with screen sharing. Their technical task was Transaction Fee Calculator — Parts 1–2: CSV transaction data with output columns for transaction ID, type, payment provider, and fee. The screenshot's sample output includes py_1,payment,card,51, py_2,payment,card,0, and py_3,payment,klarna,101, but does not preserve a complete fee rule table. They found the string processing and rule reading more time-consuming than the core calculation. After coding, the interviewer could ask about Stripe and take candidate questions; the candidate said no decision was given on the call. This account does not establish one required editor or one universal rate schedule.

Continue to Part 2: three November 2025 reports cover column verification, an MLE coding and model-integration loop, and an earlier 2026-cohort shipping-cost screen.

Related Stripe posts: 47-problem ranking · 2026 coding patterns

Thank you very much for your patience! ❤️