Stripe Software Engineer (New Grad) Interview Experience
Stripe · Entry level · Software Engineer
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.
Interview rounds · 2
- 1
Technical round
CodingTechnicalMy 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.
Q1. Parse a CSV and validate that the headers are present and non-empty.
How they answeredI 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.
Follow-up questions- What counts as an invalid header?
Q2. Validate that row values are non-empty and output the third column for valid rows.
How they answeredI 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.
Follow-up questions- What should happen if a row is missing the third column?
Q3. Validate a cross-column rule where values in one column must also appear in another column.
How they answeredThe 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.
Follow-up questions- How did you implement that check?
Q4. Detect circular dependencies between fields in the CSV data.
How they answeredAs 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.
Follow-up questions- How would you model the dependency?
- Did you fully implement the cycle detection?
- 2
Technical round
CodingTechnicalProject DiscussionThe 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.
Q1. Use the provided codebase and internal API or SDK to expose names and emails through an endpoint.
How they answeredI 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.
Follow-up questions- Where should the data be surfaced?
- How much were you expected to figure out on your own?
Q2. Process JSON data from another API and add fields to the existing output.
How they answeredThere 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.
Follow-up questions- What kinds of fields were you adding?
- Was the challenge the response handling or choosing the right API?
Q3. Choose the best endpoint or method from the available API surface.
How they answeredAt 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.
Follow-up questions- What happened when you picked a suboptimal endpoint?
Tips from the candidate
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.