
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 rounds
7 questions across 2 roundsTechnical interview (1)
4 questionsOverview
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.
Technical interview (2)
3 questionsOverview
The next technical was Stripe's integration-style round. They sent me a decent-sized repo with docs, and I was allowed to use the internet and look up libraries. This one felt more like figuring out tools and wiring than pure coding. I talked with the interviewer a lot more in this round, and they would nudge me if there was a better endpoint or API to use.
Question types asked
Specific questions asked
Use the provided codebase and internal API or SDK to expose names and emails through an endpoint.
Where should the data be surfaced?
How much were you expected to figure out on your own?
I had to work in their existing repo, call the provided API, get data like names and emails, and expose it through an endpoint so I could see it from the command line. The hard part wasn't writing code. It was figuring out what to call, what tools to use, and how I wanted to wire it together from the existing code and docs.
Process JSON data from another API and add fields to the existing output.
What kinds of fields were you adding?
Was the challenge the response handling or choosing the right API?
There was another task where data came from another API as JSON, and I had to process that response and update the output with more fields, something like phone numbers. For me the harder part was choosing the right method or endpoint from what was available, not the actual coding. It honestly felt more like design than coding.
Choose the best endpoint or method from the available API surface.
What happened when you picked a suboptimal endpoint?
At one point I picked something that technically returned the data I needed, but the interviewer hinted there was probably another endpoint that would do it better. The difference was basically that my choice returned less of what we needed or wasn't the cleanest path. I came away feeling like I just hadn't looked hard enough through the SDK and docs.
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.
Get full access with a membership, or share your experience to try it free.
More Stripe interview experiences

“Online assessment was not difficult but super lengthy. The question was closer to the actual problems stripe works on.”

“I have completed the Online Assessment as of now and I am waiting for my results. The most important thing is to practice reading comprehension and extracting the necessary rules/constraints and using them properly within time constraints. Doable with enough practice.”