Updated by Stripe candidates
Software Engineer (New Grad) Interview Experience
When they wrote that one column depends on another, I pretty much immediately jumped to cycle detection and modeled it as a graph. There was a lot of reading involved, but the solutions themselves were mostly brute force and straightforward.
Interview process
The biggest thing that stood out was how little it felt like normal LeetCode. The first technical was a long CSV parsing and validation problem with multiple parts, and the real skill was extracting the actual problem from all the words and then implementing simple logic quickly. The next round was an integration repo round where I had to read unfamiliar code, figure out which APIs or endpoints to call, and wire data into an endpoint and CLI output. That one felt more like design than coding to me. Overall I liked the style more than typical coding screens because it was straightforward, but you do need to read fast, type fast enough, and stay calm with ambiguous real-world setup.
- Technical interview
Interview tips
I'd prep for Stripe by practicing wordy, real-world parsing problems instead of only grinding LeetCode. For the coding round, don't overthink it. My solutions were pretty brute force, and that was fine. The bigger thing is reading carefully, extracting the rules, and explaining your process while you code. For the integration round, get comfortable reading a repo, skimming docs, choosing between similar endpoints, and talking through why you're using one API over another.
Company culture
They're testing whether you can work through realistic engineering tasks, not whether you know some obscure trick. The coding round was very requirement-driven and pretty straightforward if you read carefully. The integration round felt even more like actual work: read the codebase, use the docs, pick the right SDK or endpoint, and stitch things together cleanly. They even allowed internet access, which tells me they're fine with a more real-world setup. The interviewers didn't seem obsessed with optimization. They mostly wanted a working solution, clear articulation, and evidence that you could navigate their tools without getting lost.
Questions asked
Overview
My first technical was in an online IDE and it was way more about reading a long Stripe-ish problem carefully than doing some tricky LeetCode thing. The whole thing was a CSV parsing and validation prompt with four parts that built on each other. My interviewer was pretty straightforward and mostly let me implement what was written. I had to write the function myself and run my own tests.
Specific questions asked
Parse a CSV and validate that the headers are present and non-empty.
What counts as an invalid header?
I treated consecutive commas in the header row as invalid because that meant a header was missing. My check was basically that every header needed at least one non-space character. It was very straightforward, not tricky, and I just talked through the cases while coding.
Validate that row values are non-empty and output the third column for valid rows.
What should happen if a row is missing the third column?
I went through each row and made sure the values weren't empty. Then I displayed the third column for each valid row. If that third column wasn't there, I just omitted that row from the output. It felt like simple data cleaning and validation, just with a lot of words in the prompt.
Validate a cross-column rule where values in one column must also appear in another column.
How did you implement that check?
The prompt gave a plain-English rule like making sure values in one column also appeared in another one. I used a set and did it pretty brute force. That was accepted. The round felt like they just wanted a working solution and a clear explanation, not some optimized fancy answer.
How would you model the dependency?
Did you fully implement the cycle detection?
As soon as I saw that one field depended on another field, I jumped to a graph. I explained that I'd model it as dependencies between fields and do cycle detection, basically DFS on a directed graph. I didn't fully code that part. I explained it pretty explicitly, and that was fine. To me it was easy once I mapped 'depends on' to a graph problem.
Get full access with a membership, or share your experience to try it free.
