Stripe

I applied for the Stripe Software Engineering Intern role through an off-campus opening. I had heard that Stripe's interviews were somewhat different from the usual DSA-heavy interviews, so I was expecting more practical coding and implementation questions. That turned out to be pretty accurate. The process had multiple technical stages, and each round felt like it was testing something slightly different. The questions weren't necessarily extremely difficult from an algorithmic point of view, but the amount of information in the problem statements and the changing requirements made them challenging. Round 1: Online Assessment The first step was a HackerRank online assessment. Instead of getting two or three completely independent LeetCode-style problems, the question was more implementation-oriented. The problem involved processing and manipulating data, and the requirements were introduced progressively. At first, the task looked quite simple. There was some string and data manipulation involved, and I initially thought I could finish it quickly. But as I went through the later parts, new requirements were added that depended on the code I had already written. That was probably the biggest difference compared with the DSA contests I was used to. I couldn't just throw away my first solution and write something completely different for every part. The earlier code had to be structured properly so that it could be extended. I spent a lot of time reading the requirements and testing different edge cases. I managed to get through the assessment and received the interview invite. Looking back, I think writing more modular code from the beginning would have saved me quite a bit of time. Round 2: Pair Programming The next round was a pair-programming interview. The interviewer first explained the problem and gave me some time to understand the requirements. We then started implementing the solution together. The problem again involved manipulating data and extracting information from it. It wasn't the kind of question where knowing one particular algorithm would immediately give you the answer. The interviewer was interested in how I approached the problem. I explained what I was thinking, wrote the initial version and then tested it with some examples. After the basic solution was working, additional requirements were introduced. This was where the round became interesting. Instead of saying "now solve another question," the interviewer basically extended the original problem. I had to modify the code without breaking what was already working. I made one design decision early in the round that later made one of the follow-ups harder. The interviewer pointed this out and asked how I would change the structure. I understood the issue, but changing the implementation while keeping the previous functionality intact took some time. The interviewer was helpful throughout the process, and the conversation felt more like actually working through a programming task with another engineer rather than being interrogated. I was able to get most of the functionality working, although I wasn't completely satisfied with the final version. Round 3: Final Technical Round The final stage was a two-hour technical interview, split into two one-hour sessions. The first session was another pair-programming-style coding problem. By this point, I had a better understanding of what Stripe expected. I focused more on writing clean code instead of immediately trying to optimize everything. The problem again involved manipulating and transforming data. There were multiple stages to it, and each stage added another requirement. One thing I noticed was that the interviewer cared about code quality and maintainability. They asked questions about why I had chosen a particular data structure and how I would change the implementation if the input became much larger. There were also discussions around edge cases. I had initially assumed that the input would always be valid, but the interviewer asked what would happen with missing or malformed data. That forced me to go back and make the code more defensive. The second one-hour session was probably the hardest part of the entire process. It was an integration challenge rather than a traditional DSA problem. I was given an existing codebase and had to understand how it worked before making changes. There were APIs involved, along with documentation that I had to read while working through the problem. The task involved taking data from one part of the system, making the required API interaction and then processing the response correctly. At first, I spent too much time trying to understand the entire codebase. Eventually I realized that I only needed to understand the specific parts related to the task. I started tracing the existing functions and then worked on the required changes. The debugging part took a significant amount of time. I had a situation where my code looked correct, but the output wasn't what I expected. I went through the data flow step by step and eventually found that I had misunderstood one part of the existing implementation. By the time I fixed it, there wasn't much time left. I managed to get a significant part of the integration working, but I couldn't finish everything before the session ended. What I Struggled With The biggest challenge throughout the process wasn't really advanced DSA. It was understanding requirements quickly and writing code that could survive follow-ups. In competitive programming, I'm used to seeing a problem, identifying an algorithm and writing the solution. Stripe's process felt different because the interviewer kept changing or extending the requirements. For example, a solution that works perfectly for the first version of the problem might become difficult to extend if the code is poorly structured. I also realized that I wasn't as comfortable as I thought with reading an unfamiliar codebase. The integration round especially exposed this. I had worked with APIs and backend projects before, but doing it under interview time pressure while simultaneously understanding someone else's code was different. I also spent too much time trying to make the first version perfect instead of getting a clean working implementation and then improving it. Result After the final round, I waited for the result. Unfortunately, I wasn't selected for the internship. Even though the result wasn't what I wanted, I actually found the interview process quite useful. It felt much closer to the kind of work a software engineer might do in a real project compared with a normal DSA interview. The biggest lessons for me were to write modular code from the start, communicate while coding, test edge cases continuously and become more comfortable working with unfamiliar codebases. I also realized that knowing DSA alone isn't enough for every software engineering interview. Being comfortable with data processing, APIs, debugging, reading documentation and modifying existing code can matter just as much. Overall, it was a challenging process, but definitely one of the more interesting internship interviews I had gone through.