How Stripe does engineering interviews
quora.com
quora.com
The way these tech interviews are going we'll all end up being sole traders as none of us will put up with these ridiculous parlour games.
Just chatting with my girlfriend, she pointed out that we can hire lawyers, doctors, and surgeons on the back of a CV and an hour interview. So how did we get into this crazy mess over hiring programmers?
* Yes, I really do want to fill my company with people who want to be there 24x7, for many reasons, least of which are the fact that such people exist in large quantities, and while it's not a guarantee they'll put in more work-per-dollar, it's a safe bet that they will.
* If what you're saying were true about "sole traders", then Google, Stripe, and all the companies who play these "rediculous parlor games" would not be staffed, and yet they are. So clearly, that's an inaccurate prediction.
* Your girlfriend listed professions which come with multi-year vetting built-into the system. No such system exists for programmers, especially, considering some of your best talent is going to have dropped out of college. When you get an applicant for a software dev position, they could be effectively anybody.
If you're not willing to play the game at the level other folks are playing, you will need to bring something else to the table to compensate. That's that.
No, you don't. This is naive. Human beings aren't computers.
There is no constant output per hour of work. It's nonsense. The output per hour of work depends entirely on the state of mind and physical condition of the employee.
If the employee is well-rested, healthy, and happy, they will be quite productive.
If they are sleep-deprived because they stayed at the office until midnight, depressed because they have nobody to share their life with, and physically exhausted or sick because they haven't taken time off in years ... you really think they will produce the same output as well-rested, happy employees? No. They won't even produce a quarter. In fact, they will make mistakes that will end up costing you on top of whatever it is that you're paying them.
You know what it is? I get paid money to play with computers. As much as I want to think of what I do as work, I come back to the fact that I'm lucky enough to have made my hobby a profession. Do I think that everyone in technology is in the same boat? No. Not by a long shot. But would I happily swing by on a Sunday to help a coworker with a problem, you bet. I love hard problems. Hard problems I get to solve by using technology are even better. I choose to surround myself with those individuals who feel the same way, I don't see why that is a bad thing.
But you know what else is awesome? Spending time with my wife, gardening, hiking, traveling, biking, eating, exploring, wine, beer, home improvement, etc.
So yeah, I will never come to the office just to hang out with someone...especially on a sunday. But I'll get my work done and help others get their work done and it will be good work. I just won't do it on a sunday.
- Ok, a year and a half ago I worked 43 straight 10+ hour days because I really believed in what I was doing. Chances of me ever doing that again voluntarily? Basically nil. Life's too short and spending so much of it in front of a screen...yuck.
I rather work on learning about Minix, Linux Kernel, 3D graphics rendering, compilers, Bioinformatics than messing with some config file because a production server was upgraded from Stack 1.1 to 1.11 over the weekend.
Company's goal is to serve the business no matter how intellectual my co-workers may be or the technology involved. My goal is to learn for the fun of it.
Your presupposition the sick guy is how everyone will become if they work an hour over 40 with any regularity is just plain not true. There are people who are at a point in their careers and lives which allow them the ability to invest more time and energy into work in a regular and patterned way than others. It's frankly naive to think there aren't people out there who want to be at work, and can be at work for more than the 9-5 grind each week.
Do the sickly people exist? Yes. Can you be happy, healthy, and work 60 hour weeks while still loving your job? Yes.
No.
I haven't met a single person who works 60 hours a week and is thrilled about it, outside of those who work for themselves. When you work for yourself, yes, it's definitely possible. That's not what we're talking about.
On top of everything, we're primarily talking about young people. A young person needs to invest a lot more time into their non-work life. Relationships, friends, acquiring property, family, hobbies, sports, etc. I can go on. All of those things are important and require time.
There's a reason you see depression threads pop up here on a constant basis. A healthy work/life balance is important!
You get everything you're saying a young person needs, and you also work 60 hours a week, without even realizing it.
That's the kind of environment worth fostering.
If you're chilling, you're not working, are you? It's one or the other. Highly technical work requires concentration, not banter.
> Work is life, and your relationships are balanced by virtue of the fact that you're actually friends with the people you work with.
Spoken with true inexperience. You've never worked with friends before. Not people who you hang out with. Those are not friends. Friends.
You will quickly find that your personal relationship will strongly conflict with your professional one. It will become a nightmare.
> You get everything you're saying a young person needs, and you also work 60 hours a week, without even realizing it.
Are you also fucking your co-workers too? Not a good idea.
> That's the kind of environment worth fostering.
Sounds like hell. I'll pass.
I'd like to take the time now to point out that your personal experience is not a universal key to the truth. You have a very, very tiny view into what does and does not work, and if companies believe as I do, then they're going to hire as I would. This isn't a, "here is what I think might work", this is a "here is an explanation of why people think this way".
Besides, if you don't believe what I've written works, then how do you square the unmitigated success of companies who hire as I've outlined? Maybe the problem in your experiences, the singular constant, was you (and that's okay). Maybe you just don't work well in that environment.
One of the biggest reasons you don't want this as an employer is the employee has no time to grow personally and pursue things on his own time.
Many, many people crave working in places like this, and with people who want to experience this. Apparently Stripe is one of those places. Apparently not everyone wants to work like this.
I do. They do. Who are you to tell us we can't work like that, and hire people who also want to work like that?
-People will get burned out. But instead of having a place to seek refuge (friends outside of work) the only place they have to go is the very place that is causing it, creating a negative feedback loop. Don't get me wrong, having co-workers who are friends are great, but it shouldn't be a requirement of the job. If work crew is small enough it may work for some length of time, but your theory on everyone being friends breaks down, somewhere I'd wager above 5 people.
-I've met extremely smart people who are great to work with in the sense they can get stuff done in a timely manner, but who prefer to stay in with their family or be home for dinner, you are missing out on great candidates like that.
-The biggest thing for me however, is the importance of giving programmers free time. We're in a fast moving world, and to only be able to focus on one subset is damaging to a persons professional growth. People should have the spare time to pursue things on their own, 40 hours is barely enough, 60 you can forget it.
Let me rephrase this for you: what I'm describing works. Period. This isn't some navel gazing here, it's an explanation of how companies like the submission company and others succeed. This isn't a case of, "let's all give our opinions on what might work and what might not work" this is, "let's give our opinions on why this already works."
So with that in mind, your argument simply doesn't mesh with reality. Sure, people such as you describe exist, but people such as I describe are giving interview outlines on Hacker News, and we're commenting about it.
You're saying what should and shouldn't be, but at the same time you're saying you're not telling me what I can and can't do. Those are dichotomous - pick one.
>* Yes, I really do want to fill my company with people who want to be there 24x7, for many reasons, least of which are the fact that such people exist in large quantities, and while it's not a guarantee they'll put in more work-per-dollar, it's a safe bet that they will.
You obviously have never witnessed or have burnout yourself. That "want to be in the office 24x7" will easily become an implicit rule and eventually everyone involved will burnout. I've seen that myself. It takes maturity to come to terms with the fact that you can't work all the time.
So yes, even aware of burnout, I would still want to fill my company with people who want to work more than 40 hours a week.
This may be a twisted analogy, but I think of work in a way similar to how one properly cages a dog. Some people make cages a place of punishment for their dog; break a rule, be disruptive, and you enter the cage, which is far away from all happiness or socialization. It's a place for bad dogs. It makes the cage a hugely negative place for the dog, and causes all kinds of anxiety and trouble.
The solution? Make the cage an everyday and normal part of the dog's life. Put the cage in the middle of a high-traffic area, leave the door open so the dog can go rest in the cage when it's tired, make the cage a comfortable and happy place for the dog, and it becomes much easier to put the dog into the cage when the time calls for it (company, leaving the house, etc.).
Work should be thought of similarly. It can be your 9-5 cage, or it can be a place you come and go, a place to willingly spend free time, a social experience where you interact with cool and interesting people who you'd hang out with even if you didn't work with them. In both cases, you have to be there 9-5, but in the latter case, you actually want to be there, and it's not associated with huge Dilbertesque negatives.
So when someone talks about "I want people who want to be there 24x7", they're talking about having a cage that isn't for bad dogs, but a part of their everyday doggy life.
While some may choose to work weekends (or go to Mars), you shouldn't confuse the consideration of a hypothetical scenario with an implied workplace policy.
Lets say for whatever reason, this person is in the office on a Sunday. Does the idea of going and working with that person, all by yourself, sound terrible? If you can't be with that person all alone, there's no reason that they should be part of your team.
As a lot of people have noted, the test has nothing to whether you'll actually work on a Sunday (most people don't). Instead, it's about whether you'd go out of your way to be around that person. Like it or not, we all spend lots of time around all of your coworkers, and I for one want to work with people who make me happier for it.
I don't think these problems are actually easier in other fields. Both my parents are physicians, and over the past few years they've been having a lot of trouble hiring the right coworkers. Many of the ones they've ended up with have either ended up not being very good, not being that pleasant, or not being very invested in the role. Ultimately these hiring mistakes have caused a ton of friction and problems for the entire staff, and it's pretty clear that there's something wrong with the initial hiring process.
Likability means nothing, unless your hiring a sales guy or someone going to be in the public eye. I know who on the team is adding max value and who isn't it has nothing to do with my subjective view of how cool they are.
(Off the top of my head, "the Drink test" with the description "If this person were alone at the bar/cafe on a Sunday..." is better.)
You can do that with programmers too. And depending on the type of work you are hiring for, this can be sufficient.
Menial product maintenance is suitable for one-hour interview hires. Routine legal and medical work likewise.
But some work is so demanding that it requires a team. Hiring for a team means recognizing group dynamics. Whether you're starting a new law firm, or hiring someone to join your surgical department, or building a development team that must be able to respond quickly and effectively to changes to a startups understanding of the landscape, you don't settle the hiring question on a one-hour interview.
Not all work is the same. Please refrain from acting as if it was.
This kind of interview seems like it will do a better job of hiring great engineers, rather than just hiring the "smartest" person. I think a problem that lots of major tech companies have today is that they've only hired people who are "book" smart vs "street" smart. (If that makes any sense to you in the realm of programming).
(I agree that soft skills are critical, though. I work at Stripe, and part of the reason we picked this set of interviews is to assess those soft skills in something as close to a real-life situation as can be approximated in a few hours.)
That said, their interview process was all fiddly little tests, although since they were in the habit of hiring arts students and training them to code, particularly philosophers who'd done a little formal logic, they weren't about "algorithms", more just little brain teasers with simple, made up languages, and follow up questions like "could you make this any faster?"
But I don't like the notion of going to work on a Sunday, that's something I would never do unless the company is going to go under (or if it was my company).
I'm also curious on how the whole team can be involved in a hiring decision. That's seriously a lot of time spent - on each candidate!
The post has since been updated, but I'll just copy it here: This isn't about actually coming in on a Sunday (most people don't) — it's to determine if this is someone who is so impressive and so nice that others actively want to be around them.
Also, as mentioned in the post, usually just the interviewers attend the meeting to make a hiring decision. In the case that someone didn't interview a candidate, but knows him or her in some other way, we want to make sure this person can also join in, if wanted.
2. I really enjoy those brain-teaser algorithmic interviews, but I recognize that they don't test skills that will be used every day. I don't see the contract-to-hire alternative that is always discussed on these threads as a attractive alternative to me as an employee. The interview described by the Stripe CTO sounds like a good way to test real-world skills without the huge time commitment of contract-to-hire.
3. This interview process sounds like much more work to set up than algorithmic brain teasers, especially since they tailor the projects to each person.
I'm not saying you need to spend more than five hours with a candidate though it's not an obscene amount of time to vet out a person.
This doesn't make sense to me. Customers don't know or care what your code looks like, they just want your product to work.
readable code is more likely to be correct, but correct matters a whole lot more than readable. How many times have you had to hack on JSON serializer internals or HTTP layer implementation details or database drivers or filesystem I/O. Probably never, and if you did take a peek, you would not be thrilled, because a lot of that stuff was written 15+ years ago.
readable code is a tool that good engineers use to arrive at correct code, especially in cases where we haven't iterated with the product owners enough to know what the correct logic is, or domains where the requirements are not well defined. But correct code is the goal.
This can also explain why some of the very best programmers insist on using category theory and monads even though it is infamously difficult for untrained programmers to read.
FWIW my perspective is large enterprise webapps implementing complex and poorly-defined business rules. Not like I'm doing linear algebra or device drivers.