This is Kristen O'Brien, Managing Editor at NFX, and this is the founder list. Audible versions of essays from technology's most important leaders selected by the founder community. Greg Brockman, former CTO at Stripe, and now chairman CTO at Openai, describes the intricate interview process they developed for engineers back when Stripe was in hyper growth mode pulled from a Morgan post. Red by NFX. What is the engineering interview process like at Stripe?
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 Sidarth Chondressikaran, Evan Broder, and me back in May 2013. Our interview try to simulate the work you 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 to a 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 the solution and then actually making that solution exist. You should build this as if you were going to put it into production. Optimized for code quality over quantity, write tests as appropriate, and so on. It's fine if you don't actually finish. Bug squash 45 to 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 code base and fixing problems in other people's code. Refactoring 45 to 60 minutes. We give you a simple application that is in dire need of improvement. And we ask you to improve the structure.
Here, we're mostly trying to measure your ideas around what makes for good code. Finally, pair programming. 30 to 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 Pete 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 Currier, and others 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 six 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.
For more audio essays from the people who've built companies like Instacart, Facebook, Trello, HubSpot, and Dropbox, visit the founder list at nfx.com, or subscribe to the nfx podcast at podcast.nfx.com, or wherever you get your podcasts.