How do you hire great developers? It’s an evergreen question. One of our developers was reflecting on some differences between the interviewing process he went through with us versus some experiences his friends were having. He commented,
Usually people just look through my resume and ask me questions about things on it, no pair programming or whiteboarding.
I’ve wanted to ask why you didn’t have me pair-program or give me a problem to solve. It’s just weird to be surrounded by people who get drilled during interviews and never have experienced it. Hopefully I never have to :).
It’s a great question! It’s so good that it prompted this blog post. Warning: opinions follow.
Unique People, Unique Needs
A great hire for one technology company isn’t always a great hire for another, even if they’re very similar. Many factors play into whether a person is a good fit. Interviewing often focuses on whether the person knows how to code, whether there’s a cultural fit, and so on. These are all very important, but the real thing you want to find out, in my opinion, is whether the person is going to be successful with the company, team, product, and customers.
A lot of people would agree with that, I’m sure, but many people disagree on specific aspects of the list. One of the biggest divides is whether to ask the candidate to write code in interviews. This is a violent and mostly unsolvable debate.
Is There Really No Substitute?
When I was working with an early-stage company in Charlottesville some years ago, we interviewed a lot of people. The founder had a set of puzzles we used to challenge people with. Some were on-the-spot, others were homework to do in advance. A few of them were downright hard.
We hired some bad programmers, and some good programmers who didn’t fit anyway, but I don’t think we did any worse than other companies.
The founder was a fan of Joel Spolsky’s writings. It was all very opinionated, colorful, and seemed solidly argued. I think it’s less popular today than it was then, but at that time everyone was reading and debating everything Joel wrote.
Joel was a hard-liner. I have several of his books on my bookshelf, and I can probably come pretty close to quoting him without even walking over and flipping through one of them: “you want people who are smart and get things done, and the rest is largely immaterial. There is no substitute for writing code in interviews, because otherwise you’ll never know if the candidate can actually write code or not.”
How can you argue with that? I can’t, but over the years I’ve developed a gut feeling that doesn’t quite agree with Joel. My approach has changed over the years. I rarely feel the need to actually grill people in great detail about writing lines of code.
Smart people who have demonstrated success are probably capable of replicating it in a new environment. If not, I’m not sure you will find out in an interview. It will probably only become clear after a couple of months. Very few people can change careers and be amazingly productive in the first week.
Hiring Needs To Be Re-Learned Every Time
I used to work at a fully remote and distributed company. While there I hired dozens of people, and I thought I got pretty good at it. It’s taken me quite some time to adjust to hiring for VividCortex. It was a bit of a surprise: people come to VividCortex for entirely different reasons. There was a set of assumptions and foundations at the old job, which became comfortable and unconscious for me. At VividCortex, I had to realize that my skills at hiring in the old company were only partially relevant. By the time I realized this, I’d hired a couple of people who didn’t really fit the team, and who eventually left.
Moral: Skill in hiring at one company doesn’t always translate to another company.
But some things did remain the same. For example, that company helped me to be more comfortable hiring people remotely, without meeting them in person.
Skilled at Interviewing
The skill in interviewing runs both ways. It’s clear that people can be skilled at interviewing and not skilled at the job. I have lots of war stories to tell, some of them about actually sick people. Perhaps the most unsettling thing about the dangerous people is how good they can be at camouflaging themselves. A real psychopath’s greatest asset is the ability to seem completely normal, even under extensive scrutiny.
I was once part of an interview process for hiring a person who was just too good to be true. Many people met with this person face to face, and we and spent days together. My gut kept sending me signals, yet there was absolutely nothing wrong. The trouble is, an interview isn’t everyday life, and behavior in interviews doesn’t represent how everyday work will go. Only after the candidate returned home and weeks passed did the mental illness become evident.
To some extent, you can just ask people if they’ll be good at the job and see how they answer. We used to prevent bounced checks at my mom’s hotel by just asking “is this check good?” But this doesn’t work with people who are psychopaths. You’ll never completely eliminate this risk in interviews, no matter how hard you try. I’ve worked very hard to design systems to find whether people are good or not, and it hasn’t seemed to make much difference.
The Bottom Line
Given that you can try extremely hard without getting much better results, I lean towards keeping the cost and effort of interviewing down. I don’t know how good it’s possible to be at interviewing. I think Google can probably claim to be very good at interviewing now. But they used to claim that years ago too, and they have changed a lot since then, so who knows?
Instead of putting so much effort into interviewing, I am gravitating towards looking for proof of whether someone will be successful: can they communicate and work well enough to ship code in an open-source project? That, and references from people I trust, are worth their weight in gold.
So if you want to get a job at VividCortex, a link to a significant pull request on GitHub is better than anything you can put on your resume!