Why hire brilliant when average will do?

by Sam Hopkins

About me

I've recruited, hired, and worked directly with ~50 technical workers over the last 8 years. And by "worked with" I mean actually worked with. Gone to client meetings with them, made project plans with them, written code with them, released bugs into production with them, fixed said bugs with them, watched them overcome challenges, watched them fail challenges, etc. I wrote this up to share some of my more unintuitive findings from this journey with you.

The conventional wisdom

A simplified version of the conventional hiring process looks like this:

  1. Apply aggressive filters to candidates.
  2. Rank by technical ability.
  3. Try to hire who shows up at the top.

Sure there's usually more going on in a hiring process but these are portions of the process that we'll focus on in this discussion.

DareData's process

The main thing that I've noticed though hiring and working with lots of technical folks is that motivation and attitude almost always trumps technical ability. And I say this as a technical manager that demands technical excellence. Ask anyone who has worked with me and they'll tell you the same.

motivation and attitude almost always trumps technical ability

Compared to the hiring process mentioned above, ours looks more like this:

  1. Apply the fewest filters possible.
  2. Rank by personal fit for the job.
  3. Try to hire who shows up at the top.

The differences and their implications

Is speed everything?

So the most obvious criticism of our process would be that you end up with people that can't execute on technical tasks quickly enough. Let's take a look at what might be the underlying causes of this slower execution speed and then explore how important this actually is.

If person A is better at executing technical tasks than person B, this reason usually falls under two categories:

  1. Raw brainpower a.k.a. smartness.
  2. Experience.

Let's start with point(1). Saying that you want to hire the smartest people possible is, to me, is incredibly silly idea for the vast majority of cases. Intelligence is relative and, literally, most people are of average intelligence. Some a bit above, some a bit below, but we are all on a bell curve. Saying that you want to grow your team by mining scarce resources is going to send you down a long, arduous, painful, expensive, and usually unnecessary path. If you need brilliant people it is probably to compensate for bad management anyway. If you have a clear mission and a well formulated plan / strategy, average intelligence works just fine. Of course there are exceptions for a key role or two but they are just that: exceptions. If you need to build ye olde web app or train a vanilla recommender system you are super lucky. Don't waste your time trying to hire the biggest brain around, Google will offer them a few hundred thousand more than you anyway.

If you need brilliant people it is probably to compensate for bad management. With a clear mission and a well formulated plan / strategy, average intelligence works just fine.

Point (2) is also a bit counter intuitive. You do indeed need to make sure that the candidate is over some kind of threshold and making that judgement is on you, the person drawing up the technical requirements for the job. Hiring someone as a full stack developer who has no experience programming will probably not work, no matter how motivated they might be. Hiring a full stack developer that does have experience with 1/2 of your stack but is extremely motivated may or may not work and requires a judgement call. What I've found is that hiring someone with a bit less experience than ideal usually means that the first months will be slower as they ramp up. Across the lifetime of their employment and your company, these few months of 30% or 40% lower efficiency really doesn't move the needle, especially if management and employee retention is good.

The conclusion that this has led us to is that we should think carefully about what are the minimum technical requirements for the job and make those the upfront filters. At DareData, anyone who passes those filters gets a first interview with me. I'll sometimes give someone an interview even if they don't clear the minimum requirements on the off chance that they have simply drawn up a bad CV. If not, the worst thing that happens is that I spend 15 minutes of my time telling them what they need to do in order to apply again. Many times they will then re-apply a year or so later when they are prepared and everybody wins.

So if our upfront filters are so low, what do we use as filters? Surly we must use something! That brings us to our second and third of the bulleted points.

Rank and hire by personal fit for the job

The moment that I am reasonably convinced that the candidate might be over the minimum technical threshold required for the job, we move on to the most important question: is this a job that they want?

I can typically find this out in 30 minutes or less of speaking with them and the script usually goes like this:

  1. I ask them "before I tell you anything about what we offer, you tell me what you are looking for in a job".
  2. I then use the new information that I just gained from them to explain, in terms of what they are looking for, what we have to offer.
  3. We then discuss whether or not there is indeed a fit.

Note that this approach is miles different from the script in which most interviews start by having the interviewer talk about what THEY have to offer while the prospect listens. There will be plenty of time to talk about yourselves in the future and in the meantime, the best way to sell yourself is to show them that you are a respectful listener.

After about 15 minutes going through the above points, we will find out if what we offer is not what they want. We finish up with a friendly chat, move our separate ways, and promise to keep in touch in case something changes on either end.

If we do agree that there is a personal fit for the job, we put it in writing in our meeting notes. Then as long as this offer / want match stays, we know that the job is a good one for them. If this changes at some point in the future we simply re-assess and see if what we offer is still a good fit for them. If not, we help them find a new job and hire someone else that has a better personal fit. Since the high levels of what a person wants out of a job doesn't change that often (at least a few years) we can be reasonably certain that they will stick around long enough for our initial investment in them to bring good returns.

How often does this fail?

If we don't place too much importance on technical ability when hiring, you might be wondering how often we end up hiring someone whose technical abilities don't cut it. The basic numbers look like this:

  • We've hired about 30 people at DareData in the last 2.5 years
  • 2 of them have been below the minimum technical requirements

And for both of them we found that the errors were mine. The technical evaluation process wasn't good enough and the bar was set too low. In both cases, the candidates presented themselves in honest and transparent ways and the judgement call to bring them on was mine because I didn't evaluate the technical abilities properly. We've since modified our technical evaluation processes and it seems to have fixed the issue.

In conclusion

Underlying all of this is a basic faith in human being's ability to learn and adapt. If someone fits in a team, communicates well, understands the desired outcome, and has a willingness to learn, and has the minimum tech skills required, nine times out of ten they will find a way. And for the rest of the team it is incredibly rewarding to watch someone grow into a role that 6 months or a year ago seemed out of their league.

In tech we have a tendency to over-emphasize the importance of technical ability. I think that it comes from day one of the training. During the training process (university, bootcamps, etc.) there is 100% focus on how well can you use a tool in an artificial environment. You are given contrived puzzles to figure out on your own in a vacuum and whoever can churn through them the quickest is considered the most likely to succeed.

In the real world the technical ability of your team is almost never the limiting factor when it comes to success of your organization, rather it is management and strategy. If you focus on making good plans and putting motivated people in place, you should be on a nice and reliable path to success without the need of the proverbial "rockstar".