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