12 ms·
How Stripe does engineering interviews
- canistr 13y agoGood resource on refactorings: http://martinfowler.com/refactoring/catalog/ http://martinfowler.com/refactoring/catalog/
- RandallBrown 13y agoThat 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).
- gtaylor 13y agoI 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.
- walshemj 13y agoI 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.
- pc 13y agoOn 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.)
- rybosome 13y agoI'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.
- tehwalrus 13y agoI 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?"
- byroot 13y agoI love the Bug squash part, It's a very good way to tests debugging skills while providing value to the community.
- jbapple 13y ago1. 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.
- a3voices 13y ago"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.
- pdovy 13y agoThat 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.
- diminoten 13y agoI 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?
- dustingetz 13y agoi 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.
- vowelless 13y agoI disagree. Your teammates do care about what your code looks like.
- coldcode 13y agoImagine 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.
- diminoten 13y agoA 5 hour interview process, is "a lot of effort"?
- sehrope 13y agoIf 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.
- gpsarakis 13y agoMuch more time may be wasted if you end up hiring someone that doesn't fit the job description.
- xedarius 13y agoStop 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?
- sgrove 13y agoSo don't go in - it's a wonderfully effective two-way screen for both you and the company. No need to complain.
- xedarius 13y agoI 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.
- RandallBrown 13y agoI 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.
- diminoten 13y agoThere'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.
- lawn 13y agoFirstly 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!
- cristinacordova 13y agoI 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.
- lawn 13y agoAh thanks for the clarification! That makes sense and sounds like a good arrangement.
- Pro_bity 13y agoI 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.