Finding and shortlisting candidates is hard enough, so it’s easy to overlook the interview process itself. In this blog, we look at some best-in-class interview techniques from Google, and some helpful tools you can try out.
So much of hiring is based on hypotheticals. ‘Does their CV truly reflect their skills?’ ‘Is their reference reliable?’ ‘Will they listen to their headphones on full blast and irritate the hell out of everyone?’ But the interview process is perhaps the best indicator of whether a candidate is the real deal.
That’s why we were intrigued to read this Wired piece by Laszlo Bock, Senior Vice President of People Operations at Google, which features an excerpt from his book Work Rules!
Laszlo makes a compelling case for the interview techniques that have not only helped Google hire better candidates, but also, transformed the perception of the company among rejected candidates (80% of whom would recommend Google to a friend).
The main thesis is that traditional interviews are replete with confirmation bias, where “an interview is spent trying to confirm what we think of someone, rather than truly assessing them”.
“In other words, most interviews are a waste of time because 99.4 percent of the time is spent trying to confirm whatever impression the interviewer formed in the first ten seconds.”
How can we overcome our biases and beliefs, and conduct interviews that match our hiring goals? Here is a summary of Laszlo’s tips:
1. Introduce a work sample test. All Google’s technical hires undergo an on-the-spot test as it’s the “best predictor of how someone will perform in a job”. In our conversation with Amandeep Shergil, director of tech recruiting at Automattic, Amandeep discussed the importance of setting expectations early if you intend on setting a code test.
2. Consider a cognitive ability test. “General cognitive ability includes the capacity to learn, and the combination of raw intelligence and learning ability will make most people successful in most jobs,” Laszlo writes.
3. Avoid brainteasers, which “serve primarily to make the interviewer feel clever and self-satisfied”.
4. Ask generic questions. This might seem dull, but as Laszlo argues, that’s exactly the point. “Yes, these questions are bland; it’s the answers that are compelling.”
5. Add a ‘cross-functional interviewer’. In other words, someone from a different department who can provide a “disinterested assessment” and is “unlikely to have any interest in a particular job being filled but has a strong interest in keeping the quality of hiring high”. It’s perhaps a similar logic to Amazon’s Bar Raiser programme, where an interviewer “is brought into hiring loops as an objective third party”.
Importantly, Laszlo adds that cognitive testing needs to be implemented in conjunction with other processes, like structured interviews, to avoid a “highly subjective or discriminatory” interview experience. You need a combination of ingredients to make interviews work.
“The goal of our interview process is to predict how candidates will perform once they join the team. We achieve that goal by doing what the science says: combining behavioral and situational structured interviews with assessments of cognitive ability, conscientiousness, and leadership”.
The insights from Google provide a sound theoretical basis for interviewing more effectively, but how can you implement these theories in practice? This Zapier blog extols the virtues of three tools in particular:
● Coda – for documentation and project management. “Coda acts as our information hub.”
● Searchlight – for quality of hire and references. It helps hiring managers and recruiters to “align on success profiles and structured interviewing criteria for each role”.
● Greenhouse – an applicant tracking system (ATS) which “helps keep track of what we evaluate”, and has “seamless integration” with Searchlight.
According to Zapier’s blog: “Greenhouse, Coda, and Searchlight combined inform our interviewing source of truth when it comes to what we evaluate, how we evaluate, when we evaluate, who does the evaluating, and tracking candidates who advance.”
We’ve covered the brilliance of Google’s interview techniques, but on the other side of the coin, there was an interesting blog penned by a software engineer who left Google after ten years.
“It’s only now that I realise what was wrong,” Scott Kennedy writes. “I missed the satisfaction of building things and finishing projects.”
Are there lessons to be learned in how we persuade candidates (and existing teams) that they’ll be able to see the fruits of their labour?