Hire the best, even if they know nothing

Recently I hired two new developers and went through the interview process. One of the interviewees didn’t know the language he was about to start writing code in. He got the job. I gave him the job because he was the best person for the job. And time has proven me right.

Let me tell you about the interview and hiring process I used.

While I don’t agree with everything Joel Spolsky says, I think his blog post on interviewing is a great template. As Joel says, you want to hire someone who is “Smart and Gets Things Done”

One thing I ask interviewees to do is to write me some code on the whiteboard. Something really simple. In this case it was to find the intersection of two arrays in Perl.

Everyone that made it to the interview stage could do this. Some faster than others. But one guy didn’t even know Perl. With some misgivings, I suggested he write it in Javascript (another language he would be expected to know).

Most of the candidates did a reasonable job by creating nested loops to find elements in both arrays. For two arrays of 10 elements, that would give 100 comparisons. We call that O(n*m) and so we have a geometric increase in the number of operations required. Add one more element to each array and you’ve added 21 operations!

The candidate that didn’t know perl didn’t even consider writing something that was so inefficient. I won’t go into the details but it ended up being O( n log n + m log m ) — In other words: hugely more efficient.

When he first started writing up his solution I was puzzled. I’d seen the inefficient solution several times by then. Though of course, I kept a poker face and asked him to explain his code.

This guy’s brain instinctively threw out an inefficient solution and never passed it to his conscious mind. His first thought was to make sure the function he wrote would work nicely on a huge data set.

I thanked him for his time and send him on his way. But I was impressed. So I contacted him and gave him a different, more complex challenge, and required that it be written in Perl. I gave him a week to find the bits of the language that he would need. But by the time I arrived at work the next morning, he had the solution in Perl — and using the industry standard libraries that any experienced Perl programmer would use.

Smart? Yes. Gets things done? Yes. Hired? Yes.

The smartest person can adapt and learn the details of a job infinitely easier than a person who knows the details can become smart.

It feels like a risk, and can be difficult to justify to your own boss, but a manager is judged on the people he brings into the company. Even if it’s not in your KPIs, your team’s performance will be the primary method by which your effectiveness is assessed.

I firmy believe that it’s a bigger risk hiring someone who knows the details than it is to hire someone who is smart. What do you think?