After a recent discussion here on DEV regarding the use of open source contributions in resumes, I wanted to take the time to talk about the technical hiring process. I have a considerable amount of experience with technical interviews, both as a candidate, and as an interviewer. This experience has led me to develop some opinions.

Eliminating Bias

It should be no secret at this point that there is an inherent bias in the IT and software development world when it comes to hiring. It's important that anyone involved in the interview process at a company be aware of their unconscious bias, and take steps to counteract it.

Some techniques for removing unconscious bias from the hiring process include:

1. Anonymous CVs: Studies have shown that for the same resume men were 6-14% more likely to get an interview, men with the same credentials are consistently considered more competent, and resumes with white-sounding names get 50% more callbacks. This is why I advocate for blind CVs. Meaning, before a CV ever reaches an engineer all personally identifiable information is removed. This includes names, email addresses, social media links, etc.
2. Unconscious Bias Training: Research has shown that awareness of unconscious bias is an effective way to reduce it.
3. Clear, Concise Requirements: It's well understood that women don't apply for jobs unless they believe they can meet 100% of the listed job requirements (source). By providing clear and concise job requirements in ads we can increase the number of potential applicants, especially from under represented groups.
4. Degree Requirements: There are many ways to get into this industry, and a degree is only one of those ways. Unless a bachelor's degree is definitely required (e.g. academia), stop listing degrees as a requirement on job ads.

This is by no means an exhaustive list, but the takeaway here is to be aware of the implicit bias in the hiring process and take active steps to combat it.

The Phone Interview

The phone interview should be used as an opportunity to not only get to know the candidate better, but also to help the candidate better get to know your company. Many companies forget that the candidate is interviewing them just as much as they're interviewing the candidate.

As an example - at Condé Nast in London, we keep phone interviews relatively short (30-45 minutes) with a primary focus on cultural compatibility, while selling the company and engineering organisation to the candidate.

I feel it’s important to emphasise that the phone interview isn’t the right place to ask complex or difficult technical questions, but rather ensure a basic level of compatibility between the team culture and the candidate. As a result we have very few technical questions in the phone interview stage. An example of some of the areas we focus on include:

• Approach to software quality and reliability
• Interacting within a team, and handling conflict/differing opinions
• Understanding of diversity, and your experience working within diverse teams
• Basic application architecture, and what considerations you would make when productionising a software product
• Basic troubleshooting and your approach to problem solving

These questions give us a good idea of how the candidate approaches working within a team and how they think about the software development process, and are specifically designed to prompt the candidate to ask their own questions. This gives us the ability to understand the way they approach problems, and their thought processes.

After the phone interview the interviewer provides feedback to a hiring guild along with a recommendation on whether the interviewer believes we should proceed with the candidate. Again, care is taken to leave out any identifying information (including the use of gender-neutral language). The committee may then choose to ask additional questions. It's important that feedback is provided within a standard structure, and that clear reasoning is provided for the recommendation.

Wait, What’s a Hiring Guild?

In an engineering organisation, a guild is a group of people who work within different feature teams and meet with some frequency to discuss a specific competency. At Condé Nast, the hiring guild is comprised of various engineers of all levels, and is empowered to continuously improve the technical hiring process, and promote a diverse and inclusive engineering team. The hiring guild has full ownership over the process, and therefore are free to make changes where they see fit. The result of this is not only a reduced load on the People team, but also ensures candidates are properly evaluated by their potential future colleagues.

The Technical Interview

Technical Interviews have been a contentious topic in the software development industry over the last few years. Laszlo Bock, the head of HR at Google - a company well known for subjecting candidates to difficult computer science puzzles (often on a whiteboard) - admitted: "Brainteasers are a complete waste of time".

In fact, the brainteaser interview style used by Google, Facebook, Netflix, Microsoft, and many others is so famous it has spurred the release of a book designed to help candidates pass them - Cracking the Coding Interview.

It's worth noting these interviews represent yet another form of bias within our industry, which effectively ensures that only those with computer science degrees can succeed.

So what is the alternative? When designing a technical interview task I like to ask myself some questions:

• Is the task going to cause the candidate undue anxiety?
• Is the candidate going to have enough time to properly consider the problem?
• Is the candidate going to be given the opportunity to explain their solution?
• Is the task accessible to those with limited time, such as parents or carers?
• Is the task relevant to the position the candidate has applied for?

At Condé Nast the solution we arrived at was a short two hour technical task that the candidate is free to complete in their own time. The tasks vary slightly based on the position, but are designed to be relevant to the position (e.g. create a basic front end that consumes a public API). We strongly emphasise to the candidate that we DO NOT want them to spend more than two hours on the task.

We also book the face-to-face interview at the same time we send the task to the candidate, during which we will give the candidate an opportunity to walk us through their solution and explain why they made certain decisions. The technical task is not a gate, but rather provides us with insight into the way they approach a problem, and serves as a point of discussion for the face-to-face interview.

The Face to Face Interview

The face-to-face interview should be the final stage of the interview process. Of course, as you could probably guess, it's yet another stage of the interview where the interviewer must be aware of potential bias. Some recommendations I have for conducting face-to-face interviews are:

• Keep the interview as short as possible. 1-1.5 hours would be my preferred length. Most of your candidates will already have full-time employment, and those that don't may have other responsibilities (e.g. a parent returning to the workforce).
• Keep the number of people in the interview to a minimum. I recommend no more than 3 interviewers. The more interviewers in front of the candidate, the more nervous they're likely to be.
• Provide the option to complete the interview via teleconference. This provides additional flexibility to the candidate and having the opportunity to interview from a space they're more comfortable may help calm nerves. This has the added benefit of opening you up to candidates that aren't local, but might be willing to relocate.
• Ensure the interview is well-structured. There is research that shows that less structured interviews can increase bias.
• Try to ensure a diverse panel of interviewers. This reduces the effect of "similar-to-me" bias.
• Always leave time for the candidate to ask their own questions. Remember, they're interviewing you just as much as you're interviewing them.

The Conclusion

Hiring is hard. Hiring fairly is harder. However, when you take the time to invest in a fair and inclusive process, the payment is a happier, more effective engineering organisation that advertises itself.

Research has shown that individuals are less likely to want to work within teams where they don’t feel represented. A development team with good representation makes it a desirable place to be to those in the industry that may not feel like they fit in elsewhere.

If that isn’t enough to convince you, there is also a clear business case for diversity for the hard core capitalists out there...

Thanks for taking the time to read this post, I know it’s quite long. I welcome your comments below!

This post was originally posted on my blog here.