Improving DevOps and SRE job interviews

  • April 30, 2020
  • 3 min read

The rise of cloud computing in the past decade and the move towards infrastructure as code have changed traditional systems administration roles. The lines between software engineering roles and such roles have blurred as companies moves towards managing everything via code. This shift in focus has resulted in job titles such as DevOps Engineer, Site Reliability Engineer and Cloud Engineer to be advertised widely. We think that using live running scenarios, as opposed to asking hypothetical questions, lets candidates demonstrate their skills and at the same time shows to the hiring manager the strong and weak points of the candidate. Scenarios can range in difficulty depending on what position you are hiring for, from junior to senior and managerial roles.

Companies have to answer two key questions during their hiring process:

  1. Which candidate seems to have the best team or company culture fit?
  2. Which candidate seems to be able to perform the required duties best?

Both questions are important. The first question is quite fuzzy by nature and thus subjective to answer. We focus on the second question in this blog post.

Some candidates have the ability to sell themselves during interviews. Others have credentials such as graduating from well known universities or working at well known companies. Whilst some recruitment teams place a higher weight on these signals, specially during initial screening, we think that better hiring decisions can be made by observing candidates working in live running scenarios.

DevOps and SRE roles come in various forms but they usually involve two broad types of tasks: building things or fixing things. The building part involves investigating and weighing alternatives followed by building/coding, testing and finally releasing infrastructure changes. The fixing part involves troubleshooting and digging deeper until a root cause is found. This part is followed by the previously mentioned building part, where alternative solutions for the root cause are investigated, coded, tested and released. Anecdotally speaking, some of the best engineers we’ve worked with have been amazing troubleshooters.

Scenario based interviews push companies to decide what skills are important for their positions. Once they know what they are looking for, they can create scenarios which test the skills required in a real life scenario, which are close to the actual work the candidate will end up doing.

We recommend that companies first establish two-way communication with the candidate via their recruitment teams to make sure that there is a rough match between the candidate’s expectations and the position on offer. They can also be told about the hiring process and answer any initial questions that the candidate might have about the position or the company. At this point, both parties should be evaluating the other. It is not for the candidate to only chase the company, but the company to also be chasing the candidate.

Scenarios can be used during the screening phase as well as during technical interviews. For example, having a 5 minute warmup scenario followed by two 10 minute scenarios might be suitable for screening. These scenarios can help answer the following questions about candidates:

  1. Can they write a simple script using an if statement and a for loop?
  2. Can they troubleshoot networking issues using ping, telnet and dig?
  3. Can they read logs and keep pulling an error “thread” until they find and fix the issue?
  4. Can they search for something online and implement what they learn?

Depending on the position and the level that is required, companies can choose to have bigger scenarios involving technologies such as Terraform, Ansible or Kubernetes. Scenarios could be accompanied by live monitoring and alerting systems too. These scenarios can take up to 45 minutes. Bigger and more challenging scenarios enable deeper discussions during interviews, which leads to the depth of a candidate’s skills to be discovered.