©Shutterstock/New AfricaThe age of obtuse riddles and sweat-inducing whiteboard interviews is waning — and for good reason. If a whiteboard interview is facilitated by an engineer who cares more about tricking the candidate than they do about discussing a technical conversation, you’ll go nowhere fast.
Whiteboarding interviews have taken a lot of heat recently for putting underrepresented and marginalized groups — which includes women and people of color — at a disadvantage. In this age, it’s absolutely vital for tech companies to hire diverse workforces, so this situation is unacceptable. However, you have to somehow gauge a person’s technical ability.
What’s the answer? Well, the good news is you have options. (The bad news is . . . you have options.)
How you hire will determine who you are.
Revisit the whiteboard interview for DevOps job candidates
The whiteboard interview was never intended to be what it has become. In one whiteboard interview, the DevOps candidate was handed a computer program printed on eight sheets of paper. The instructions? “Debug the program.” Umm . . . excuse me?The whiteboard interview has become a situation in which you give a candidate a seemingly impossible problem, send them up to the board with a marker, and watch them sweat profusely while four or five people observe their panic. This type of interview provides no one with quality information on whether either the employer or the interviewee is a good fit for the other party.
Although others have called for the elimination of the whiteboard interview, here’s a more nuanced suggestion: Change it to make it fit your DevOps needs. Make it a discussion between two people about a piece of code or a particular problem. Don’t make the problem something crazy, such as balancing a binary search tree. Unless the job you are interviewing for is literally writing code in Assembly, you do not need to evaluate the candidate’s ability to write Assembly.Be cognizant of the DevOps job you are looking to fill, the skill sets required, and the best way to measure those skills in a candidate. Have a single engineer on your team sit down with the candidate and talk about the problem. How would you start the conversation? What problems do you run into along the way? How would you both adapt your solutions to the challenges you encounter?
This conversational approach accomplishes two things for DevOps job candidates:
- It reduces panic. Most people don’t think well under pressure. Plus, you don’t do your job everyday while someone stares over your shoulder, criticizing every typo or mistake. You’d quit that job in an instant. So don’t force people to interview that way. Instead, give your candidates the chance to show off what they can do. You’ll gain insight into how they think and communicate.
- It mimics real work. The conversational interview gives you an idea of what it would be like to work with this person. You don’t solve hard problems at work by watching each other struggle. (At least, you shouldn’t. Really. That’s not very collaborative or DevOps-y, leaving your colleagues to suffer in their silo.) Instead, you work together, trade ideas, think things through, make mistakes, recover, and find a solution — together.
Offer take-home tests to DevOps job candidates
An alternative to a more traditional whiteboard interview is the take-home test. This type of test is particularly friendly to people who have any kind of anxiety or invisible disability that impacts their ability to participate in a whiteboard interview. This style of interview is also friendly to engineers who struggle intensely with imposter syndrome.Imposter syndrome describes high-achieving individuals who struggle to internalize their successes and experience a persistent feeling of being exposed as a fraud.
A take-home test consists of some type of problem that a DevOps candidate can solve at home in their own time. Take-home tests are often set up as a test suite for which the candidate must write code to make the tests pass.
Alternatively, the problem could be something relatively small, such as, “Create a program in [your language of choice] that takes an input and reverses the characters.” The options are endless, and you can tailor the test to your tech stack as you see fit.
You can even ask DevOps job candidates to deploy their application. Ensure that you allow candidates to use open source tools or provide them with the necessary subscriptions to use particular technologies.
The major drawback to take-home tests is that you’re asking people to take time during their evenings or weekends to do what is essentially free work. Even if you pay them for their work on the take-home test, this style of interview can unfairly impact a DevOps candidate who has other responsibilities outside of work, including caring for children, a partner, or ailing parents.
Not every great engineer has unlimited time to commit to their craft. But if you limit your DevOps candidate pool to people who can afford to dedicate 5–10 hours to a take-home test, you’ll quickly find your team becoming homogenous and stagnant.
Review code with DevOps job candidates
One interview technique that can be really telling is when you sit down with an engineer, or a group of engineers, to solve real bugs in real code together. You can take a few approaches to a real-time code interview.You can mimic a take-home test and give the candidate an hour or so to create a program or write a function to make a series of tests pass. You can also stage the interview like a code review in which you pull up an actual PR and dig into what the code is doing as well as what could be improved.
In many ways, the pair-programming nature of a code review combines the best parts of both a whiteboard interview and a take-home test — but without some of their major drawbacks.
Pair programming is an engineering practice in which two engineers sit down and work through a problem together. Typically, one person “drives” by owning the keyboard, but they collaboratively decide what approach is best, what code to add, and what to take away.
If the DevOps position involves an operations-focused role, using this real-time coding approach is even better. Although many ops folks are learning to implement infrastructure as code or manage configurations, they don’t have the same experience as developers.
Reviewing what something does and how it might work is a fantastic way to confirm that the candidate has experience in the tools and technologies list on their résumé as well as ensure that the candidate can communicate with a team.
Building your DevOps team is an individual pursuit. Your DevOps team does not need to match others you have seen. Evaluate your goals and select the right candidate for each DevOps job.