DEV Community: Josh Michielsen

On Hiring Developers and the Technical Interview Process

Josh Michielsen — Fri, 15 Nov 2019 16:04:04 +0000

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:

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.
Unconscious Bias Training: Research has shown that awareness of unconscious bias is an effective way to reduce it.
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.
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.

Separate Your Tests with Build Tags

Josh Michielsen — Mon, 04 Nov 2019 19:17:57 +0000

Have you ever wanted to separate your unit tests from your integration or smoke tests? Go has a built-in mechanism for allowing you to logically separate your tests, in addition to adding conditionals (e.g. operating system or CPU architecture) with Build Tags.

What are Build Tags

Build tags are a directive provided, in the form of a single line comment, at the top of a .go source file that tells the Go compiler important information about how it should deal with that file when go build is run.

For example, the following file will only be included in the build if the GOOS=linux environment variable is set:

// +build linux

package mypackage

...

The build tag needs to be placed as close to the top of the file as possible, and must have a blank line beneath it.

Tags can also be negated with the ! operator. E.g. A file with // +build !linux will be included in all builds that aren't on linux.

Tags can contain multiple conditions. If the conditions are on the same line then they are evaluated as an OR condition. If they're on separate lines they're evaluated as an AND condition.

// +build linux darwin
// +build amd64

package mypackage

...

The above example file will only be included in linux/amd64 and darwin/amd64 builds.

Separating Tests

Build tags can also be used to separate different types of tests, such as unit and integration tests, within separate _test.go files.

Let's continue with the example of unit and integration tests.

myfile_test.go:

package mypackage

import "testing"

...

myfile_integration_test.go:

// +build integration

package mypackage

import "testing"

...

There are two file examples shown above, the myfile_integration_test.go file contains a build tag of // +build integration, while the myfile_test.go file, where unit tests will be stored, contains no build tag.

When running go test in the directory where these files are stored the Go test runner will only run the tests in myfile_test.go. To run the tests within myfile_integration_test.go the --tags flag will need to be provided - go test --tags=integration.

There is one small problem though. Those following along probably would have picked up on this already. When running go test --tags=integration the Go test runner still runs the unit tests! To avoid this you can add a negation to the non-integration tests files, like so:

myfile_test.go

// +build !integration

package mypackage

import "testing"

...

With the above build tag included in all unit test files, the Go test runner will continue to run the tests when go test is used, but they will be excluded when running go test --tags=integration.

Why?

There are plenty of reasons developers might want to separate tests. Some simple example might be:

Integration tests are often slower, so you may want to only run them after the unit test (which are often much faster) have passed.
Smoke tests that are run against the live application, generally after a deployment.
Deploying the same app to different tenants.

Of course, this is by no means an exhaustive list! If you already separate tests sound off with why in the comments!

Conclusion

Build tags are a very useful tool within the Go ecosystem, and there are plenty of other possibilities above and beyond this one example. Head over to the go/build package documentation for more information!

Thanks for reading. Please feel free to leave a comment with any questions or comments!