I have just been through the recruitment process for a junior role in my team and this got me thinking about the level of consistency across interviews that we carry out.

We do have a standard set of questions but when I looked at these they were focused on a DevOps Engineer, only some of the questions applied to the Site Reliability Engineer (SRE) role I was looking to fill. The standard questions were supplemented with some SRE-specific ones but the I still felt like the process could have been smoother.

Recently I have been listening to Work Rules by Laszlo Bock and, I think in chapter three, he talks about how important hiring is to get right. There are some figures quoted that struck me as interesting in how far they go to explain the performance of an employee. The number quoted is the r2 value e.g. an r2 value of 0.14 results in 14%.

The following list covers some of the interview tools/methods and their effectiveness:

  • graphology (handwriting analysis); 0.4%
  • number of years experience: 3%
  • unstructured interview: 14%
  • reference checks: 7%
  • general cognitive test: 26%
  • structured interview: 26%
  • work sample test: 29%

The work sample test is something that I had to do when I first joined the company and I have friends who have had to do code tests as part of the application process for dev-related roles.

This is something I think would be a good addition to the DevOps/SRE process – just off the top of my head we could ask the applicant to solve a problem using PowerShell or write an ARM template to create a set of resources perhaps.

Google also include a non-interested party in the interview, this person is aware of the skills and other requirements for the role but as they will not be working with the new hire they can be objective.

When I applied for a previous internal promotion, the interviewers consisted of a director who I would be reporting to directly and a representative from HR. The HR lady knew what skills were required for the role but as I wasn’t going to be working with her, she was able to provide a non-biased opinion.

An interesting part of this chapter in the box mentions the uselessness of brainteaser-type questions such as “Estimate how many gas stations there are in Manhattan.” If you’re interested, Wired have an article about this! Thankfully, the interviews I have been in and have conducted myself have not included this type of question 🙂

The book goes on to say that the interview is an opportunity to make the applicant fall in love with the company, it’s not just about us finding out about how suitable they are for the job. This is a good point, you may interview the greatest candidate ever but if they are put off by the unstructured, unprofessional approach taken in the interview then we are likely to lose them.

The interview is not just about the applicant making a good impression on the interviewees but also us showing why they should want to work with us.

From what I have learnt so far from the book and how Google recruit people, I intend to create an interview pack including a standard set of interview questions for an SRE, some example problems/work scenarios that need to be solved, and a list of non-interested parties who would be willing to join the interview panel.

Have you read/listened to “Work Rules”? What lessons did you glean from it? Leave your comments below and let me know. 🙂

1 thought on “Hiring – some lessons from Google

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.