Everyone wants to hire more engineers, including you, driving software salaries through the roof. Unfortunately, it’s very likely that you don’t have the slightest clue how to recruit well.
Take heart. While your ability to spot real talent in an interview may be weak, open source makes it relatively easy to see who can actually code, and who simply knows how to answer useless, abstruse questions.
Finding great technical talent is important. In fact, in a world increasingly run by developers, I’d argue that it’s the most important thing any company does, whether it’s a technology vendor or a manufacturer of cars or clothes. The better the engineering, the better the product, and the better the product, the less reliant your company needs to be on sales and marketing, at least, early on.
Or, as venture capitalist Fred Wilson puts it, “Marketing is for companies who have sucky products.”
The problem, of course, is that everyone is scouring the planet for the same engineers. Which, in turn, has driven the cost of developer salaries way up:
There are all sorts of gimmicks to finding great engineers. Google, for example, used to impose complex brainteasers on job applicants—only to discover they were utterly useless, as Laszlo Bock, senior vice president of people operations at Google, said:
We found that brainteasers are a complete waste of time. They don’t predict anything. They serve primarily to make the interviewer feel smart.
Brainteasers, then, are out.
But, as Bock went on to highlight, so are brand-name schools, test scores and grades. “Worthless,” he declares. In fact, the whole hiring process is a “complete random mess.”
So how can you fix this?
Changing The Interview Process
One way is to change the way you interview. As Laurie Voss, the CTO of NPM, recently argued, “You are bad at giving technical interviews…. You’re looking for the wrong skills, hiring the wrong people, and actively screwing yourself and your company.”
Sadly, she’s probably right. And not just about you. We’re all pretty bad at technical interviews (or interviews, generally, for that matter).
The gist of her post is that too often we “over-valu[e] present skills and under-valu[e] future growth,” hiring people based on what they’ve done (or went to school) rather than what they can do. Or, as she summarizes:
1) Many interview techniques test skills that are at best irrelevant to real working life; 2) you want somebody who knows enough to do the job right now; 3) or somebody smart and motivated enough that they can learn the job quickly; 4) you want somebody who keeps getting better at what they do; 5) your interview should be a collaborative conversation, not a combative interrogation; 6) you also want somebody who you will enjoy working with; 7) it’s important to separate “enjoy working with” from “enjoy hanging out with;” 8) don’t hire [jerks], no matter how good they are; 9) if your team isn’t diverse, your team is worse than it needed to be; and 10) accept that hiring takes a really long time and is really, really hard.
Bock echoes this, indicating that Google’s experience has been that behavioral interviews work best. Rather than asking a candidate to remember some obscure computer science fact, Google now starts with a question like:
“Give me an example of a time when you solved an analytically difficult problem.” The interesting thing about the behavioral interview is that when you ask somebody to speak to their own experience, and you drill into that, you get two kinds of information. One is you get to see how they actually interacted in a real-world situation, and the valuable “meta” information you get about the candidate is a sense of what they consider to be difficult.
This is a great approach, but there’s a way to take it one step further.
Open Source Your Interview
The best place to see how engineers solve problems in the real world is in the open-source projects to which they contribute. Open-source communities offer a clear view into an engineer’s interactions with others, the quality of her code and a history of how she tackles hard problems, both individually and in groups.
No guesswork. No leap of faith. Her work history is all there on GitHub and message boards.
But open source offers other benefits, too. As Netflix’s former head of cloud operations, Adrian Cockroft, once detailed, open source helps to position Netflix as a technology leader and to “hire, retain and engage top engineers.” How? Well, the best engineers often want to work on open source. Providing that “perk” is essential to hiring great technical talent.
Interviews are important to ascertain cultural fit, among other things, but they shouldn’t be a substitute for the more informative work of analyzing a developer’s open source work.
And if they have none, well, that tells you something, too. A colleague at a former company told me that the best engineers were all on GitHub, not LinkedIn. While perhaps an overstatement, there’s a fair amount of truth to it, too.
In sum, you should be able to get to know your next engineering hire through open-source development far better than through any interview process, no matter how detailed.
Photo via Shutterstock