
How Stripe does engineering interviews - christinac
http://www.quora.com/Stripe-company/What-is-the-engineering-interview-process-like-at-Stripe?share=1
======
xedarius
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?

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

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

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

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

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

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

~~~
pc
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.)

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

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

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

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

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

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

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

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

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

------
canistr
Good resource on refactorings:

[http://martinfowler.com/refactoring/catalog/](http://martinfowler.com/refactoring/catalog/)

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

~~~
diminoten
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?

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

