Lately, it’s been popular to complain about how ineffective interviewing is as a way of selecting good candidates. It’s decried as a waste of time, unpredictable and “just wrong”.
Interviewing doesn’t have to be this way.
In every other part of software development, we invest massive amounts of discussion, argument, blood, sweat and tears trying to find the perfect reproducible process. We spend PEOPLE YEARS of time tuning our software lifecycles, even when we don’t even know what we’re building or who we’re building it for. Think about all the software methodologies we have, all the conferences, the books, the acronyms. In my 17 years, I’ve learned/participated in at least 4 major software development methodologies (and endless mixes): RUP, Agile, Scrum, Kanban.
You know how many interviewing methodologies I’ve been taught?
Zero. Nil. Nada. Zilch.
Do you see the problem here?
Random actions yield random results. Interviewing people without a very specific, repeatable process will yield worse than random results. Even coin-flipping can yield a streak of good hires. An unreproducible interview process will allow existing biases, personal mood swings and time of day (!!) to influence the outcomes. It will create a self-reinforcing cycle of bad hires. Not only that, it will waste precious time — quickly offsetting any gains from adding staff.
Here’s where you start:
- Determine up front how many interviews EVERY candidate will have.
- Determine up front the goal of EACH interview.
- If possible, determine the questions (and the specific wording of them) you will ask in each stage.
Write these decisions down. Develop a script. Train your team with this script. Each time you choose to pass on a candidate, review the process in light of the decision and see if you could have identified the problem earlier in the process. Adjust as necessary, but try to change only one variable at a time.
In other words, treat hiring with the same rigor and focus on reproducibility as with developing software. Be methodical. The truth is that the people you choose to build software matter more than the development process you use. Good process amplifies people, but no amount of software process can fix a bad hire.