In a previous post, I put together a list of 10 questions for DevOps team managers to use as a point of reference when interviewing potential DevOps engineers. Each question included an in-depth explanation and follow-up questions, so in case you were, or are now, a candidate, that list could help you prepare for interviews.

To help candidates even further, I’ve prepared this cheat sheet for those preparing for an interview for a DevOps position. Each organization and team is different of course, using different technologies and methodologies, but coupled with research on the organization you are interviewing at, these tips can be quite the resource.

What have you been doing over the last 1-2 years?

This is probably one of the best opportunities to let the potential employer know that you are a good fit for the role. You should practice answering this question, and make sure that your answer includes the proper terms of the industry, and that you know what they mean.

Make sure to provide information about your drive for automating things (explain why and give examples). Mention the tools you’ve used and be prepared to explain why you chose them. It is also a good idea to use this question to bring some of your personality traits to light: let them know that you took responsibility of something, mention how you excelled in one area or another, ideas you had, organizational changes you advocated, etc.

How do you deploy software?

At this point,  you’re expected to go into the details of your deployment pipeline. It’s okay if the pipeline is not automated, but for each step, it’s a good idea to describe what is happening, what is good about it, and what are its weak spots, along with suggestions for improvement.

A bonus is to weigh in the benefits of each of these improvements along with the cost (in time and risk) of implementing them, and to propose an effective roadmap for this critical part of work.

In certain parts of the interview, it is good to mention your use of source control, and why you are using it like that and not in another way. In general, it is very important to be able to answer “why” questions. Most of the time they are more important than the “what” questions.

Lastly, talk about your infrastructure changes, and how those are performed (hint: infrastructure as code).

How have you handled failed deployments?

First of all, it is important to demonstrate that you are not afraid of failures, that you understand that they are a part of the process , and that failures need to be taken into account by reducing the time it takes to fail a component and having sound rollback processes in place in advance.

Talk about how much of this failure handling is done manually and how much is automated. It also shows professional maturity to have (and mention) a sound lesson learning function in your organization.

Lastly, don’t forget to mention the plan moving forward, when is it decided, and how the systems that are in place are conducive to that goal.

If something breaks in production, how do you know about it?

Talk monitoring, monitoring and more monitoring. Both applicative (are my users able to login? how long do my pages take to load? are there exceptions in my logs?) and resource usage/capacity.

If your environment is dynamic, talk about how your monitoring infrastructure is automatically modified to reflect your monitored environments. Do not forget to talk about escalations and customer communications.

What happens when you type “mv *” in a directory with three subdirectories: a, b, and c?

The answer is that the directories “a” and “b” are moved into “c”. The talking points are shell expansion, and understanding that “mv” can take any number of arguments, the last of which is the target.

The significance of this question is not in knowing the specific answer to it, but knowing enough about shells to not say silly things.

Without using Docker, can you see the processes running inside a container from the outside?

Yes! This is an opening for you to demonstrate your understanding of containerization fundamentals. ‘Docker-containerd-shim’ is the parent process of a process running inside a container, so it can be used for digging from the host OS, using simple ‘ps’ commands.

Docker is not a virtualization technology, but rather uses Linux building blocks such as groups and namespaces to provide isolation. As such, processes do not run on a separate (Guest) OS.

More useful information can be found in Jérôme Petazzoni’s talk on slideshare, or in his DockerCon EU 2015 talk on YouTube

Describe the Linux boot process.

Needless to say, this question is aimed at gauging your system understanding and Linux expertise. I will not go into the whole explanation, but you can check out this resource for reference:

How does “traceroute” work?

This, in a sense, is a very tricky question. More often than not, it does not require knowing the actual answer (although that would be a big plus), but it does require being able to talk about, and discard (for not making sense) any potentially erroneous ideas to what the answer might be.

Traceroute sends multiple packets to the destination, with ever-increasing TTL (starting with 1), and listens for the incoming “time exceeded” responses coming in from all the intermediary routers.

More useful information on this is available here:

Do you consider seven to be a high load average?

A question aimed at gauging your understanding of the basics of system performance monitoring. “Load” numbers are always relative to the number of CPU cores on the machine. So a plain “7” is meaningless. Could be low or high if the host has more than, or fewer than, 7 processor cores.

Even then it does not directly mean much, and is indicative of the number of processes that are waiting for resources (these could be disk, network, cpu, etc.)

Do a FizzBuzz coding test.

It goes without saying, but I’ll add this anyway – it’s important your answer is correct:

  • Make sure your answer actually finds all the numbers along the way
  • Make sure it stops at the right moment
  • Make sure there are no glaring syntax errors
  • Make sure to catch all cases (a common mistake is that the “buzz” condition is never verified when “fizz” condition is met.)

It’s equally important how you behave while trying to solve this test. If you are blanking-out, try not to disrespect the question (this has happened to many candidates of ours before), complain or otherwise behave in a negative manner. Nobody wants to work with someone who can’t take a little adversity.

In summary

If you’re wondering why these questions are asked in the first case, I recommend referring to the previous article listing the questions. Suffice to say, organizations are finding it increasingly challenging to find talent and these questions are meant to separate the wheat from the chaff.

The fact that there is great demand for DevOps talent is the good news. The bad news is that there are many fantastic engineers out there competing for the same positions. So use this cheat sheet, prepare yourself, do your research.  

As I mentioned in the previous article, I have conducted many, many DevOps engineer interviews.  Each one has been different than the other. But what has made a difference between good candidates and excellent candidates is how solid their foundation was, and how sound their reasoning was for each question.

Lastly, and this probably goes without saying, we hire people who we would like to work with so being nice also helps 🙂

Observability at scale, powered by open source

2022 Gartner® Magic Quadrant for Application Performance Monitoring and Observability
Forrester Observability Snapshot.

Detect & Investigate Threats at Speed & Scale

Learn More