DevOps is not a new term in the IT world — it has been around for almost ten years. Interestingly enough, as old as the field is, DevOps is still defining itself.
The ever-evolving definition of DevOps is also challenging from an HR perspective, and DevOps managers are increasingly dealing with the challenge of defining DevOps roles within their organizations and finding DevOps talent.
In this post, I’ve put together a list of ten questions that can be used as a point of reference when interviewing DevOps engineers. If you’re a candidate, this list will also help you to prepare for interviews. Here is a quick list followed by a more in-depth explanation and follow-up questions for each one.
(Note: at Logz.io, the focus of the DevOps team is on CI/CD, production operations, and performance investigation and troubleshooting — some companies may have a slightly different focus, so keep that fact in mind.)
Some Common Questions in DevOps Interviews
What have you been doing over the last one to two years?
Interviews do not have to adhere to a specific framework and can be dynamic in nature. To get a general perspective on what a candidate has done, it’s a good idea to start an interview with a general query into the engineer’s recent professional activities.
This will help you, a DevOps manager, to understand what specific tools and technologies the engineer has been working over the past few years (these can include Git, Puppet, Jenkins, Docker, Ansible, and scripting languages). Also, it will reveal the candidate’s ability to work in a team, as the candidate will most likely divulge whether he or she flew solo or was part of a bigger outfit. If the person’s answer does not include this information, then that is another must-ask question.
It is critical to take note of the roles in which the candidate has served and the tasks that the candidate has performed, even if they are not strictly required in your organization or in the role for which he or she is interviewing. If the prospect does not mention the exact tools that you currently use, follow up with questions about those tools and tasks to get a good feel for his or her ability to assimilate knowledge as well as his or her general operating dependencies. Good candidates will always demonstrate a deep understanding in the field of their operation while others will reply with superficial answers to drill-down follow-up questions.
2. How do you deploy software?
This question is critical for any DevOps position. As more and more DevOps teams move towards automating and adopting continuous delivery best practices, it is critical to gauge whether the candidate is comfortable talking about code deployment and whether he or she understands how all of the available Continuous Integration tools and DevOps tools fit together. If you have a drawing board available, let him or her build a diagram for you.
Depending on the answers that you get, you can develop further lines of questioning dynamically. For example: “Do you have a database in the stack?” “How do you update the schema?” “What tests do you run, and how do you run them?” “If all tests pass, how is the code deployed into production?” “How do you make sure that you do not lose traffic during deployment?”
3. How have you handled failed deployments?
Failed deployments, of course, are an all-too-common occurrence when deploying code. DevOps engineers need to be extremely hands-on — they need to know when something has gone wrong and then troubleshoot the issue as quickly as possible.
A good way of assessing the suitability of a candidate is to ask them to tell the story of a failed deployment and how it was handled. Specific, follow-up questions can include: “How do you know there was a deployment failure?” “Do you roll back automatically?” “What criteria do you use?”
4. If something breaks in production, how do you know about it?
Monitoring is a huge component of DevOps work (and this is reflected by the multitude of monitoring tools and platform out there). Regardless of the specific tools that you use and the monitoring system that you employ in your company, you need to know how well-versed the candidate is in planning and executing a monitoring strategy.
Again, you could use the storytelling tactic: “Tell me about a crisis in production that you had, how you became aware of it, and how it was solved.” A good war story is always enlightening — it will help you to assess not only how skilled the candidates are in monitoring but also how they handle crises (assuming that they tell the truth, of course).
Other leading questions: “What monitoring tools do you work with?” “Did you choose them? If so, why?” “How do you get alerted?” I have found that the best candidates will have plenty to share about their monitoring expertise and specifically about advanced user-experience monitoring techniques.
5. What happens when you type “mv *” in a directory with three subdirectories a, b and c?
Of course, this question — and the responses — can vary, but the idea is to gauge the technical expertise of the engineer in a Linux environment, which is a “must” in almost all DevOps positions.
It’s a good idea to change the bash command as you receive the answers. If you feel the questions are too easy, try raising the bar with more advanced bash questions. For example, “What is the difference between ‘cmd1 ; cmd2’ and ‘cmd1 && cmd2’?”
You might want to prepare a quiz sheet with a list of five to ten commands. This way, the candidate will find it easier to answer.
6. Without using Docker, can you see the processes running inside a container from the outside?
OK, we cheated here. Not every company is using Docker or even containers at all, so this question is a bit technology-specific. Based on our expertise and on the data in The 2016 DevOps Pulse survey that we recently released, more and more companies are moving to microservices and containerized architectures. So, we added this question to the list.
Of course, this question is meant to figure out whether the candidate understands how containerization works. Instead of asking “How do containers work?” or “What is a Docker image?”, the answer to the question above will inform you whether the person gets it. Other questions may include “How does container linking work?” or “How and why would you optimize a Dockerfile?”
7. Describe the Linux boot process.
This is another question meant to gauge the candidate’s system understanding and Linux expertise.
A good candidate will be able to detail the correct order and significance of at least some of the various stages (i.e., BIOS, MBR, bootloader, kernel, initialization, and runlevel). To drill down further, I’d recommend a follow-up question such as, “What information needs to be provided to the bootloader?”
8. How does ‘traceroute’ work?
Any DevOps interview has to include networking questions.
Many candidates will not know the answer to this question while others will offer only a partial answer. A good way to separate the DevOps wheat from the chaff is to see if the candidate only explains that the command prints the route that packets take to the network host or if he or she also delves into the “how.”
Even if you do not receive a correct and complete answer, this question is a good starting point for a deeper conversation in which you can brainstorm with the candidate. In this process, you can try to come up with valid possibilities and discount invalid ones based on a solid understanding of IP routing.
Another example of a good networking question that I often use: “What is the difference between trying to connect to a port that is not being listened to as opposed to one that is firewalled in terms of TCP?”
9. Do you consider seven to be a high load average?
Logz.io is an AI-powered log analysis platform that offers the open source ELK Stack as a cloud service, so we do our healthy share of performance testing and tuning. We need our DevOps engineers to understand the fundamentals of system performance monitoring for both planning purposes and troubleshooting issues in production.
This question enables you to learn whether the candidate understands the meaning of load average in the first place. If they understand and explain that it is not CPU usage, it is a great opening for a deeper discussion on troubleshooting performance.
Useful follow-ups: “Is it possible to observe high load with low CPU usage? If so, what may be the reasons? How would you check?”
10. Do a FizzBuzz coding test.
The main idea of the FizzBuzz test is to see how a developer handles an easy coding task. Live simulations are a good way to see how quick engineers are on their feet as well as how they grasp a simple task and then translates it into code.
The candidate should:
Write a program or script that prints out the numbers between 1 and 100. For each number that is divisible by three, “Fizz” is printed. For each number that is divisible by five, “Buzz” is printed. For each number that is divisible by both three and five, “FizzBuzz” is printed. Most good developers should be able to write such a program on paper within a couple of minutes. See how they write the code, ask them why they wrote specific parts in certain ways, and then check the validity of the code.
As I implied in the introduction, the questions in a DevOps interview will vary from organization to organization. Different companies use different technologies and will look for different expertise and skill sets. Also, these questions will vary based on the amount of experience you specifically need. Still, the list above contains questions that I have found to be relevant to any DevOps engineer position.
I have conducted many, many DevOps engineers interviews, and each one has been different. Though I always start with the same set of questions, I quickly find myself veering off into unexpected ones. After all, a good interview is dynamic and adapts to the specific candidate’s answers and technical expertise.
What questions do you ask in DevOps interviews? What questions have you been asked? I invite you to comment below.