I’ve frequently been asked variations of the question: “How does one hire the right people?” While I by no means have a perfect record in this area, over time I’ve developed some heuristics that allow me to generally recruit good people (or at least avoid not so good people).
Rule 1: Hire for the Future
The typical hiring process resembles detective work, with the central focus being a deep forensic dive into what a person has done in the past. In the end, one is left with a bucketful of self-reported “facts” and a gut feeling over whether the person might be a good fit. This is a lousy way to recruit.
Why? Simple – you’re looking in the wrong direction. When recruiting you should be trying to uncover what the person will do for you in the future, not what they’ve done in the past.
That isn’t to say that the past has no relevance. One should use past performance and experience as a rough indicator of potential future performance, but only if past performance can be truly known. Most of the time you only have the candidate’s word and whatever you can read between the lines on the resume. (Ironically this plays into the hands of people who have learned to interview well but are otherwise incompetent. Beware – there’s more of them than you might think.)
So focus on the future. How? By asking the candidate to think and solve problems. As information workers this is what we do every day, so you should see how they do it. Give them case studies and assess how they approach the problem. Observe how they deal with ambiguity (another thing we deal with every day). Get a feel for their analytical skills. See how they deal with challenges thrown at them – are they confident and collaborative or do they bristle and push back.
Some challenges I’ve used in the past for engineering candidates include:
- Design a [insert design challenge here – usually something like an online game or other complex scenario]. Show me on a blackboard.
- Here’s a [ insert business problem here ]. How would you go about developing a solution? Show me on a blackboard.
- You’re starting a company tomorrow and you head up engineering. How will you set up your SDLC? Show me on a blackboard.
- The system is struggling and here are the symptoms [ insert symptoms ]. How would you go about identifying and resolving the root cause? Show me on a blackboard.
- Here’s some data representing [ insert dataset description ]. What does the data tell you about the situation? How would you solve the problem?
One amusing anecdote – I was asked to meet with a candidate for a senior engineering role. It was mostly a courtesy interview – the team was enamored by his magnetic personality and was ready to hire him. My job was nominally to “sell” him on our company. But just for good measure I wanted to get a sense for his analytical ability. As we were meeting in a lounge without any blackboards I made up an abstract question vs. a specific engineering domain question: “How would you turn over that coffee cup sitting in front of you without touching it with any part of your body?” I thought this was a softball question – in formulating the question I’d already come up with several ideas ranging from crazy to practical. He just stared at me. And stared. And stared until it was long past the point of being uncomfortable. Eventually he said he wasn’t prepared for that kind of question and had no answer. We didn’t hire him. (Note: I’m not a fan of “brain teaser” interviews so this isn’t how I normally operate, but it’s telling when someone completely freezes over a simple abstract problem.)
Rule 2: Never Settle
The most expensive thing any company can do is hire unqualified or incompatible people. Take Germany for example – you spend 3 months recruiting, another 3 months waiting for the person to end their old contract. Then 2-3 months before you realize they may not be a good fit. Another few months of remediation before you let them go. Then another 3 months of recruiting… Your bad hiring choice basically leaves you without a person in that role for a year or more.
Never settle. Period. Hire only people as good or better than the average person on the broader team already. It’s way better to have an empty seat than a seat filled (or unfilled) with a problem.
Rule 3: Recruit for Talent, Not Skills
Any smart, motivated, analytical person can learn specific tools or languages. Not everyone who knows specific tools or languages is smart, motivated or analytical. So weight your decision heavily towards raw talent vs specific skills when hiring for a permanent team member. This means assessing their general problem solving ability and broad understanding of core computer science concepts. It’s fine to also look at their specific skills, but ask yourself whether gaps in any skills really should drive a “no-go” decision. Some of the very best engineers I’ve worked with or hired knew very little about the domain or specific programming languages at the start but ramped up quickly and became superstars as a result of their raw talent.
Of course, if you need a specific skill now – knowledge of a particular software package, for example – then by all means make that required. In that case, though, you should consider bringing on a contractor or freelancer until you have the right permanent team member ready to take on the role.
Rule 4: Key Indicators
Not all factors should be considered equal when evaluating a candidate. Being human, we overweight “personality,” “self-confidence” and other soft attributes. These may be important but often weak indicators of future performance and team fit. You need to be intentional about down-weighting those factors and staying focussed on the critically important attributes. These include:
- Accountability. People who lack accountability and ownership will fail. My experience is that low ownership correlates almost 100% with a bad outcome. Avoid these people like the plague. How do you gauge accountability? Ask questions about projects or other initiatives that didn’t go so well and see if they take some of the responsibility. Ask what they’d do in the future to get a different outcome and listen for whether they share responsibility for the improvements. Role play with a difficult challenge that has plenty of excuses and see if they take the excuse. Be creative.
- Problem solving. Creative analytical abilities are the foundation of any problem solver, and problem solving is what we do. To do this you just need to observe them solving problems. Put them on a blackboard and give them open-ended questions.
- Integrity. If you can’t trust them 100% then you definitely don’t want them on the team. This is tough since only truly incompetent people will obviously lie to you, but you can ask questions about their resume and drill down a bit in areas where you have expertise to see if they represent themselves accurately. You can ask questions multiple times with subtle variations to see if the answer changes. You can always verify references or facts listed in the resume.
- “Fire in the Belly”. You want people who will show up on day 1 and apply themselves 100%. This is sometimes tough to discover in interviews so is often something you have to assess early in the on boarding.
- Respect/Arrogance. Will they treat their teammates with respect or will they lord their excellence over everyone? You don’t want them on your team if the latter. No one likes working with assholes. Most likely they’ll defer to you, the hiring manager, but watch how they interact with the receptionist when they arrive, waitstaff when you take them to lunch, or anyone else not involved in the process. You can also get a glimpse of this if you challenge them hard during an analytical exercise and see how they respond under pressure.
These five (and I’m sure there are more) are strong “fail” signals. If the person is lacking any of these attributes it’s highly likely they’ll fail as a colleague.
The inverse, however, is not necessarily true. Someone who possesses these attributes may not be a great team member, but at least they have a good head start. So use these as a filter gate.
Rule 5: Group Think
So, who decides if a candidate is right for the team? One common approach is to have a hiring manager make the call. It’s simple. It empowers the hiring manager. But in the end it’s a bad idea.
Why? For several reasons, but I’ll focus on two. First, we all suffer from biases. We tend to overweight certain attributes (e.g. those most like us) and we each have our pet peeves. We also see what we see in the frame of our past experience. All of this together means we’re susceptible to making the hiring decision on the wrong factors.
Second, the reality is that we’re hiring for the company as much as we’re hiring for a specific team. Engineers move teams all the time, whether for their own career growth or because the mission changes. You need people who are not only a good fit for their team but for the organization as a whole.
You can solve both problems by not going it alone. Get several people involved including people from outside the team. Group interviews are fine to save time, but make sure each interviewer has specific things they’re looking for. At the end of the interview cycle take a confidence vote – I’d argue that you want unanimous agreement on a 4 or better out of 5 else you should probably pass on the candidate.