Hacker News new | comments | show | ask | jobs | submit login
How Stripe does engineering interviews (quora.com)
110 points by christinac 1309 days ago | hide | past | web | 48 comments | favorite



Stop trying to blur the lines between you, the company, and me the employee. Nothing would make me come into the office on a Sunday and 'hang out' with another employee. Do you really want to fill your company with people who want to be there 24x7?

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?


There's just so much wrong with your short little comment here, I've rewritten my own comment four or five times trying to capture it all. Here's the bulleted list:

* 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.


> Yes, I really do want to fill my company with people who want to be there 24x7

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.


That's the thing - I'm not sleep-deprived (except on occasion by choice) and I'm quite healthy and happy. I like to think I'm reasonably productive. Sure, output depends on how I'm feeling, but I still would rather be working than not.

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.


Playing with computers is awesome. Coding is awesome. It's always a huge boost to put something new out to the world. It's great.

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.


There is a difference between coding on my own vs. coding for company.

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.


That's such a strawman! No one wants a depressed, exhausted, sick worker, and no one has ever suggested such a worker would be better to have than a 9-5 happy and healthy person.

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.


> 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!


If work is life, if you hang out with your coworkers outside of work, if you come in on Sunday to chill with a colleague, then your argument isn't relevant. Work is life, and your relationships are balanced by virtue of the fact that you're actually friends with the people you work with.

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 come in on Sunday to chill with a colleague

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.


Seconded. Also, I should add that your co-workers aren't your friends. What I mean isn't that you can't make friends at work but rather in a high turnover-prone industry as IT, your friendship might not survive a layoff or a switch to a new job when a bulk of your friendship was founded on the premise of you working together. So going out for lunch or drinks after works takes no additional planning and are just matters of convenience.


You've ripped my paragraph apart and addressed each thing I said without the context of the other things I've said. For best comprehension, I do not recommend doing that.

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.


It's an easy way to get burned out. If the employee is good enough, he or she should be able to accomplish what they need to in a 40 hour week. If it takes 1.5x as long then they aren't cut out for it, or the employer is over working them. Occasionally it's OK to work more then 40 hours for milestones but every week is ridiculous.

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.


If you work with the same people you socialize with, work and leisure starts to blend. You think of your office as a place to be around your friends, and you think of your work as a problem you and your buddies figure out together.

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?


It's a bit idealistic, but I'm certainly not telling you what you can or can't do. I can only speak to the effects I've observed from working in similar environments (most of this is anecdotal so take it as you will):

-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.


This just sounds like a rationalization that comes from not being able to/not wanting to do the things other are able to/like to do. I'm talking in trends, and you're talking about specific people you've met, which is orders of magnitude more prone to sample error.

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.


I don't think the Sunday test means they're trying to fill the office with people with no lives, if anything, I think to be a likeable person you need to have some social life.

>* 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.


24x7 is hyperbole. No one literally wants to be there 24x7, but some people want to be at work more than others. If your argument is that no one can maintain any more than a 40 hour work week without burning out, I disagree.

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.


The "Sunday test" is no different from asking "Would you go to Mars with this person?". If your first response is to rant about how you'd never visit that rusty planet -- especially not with a coworker -- you're missing the point by 158 million miles. It's a thought experiment which proposes a hypothetical scenario and asks what your hypothetical response would be.

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.


I think you're misunderstanding the point of the question. It's not about forcing anyone to work on a Sunday, it's about whether or not you feel like this person is someone you'd like to work with.

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.


(I work at Stripe.)

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.


Think I have to take issue with the 'likability test' - that opens the door for rejections based on prejudices, stereotypes, conscious and subconscious.

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.


Makes sense, and I think most people understand this. That said, I think the name "the Sunday test" and the description "If this person were alone at the office on a Sunday..." is far from ideal.

(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.)


So don't go in - it's a wonderfully effective two-way screen for both you and the company. No need to complain.


I agree that's a choice for now, however this style of interviewing is perpetuated and perceived as 'the right way', when it simply isn't.


> we can hire lawyers, doctors, and surgeons on the back of a CV and an hour interview.

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.


That seems like a pretty great idea. I especially like the "tests" they give at the end. Asking those questions would give a decent feel for if you would actually want to work with that person.

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, this seems very practical and applicable. Sounds a lot less stand-offish, too. Don't have some guy pulling out obscure brain teasers to assert nerd dominance.


I think " great" engineers would balk at 5 hour interview process. And it seems to concentrate to much on the easy part ie coding and not the tricky soft skills.


On the contrary, I've found that great engineers are more concerned about flimsy interview processes. They know that everyone else will be picked by roughly the same process that they are. They want to have confidence that their colleagues will be good.

(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.)


I'm not calling myself a great engineer, but I've actually been hesitant to accept job offers in which I wasn't given a challenging interview. A challenging interview is not always indicative of a good job, of course, but with the investment I've made into my skills, I don't want them to languish.


I worked for 2.5 years for a company who interviewed me for 5 hours straight. I had no warning about how long it would last, and it seemed that if I'd been struggling at any point they would have called a halt and said thanks.

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?"


Firstly I like the focus on coding instead of algorithms and trick questions.

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!


I work at Stripe.

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.


Ah thanks for the clarification! That makes sense and sounds like a good arrangement.


I appreciate that the CTO took the time to answer the question. I know it is good for promotion, etc. Nonetheless, it is nice that the effort was put forth.


1. This sounds like a tremendous amount of fun. I would do this on a Saturday and even if there were no possibility of a job offering on the other end. I would do it just for the joy and the learning.

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.


Imagine doing this for 5 people, all the time wasted by the team necessary to spend this much effort on each person. Eventually I would think employees would get tired of this.


If you've ever been in a position to hire/fire employees and deal with managing a non trivial number of people then you'll appreciate taking the time to vet them (as best you can) before you hire them. Five hours interviewing someone is nothing compared to the days/weeks/months they'll be working with you. Even at 5 minutes of "savings" a day for a good vs poor choice you'd recoup the value of the interview in 60 working days (e.g. 3 months) and that's assuming it's just a single person's time your saving. In reality a worker's abilities and performance impacts more than just one person and the difference between a good and poor choice of employee is significantly more than 5 minutes a day.

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.


Much more time may be wasted if you end up hiring someone that doesn't fit the job description.


A 5 hour interview process, is "a lot of effort"?


I love the Bug squash part, It's a very good way to tests debugging skills while providing value to the community.


Good resource on refactorings:

http://martinfowler.com/refactoring/catalog/


"Simply writing correct code isn't enough"

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.


I disagree. Your teammates do care about what your code looks like.


I agree with the submission - fuck correct code, if it's not maintainable it might as well not be correct. I'd throw out correct but illegible code if it was bad enough - spend an extra 100% of time rewriting, and then 1% of time relearning, or spend an extra 20% of time re-learning the confusing code every time someone has to go back and look at it?


i think it's the opposite

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.


That may be true but a year out when new feature X just needs to "work", the time necessary to make that happen is going to depend in part on the quality of the foundation it's being built on.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: