I estimate I’ve hired between 50 – 100 programmers over the past ten years. Most of the people I’ve hired I have also worked alongside as their team leader or as their manager.
After ten years of interviewing and hiring I’ve come to a fairly major conclusion about the process: interviews are useful for filtering out unsuitable candidates but interviews do not identify good hires.
Interviews work by weeding out out candidates who are almost certainly not good hires.
This is why as an interviewer it’s important to cover as much ground as you can during an interview, looking for reasons NOT to make an offer.
- If a candidate can’t code up FizzBuzz during an interview – no hire.
- If a candidate can’t communicate at the required level – no hire.
- If a candidate doesn’t have the attitude you’re looking for – no hire.
Similarly, it’s important for candidates to look for reasons to refuse an offer if one is made.
- If your interviewer is disrespectful – walk away.
- If the job doesn’t match what you’re looking for – walk away.
- If the offered terms and conditions are unfair or unreasonable – walk away.
Of course, if you’re desperate, you’re probably going to make (or take) an offer that isn’t a good match, at least (you tell yourself) until you can find a better match at a later time.
I’m not suggesting that interviews are totally useless, just that interviews do not fulfil the common expectation of finding good people to join a team. It’s the other way around; interviews find (and filter out) people who would be bad for a team.
So how and when do you find out if a person is a good match for a team?
The answer is that you find out weeks or months after they join the team. There’s no way to be sure beforehand.