Ask New Question
Sign In
Quora uses cookies to improve your experience. Read more
What is the engineering interview process like at Stripe?
Answer Wiki
1 Answer
Update (April 21, 2015): For a description of the latest iteration of our interview process, see https://stripe.com/jobs/engineer....
We've redesigned our interview process several times, as we've learned what works well and what doesn't. The most recent iteration was designed by Siddarth Chandrasekaran, Evan Broder, and me back in May 2013 [1].
Our interviews try to simulate the work you'd do on a day-to-day basis. We don't ask any purely algorithmic questions — no project at Stripe has ever required writing a red-black tree from scratch. We're also perfectly okay with people Googling around or collaborating with their interviewers.
We start off with a coding interview over Skype. We generally do the actual coding over Skype screen sharing so that you can write in your favorite editor (you're also free to use your language of choice). The questions we ask are intended primarily to test what we call a person's "thought-to-code compiler". Namely, it's always fairly clear how a human would go about solving our problems, but the challenge is in writing clean, maintainable code to implement the relevant functionality. Simply writing correct code isn't enough — the most common reason for doing poorly on this interview is not having a strong enough intuition around what makes for good code.
Our on-site interviews consist of the following components:
While we're doing the technical assessment, we pay attention to what it's like working with you. In general, we look for high-bandwidth, enjoyable communication.
At the end of the process, we apply a few tests:
Each hiring decision requires everyone at Stripe to (at least implicitly) be on board. Hiring meetings are open to everyone at Stripe (though in practice usually just the interviewers attend), and anyone can veto a hire. That way everyone feels invested in each new hire joining the team, and no one can claim someone else was hired unfairly.
One important aspect of any process is how you measure its success. In the long run, the main thing we care about is that we're building a great team. It's certainly hard to assess that definitively, but our litmus test is whether engineers continue to join Stripe simply because of the people. Putting a candidate at a lunch table with a handful of Stripes has been our best selling strategy to date. As long as that continues to be the case, we know that we're building the right team.
[1] We'll frequently change the interview process for particular candidates, whether to get additional signal or to handle people's constraints. So if you're interviewing with us, you shouldn't worry if your interview process diverges from what I describe here.
We've redesigned our interview process several times, as we've learned what works well and what doesn't. The most recent iteration was designed by Siddarth Chandrasekaran, Evan Broder, and me back in May 2013 [1].
Our interviews try to simulate the work you'd do on a day-to-day basis. We don't ask any purely algorithmic questions — no project at Stripe has ever required writing a red-black tree from scratch. We're also perfectly okay with people Googling around or collaborating with their interviewers.
We start off with a coding interview over Skype. We generally do the actual coding over Skype screen sharing so that you can write in your favorite editor (you're also free to use your language of choice). The questions we ask are intended primarily to test what we call a person's "thought-to-code compiler". Namely, it's always fairly clear how a human would go about solving our problems, but the challenge is in writing clean, maintainable code to implement the relevant functionality. Simply writing correct code isn't enough — the most common reason for doing poorly on this interview is not having a strong enough intuition around what makes for good code.
Our on-site interviews consist of the following components:
- Design and implementation (90-120 minutes). We ask you to design some system (such as an API, web interface, or a distributed system — we try to tailor the question to your expertise), and then produce a prototype of your system. For this, we try to observe how you solve a problem end-to-end: thinking through requirements (whether user requirements or technical), coming up with a solution, and then actually making that solution exist. You should build this as if you were going to put it into production: optimize for code quality over quantity, write tests as appropriate, and so on. It's fine if you don't actually finish.
- Bug squash (45-60 minutes). We hand you a popular open-source project along with a failing test case for some bug. Your task is to fix the bug (or make as much progress as you can towards doing so). We're looking mostly to see how you handle navigating an unfamiliar codebase and fixing problems in other people's code.
- Refactoring (45-60 minutes). We give you a simple application that is in dire need of improvement, and we ask you improve the structure. Here, we're mostly trying to measure your ideas around what makes for good code.
- Pair programming (30-45 minutes). We give you a small, self-contained project. Importantly, the project is always solvable in pure code — we don't want you to spend time fumbling with libraries. Again, we look for a clean, maintainable implementation. We try to assess your ability to produce code when the constraints are very clear.
While we're doing the technical assessment, we pay attention to what it's like working with you. In general, we look for high-bandwidth, enjoyable communication.
At the end of the process, we apply a few tests:
- Excitement test. Would hiring this person make you more excited about working at Stripe? Each person we hire should make the company fundamentally better in some way. It's not enough to be excited about finally having someone to maintain some unloved system — the person needs to genuinely add something beyond pure human-hours.
- Velocity test. Would this person be on a trajectory to be self-sufficient within 6 months of joining Stripe? We hire a variety of engineers, some very far along in their careers and some just getting started. While we hire a variety of skill levels and we want to provide mentorship and guidance to everyone, we also want to ensure everyone is capable of guiding their own work. If we can't picture an engineer being at that level within the first 6 months, then they aren't on a sufficiently high-velocity track for us.
Each hiring decision requires everyone at Stripe to (at least implicitly) be on board. Hiring meetings are open to everyone at Stripe (though in practice usually just the interviewers attend), and anyone can veto a hire. That way everyone feels invested in each new hire joining the team, and no one can claim someone else was hired unfairly.
One important aspect of any process is how you measure its success. In the long run, the main thing we care about is that we're building a great team. It's certainly hard to assess that definitively, but our litmus test is whether engineers continue to join Stripe simply because of the people. Putting a candidate at a lunch table with a handful of Stripes has been our best selling strategy to date. As long as that continues to be the case, we know that we're building the right team.
[1] We'll frequently change the interview process for particular candidates, whether to get additional signal or to handle people's constraints. So if you're interviewing with us, you shouldn't worry if your interview process diverges from what I describe here.
204.8k Views · 1,345 Upvotes · 1,344 Upvotes · Answer requested by Patrick Collison, Kai Liu, and 1 more
Thank you for your feedback!
Your response is private.
Is this answer still relevant and up to date?
YesNo
View More Answers
Related Questions
Still have a question? Ask your own!