There are 2 main rounds (excluding recruiter call) which are the phone technical and onsite (which is virtual now).
The phone technical is your typical coding problem, I’d say maybe LC medium. The question would be broken into about 2/3/4 parts (at least that was what the recruiter told me and my experience), and the goal is to get a working solution for as many parts as you can, while also explaining your thought process and the usual coding interview stuff ofc. So bottom line is don’t focus too much on getting the most efficient solution, once you think of something just start coding it up. The interviewer might ask you to make it more efficient as a follow up, or they might just ask another question that builds ontop of that. The problem imo is that they don’t tell you how many parts, so if you only did 2 for example, you don’t know if there are just 2 parts or maybe 3/4, so try to move quickly. Also, write as much tests as you can and think of edge cases.
The onsite has 5 interviews: a. Manager interview - this one walks through your resume, and the manager(s) ask questions about some projects you have worked on, they also ask some behavioral questions, and general questions like why Stripe? Why are you looking for a new job? etc. Nothing surprising here, just try to think of like 2/3 interesting projects you want to talk about before the interview, what your role was, what technical difficulties you ran into, how you solved them etc.
b. Coding - this is the same as phone technical.
c. System design - typical system design interview. Lots of focus on scalability so no surprises here if you’ve done system design interviews before.
d. Integration - this will probably vary depending on whether you’re backend, frontend, mobile etc. But the idea is for you to integrate something to a codebase they give you. For backend I believe it’s usually about making HTTP requests in the language of your choice. The goal is to make the addition/whatever is asked of you work, while explaining your thought process to the interviewers.
e. Bug squash - this will also vary depending on the role, but the idea is that they give you some huge library/project (I believe they’re almost always open source), and they ask you to fix an actual issue that was filed in the past for the library. This is also based on the language of your choice. I believe they always write unit test to help you catch the bug but I don’t know for sure. The goal of this round is to evaluate your debugging skills and how you approach fixing bugs. Since this is a huge repo, what you definitely don’t want to do is just read files randomly, this is where you need to apply some IDE knowledge (you get to use any IDE you want), like setting breakpoint, jump to implementation etc. They usually say that fixing the bug isn’t the main focus of this but I’d say try to get it fixed if you can but overall just approach the bug systematically rather than just jumping randomly from file to file.
For all the interviews, you’re allowed to use Google (or Bing haha), StackOverflow, docs, etc whatever you need.
I thought the integration and bug squash rounds were more interesting and more relevant than just solving a bunch of algorithm questions but then this was the only company(out of 4 onsites) that I didn’t get an offer from so maybe just solving algorithm questions is better after all :)
comments
The phone technical is your typical coding problem, I’d say maybe LC medium. The question would be broken into about 2/3/4 parts (at least that was what the recruiter told me and my experience), and the goal is to get a working solution for as many parts as you can, while also explaining your thought process and the usual coding interview stuff ofc. So bottom line is don’t focus too much on getting the most efficient solution, once you think of something just start coding it up. The interviewer might ask you to make it more efficient as a follow up, or they might just ask another question that builds ontop of that. The problem imo is that they don’t tell you how many parts, so if you only did 2 for example, you don’t know if there are just 2 parts or maybe 3/4, so try to move quickly. Also, write as much tests as you can and think of edge cases.
The onsite has 5 interviews:
a. Manager interview - this one walks through your resume, and the manager(s) ask questions about some projects you have worked on, they also ask some behavioral questions, and general questions like why Stripe? Why are you looking for a new job? etc. Nothing surprising here, just try to think of like 2/3 interesting projects you want to talk about before the interview, what your role was, what technical difficulties you ran into, how you solved them etc.
b. Coding - this is the same as phone technical.
c. System design - typical system design interview. Lots of focus on scalability so no surprises here if you’ve done system design interviews before.
d. Integration - this will probably vary depending on whether you’re backend, frontend, mobile etc. But the idea is for you to integrate something to a codebase they give you. For backend I believe it’s usually about making HTTP requests in the language of your choice. The goal is to make the addition/whatever is asked of you work, while explaining your thought process to the interviewers.
e. Bug squash - this will also vary depending on the role, but the idea is that they give you some huge library/project (I believe they’re almost always open source), and they ask you to fix an actual issue that was filed in the past for the library. This is also based on the language of your choice. I believe they always write unit test to help you catch the bug but I don’t know for sure. The goal of this round is to evaluate your debugging skills and how you approach fixing bugs. Since this is a huge repo, what you definitely don’t want to do is just read files randomly, this is where you need to apply some IDE knowledge (you get to use any IDE you want), like setting breakpoint, jump to implementation etc. They usually say that fixing the bug isn’t the main focus of this but I’d say try to get it fixed if you can but overall just approach the bug systematically rather than just jumping randomly from file to file.
For all the interviews, you’re allowed to use Google (or Bing haha), StackOverflow, docs, etc whatever you need.
I thought the integration and bug squash rounds were more interesting and more relevant than just solving a bunch of algorithm questions but then this was the only company(out of 4 onsites) that I didn’t get an offer from so maybe just solving algorithm questions is better after all :)
Good luck OP.
😁