Practice what you preach - DevOps your hiring process

05/11/2016   Industry insights   Recruitment advice  

While the exact definition of DevOps is always up for debate, I think most people would agree that at its heart, it’s about optimizing the flow of development, while focusing on business objectives. It's about breaking down silos, collaborating, and sharing responsibility...that will do for this metaphor anyway!

So what has that got to do with recruitment? Well, having a DevOps mentality would make for a pretty good recruitment process.

Firstly, there’s a focus on speed and accuracy - getting the right person, at the right time. Secondly, it’s collaborative across the process, up to delivery (hire) and beyond.

Unfortunately, it’s still rare to find an organisation that has such a process in reality, with many companies who are doing amazing things within the open source world losing out on great engineers due to their recruitment practice. Some of the most common issues we see include slow or vague interview feedback (or no feedback at all!), technical testing that doesn’t reflect the role requirements (a bug bear for another blog), or delays in the process as different parties are not available for sign off.

Meanwhile, someone else has swooped in and offered your perfect candidate.

SO WHAT WOULD A DEVOPS HIRING PROCESS LOOK LIKE?

Spending your time wisely

Often a company will consider themselves ‘ready to hire’ if they have written a job spec - and though that it is important, often the actual process of recruitment is kind of cobbled together as things take shape. Recruitment will take up a fair bit of your time, so it’s better to approach it strategically from the start, so there is less time wasted. You need to understand what’s going to happen, and who’s going to be doing it across the whole process- even if it’s not your job directly.

  1. Who needs to sign things off?

  2. Who will look at CVs?

  3. How will feedback work?

  4. What’s our interview process going to look like?

  5. How will an offer be made?

You could also consider setting SLAs, working with everyone involved to ensure they have the time and resource to follow this schedule, and maintain momentum in the process.

Collaborate... and listen

In a competitive market, the best candidates have their pick of opportunities, so it’s important to understand what a good experience looks like for them (and try to make it happen!).

This might sound like something that will need a lot of time that you don't have, but even asking a couple of quick questions could see a big improvement in the speed and general painlessness of your recruitment process.

It can be really useful to speak to your existing team to ask how they found the process when they applied, to find out if there were any issues that you might be able to improve on.

Team Spirit

I think a really effective interview needs to give a good insight into the reality of the role, as well as incorporating broader problem-solving ability assessments. Sometimes interviews can end up being heavily ‘theoretical’ - you’d be surprised how many we hear about that don’t include a tour of the work environment or any of the code base.  From the candidate’s side, interviews full of abstract brain teasers are often not popular.

A good way of overcoming ‘theory fatigue’ is getting your team actively involved in the interview process, perhaps asking them to discuss a customer problem they’re dealing with, talking through some live code in more detail, or even just showing them the work environment, and giving some brief feedback to the decision maker. This is often most effective if you get people at different levels of seniority involved - you often get much more interesting insight from junior engineers!

Of course, everyone is busy (that's why you’re recruiting in the first place!), but this doesn’t need to be a long exercise, it’s more about them seeing what this person would be like to work with, which is something you can often tell fairly quickly. It can also be a way to get some fresh eyes on a challenge you are working with at the moment.

On the flipside, if the candidate doesn’t gel with the team, everyone has wasted an hour and you’re back to the drawing board.

But isn’t that better to realise before you employ them?

By using your team to help you hire, you make the process something they are a part of, rather than something they have done to them and have to work with later.

Applying some (metaphorical) DevOps principles to recruitment means there is an atmosphere of collaboration from the start. You’ll find the candidate who will work best with the team, rather than just as an individual engineer. And ultimately, in a true DevOps team, it’s often said that a true DevOps team should be more productive than its ‘parts’.

Bringing the interview process back to reality with a bit of live code or a discussion of your customer needs keeps the focus on business objectives from the start, and hire for team fit rather than just technical ability.

Thanks for reading!