Stripe

My Stripe interview process felt quite different from the usual internship interviews I had prepared for. Instead of having every stage revolve around conventional LeetCode problems, the process gradually moved towards practical programming and working with existing code. I initially received the online assessment through HackerRank. The interesting part was that the problem was structured as one larger task with several subparts. I had to process a string containing payment-related information and progressively extract and filter the required details. Each subpart added another requirement, so I couldn't simply solve four unrelated questions independently. I had to make sure that the code I wrote for the earlier part could be extended without breaking the previous functionality. A candidate reporting a Stripe internship OA described almost exactly this format, with payment information being extracted through successive filtering steps. After the assessment, I moved into the interview process. The coding interview was conducted as a pair-programming session. Rather than silently solving a problem, I was expected to communicate with the interviewer while developing the solution. The questions involved manipulating strings and data structures, and additional requirements were introduced progressively. That meant I had to modify an existing solution instead of throwing it away every time the problem changed. The final interview stage consisted of two separate sessions. The first was another programming discussion, where the emphasis remained on writing clean and maintainable code. The second was an integration-focused round. I was given an existing codebase and had to understand how different pieces worked together, debug an issue, and work with an API while referring to documentation. This was the part I found most unfamiliar because I was more accustomed to solving self-contained algorithmic problems. A reported Stripe intern candidate described the same final-round structure, including pair programming followed by an integration challenge involving an existing codebase, APIs and documentation. I ultimately did not receive an offer. My biggest takeaway was that preparing only with DSA would not have been enough for this process. I needed to be comfortable reading unfamiliar code, debugging quickly, understanding API documentation and adapting code when requirements changed. The interview itself was a positive learning experience because it felt closer to actual software development than a standard algorithm-only interview.