Log In
Sign Up
Back to interviews
Added by Anonymous

Software Engineering Intern

at Stripe

Rating
2
Review
The process started with a 60-minute HackerRank, which they described as being marked on the quality of code written, rather than the speed/efficiency of the code, or time to complete the tasks. I’m unsure if this was judged automatically, or if the code for each applicant was manually reviewed for “quality” or neatness.
The next round was a 60-minute “technical team screen”, which took place over video call with one engineer. I was allowed to use my own coding environment/IDE, and the problem was split into 4 parts. It was made clear at the beginning that the interviewer did not care about optimisation, Big-O/efficiency, they just wanted neat and readable code, following good coding practises.
Each part of the problem took about 10 minutes to code + test, and the interviewer was kind and helpful, pointing out minor errors such as missing syntax or having index references off by +/-1 etc. After solving each part of the problem, I was asked about different edge cases and how my function might not handle them correctly, and to give examples of edge cases I could think of where this might be the case. I was also asked how I would (theoretically) handle them.
The interview finished with the opportunity to ask a couple of questions and was then wrapped up. I didn’t make it past this interview, I think due to how I approached one of the parts in a not particularly neat or intuitive way. I would recommend focusing on having an elegant solution over one that is quick to type.
I didn’t have time to finish the final part of the question, but the interview did not mind at all, so it isn’t a problem if you take your time and can’t finish in time, the quality of the code is more important.
Back to interviews
Added by Anonymous

Software Engineering Intern

at Stripe

Rating
2
Review
The process started with a 60-minute HackerRank, which they described as being marked on the quality of code written, rather than the speed/efficiency of the code, or time to complete the tasks. I’m unsure if this was judged automatically, or if the code for each applicant was manually reviewed for “quality” or neatness.
The next round was a 60-minute “technical team screen”, which took place over video call with one engineer. I was allowed to use my own coding environment/IDE, and the problem was split into 4 parts. It was made clear at the beginning that the interviewer did not care about optimisation, Big-O/efficiency, they just wanted neat and readable code, following good coding practises.
Each part of the problem took about 10 minutes to code + test, and the interviewer was kind and helpful, pointing out minor errors such as missing syntax or having index references off by +/-1 etc. After solving each part of the problem, I was asked about different edge cases and how my function might not handle them correctly, and to give examples of edge cases I could think of where this might be the case. I was also asked how I would (theoretically) handle them.
The interview finished with the opportunity to ask a couple of questions and was then wrapped up. I didn’t make it past this interview, I think due to how I approached one of the parts in a not particularly neat or intuitive way. I would recommend focusing on having an elegant solution over one that is quick to type.
I didn’t have time to finish the final part of the question, but the interview did not mind at all, so it isn’t a problem if you take your time and can’t finish in time, the quality of the code is more important.