Aleksei Fedorov
6 min readApr 1, 2022

How to evaluate your DevOps skills, how much you need to know to pass interview to DevOps engineering?

The basics about DevOps and responsibilities:

DevOps is a set of practices that help automate and integrate the processes between development teams and teams responsible for infrastructure (operations) so that they can build, test, and release faster and more reliably. (Please see details https://www.atlassian.com/devops)

The main goal of the DevOps approach is to remove the “wall” between the development team and the operations team (operations are also called: System Administration, System Engineering, Infrastructure, IT) and to increase the speed of releases. The “wall” is formed because Dev and Ops have different goals. Developers aim to release as often as possible, and Operations aims to reduce the number of infrastructure fails or keep the environment stable and secure. The DevOps approach brings teams, goals, and risks together.

The main DevOps practices are:

  • Infrastructure as Code
  • Continuous Integration
  • Continuous Delivery
  • Continuous deployment
  • Continuous Testing
  • Continuous Monitoring

These practices are also the primary responsibilities of a DevOps engineer. Some practices can be divided between engineers. For example, QA may be responsible for Continuous Testing and Security Engineer for Continuous Monitoring. As a rule, the engineer who got the DevOps role (it’s not customary to say “DevOps engineer”, but the market has already taken over, sounds as vague as “Agile engineer”) is responsible for everything that happens from the moment the development team pushes the code to the repository or launches a feature. Which means that DevOps can be responsible for CI/CD pipelines, project environment, basic monitoring etc.

How many tools are there in a DevOps domain? What exactly do you need to know?

PROD grade infrastructure, IaC, CI/CD pipelines, monitoring, security, etc… Are an entire ecosystem of tools. Now there are more than 100 popular names. Some of them you need to know deeply and be able to configure. Some just need to be configured once by reading the short documentation.

If you have just started working in IT, the questions arise: what to choose, how many tools do you need to know, and what should be demonstrated at in an interview?

Engineers who migrate to DevOps, for example from system administration, learning technologies, fear that they will be tied to one thing and for another project their experience will not be relevant. For example: you learned Ansible but for the project Terraform is required.

I want to comfort you: if you have learned how to write Terraform code, you will be able to cope with Ansible, not because they are similar or close in syntax, no. Your brain is now able to solve automation problems, and your psyche has strengthened its faith in itself. During the interview, this will be noticeable and in most cases will cause respect from the interviewers. Therefore, you should not strive to learn a large number of instruments. If you have just started studying, choose the tools that you are really interested in, this will give you a positive energy and pleasure from the learning process. Don’t chase the market, don’t try to match it completely. First, do what you love.

How many tools/platforms and how deep do you need to know?

To make selection easier, all DevOps tools can be divided into domains:

DevOps tools by domains (I made this difficult infographic for two days)

The picture shows 30 most popular tools divided by their respective domains, you can add domains or tools as you need. Trying to learn everything is pointless, long and demotivating. It’s better to choose one or two tools from each domain and compile a small, personal competency matrix, from tools you really want to know, for instance:

  • IaC: Terraform
  • CM: Ansible
  • Cloud: AWS
  • CI/CD: CircleCI
  • Scripting: Python, Bash
  • Containerisation: Kubernetes
  • Monitoring: ELK, Prometheus
  • OS: Linux
  • SQL: Postgres, MongoDB

The number of tools has been greatly reduced, but the list is still large. There is a risk that inexperienced interviewers-engineers will come to the interview, and if you indicate everything from your project or experience in your CV, they can check your knowledge of all the tools you declared, expecting an advanced level from you. Such interview will be difficult and frustrating. It is better to manage expectations and indicate the level of proficiency in a tool or platform, by separating relatively simple and conditional categories:

Novice — used the tool/technology once or read the documentation. (This category has the right to exist, for example, I installed and configured MySQL for various projects, I have done it thirty times, but each time I read the instructions. Without prior preparation, I will not talk well about MySQL. Nevertheless, you should not get carried away if you specify in CV is all that you “read”, the resume will lose specifics).

Intermediate — confident use of technology/tool (important note: this level of experience can be achieved through learning).

Advanced — wide experience in using the tool/technology on projects, repeatedly had to configure/write code, hands-on experience at least for a year. The duration of the hands-on experience is extremely important. We can say that the Advanced level is acquired on PROD projects, but sometimes a training project can be more complicated than a real PROD customer.

Expert — used the technology on complex projects for a long time from a year or more. Is a committer, knows the technology better than the manufacturer.

*these categories can be criticised in the comments, this will allow us to develop a more accurate model.

Now we have the following matrix:

  • IaC: Terraform — Advanced
  • CM: Ansible — Intermediate
  • Cloud: AWS — Intermediate
  • CI/CD: CircleCI — Novice
  • Scripting: Python, Bash — Novice
  • Containerisation: Kubernetes — Intermediate
  • Monitoring: ELK, Prometheus — Novice
  • OS: Linux — Advanced
  • SQL: Postgres, MongoDB — Novice

Wow, we have greatly narrowed the area. If you are just entering the profession, with such a matrix it is easier for you to build goals (e.g. learning goals). If you go to an interview, this matrix shows what needs to be improved and what topics to talk about.

You can indicate these levels of proficiency in the CV, but I would recommend highlight the main tools you work with on the project and the Novice category in a separate line. This is necessary in order to have a conversation on a specific experience.

Here you can add one more level of evaluation: if you apply for the position of Senior DevOps Engineer, you need to know 3–4 tools at the Advanced level and one tool as an Expert. For Middle DevOps, it is enough to have 2–3 in Advanced.

In total, your competency matrix:

Middle DevOps Engineer

  • Terraform, Linux — Advanced: main experience
  • AWS, Ansible, Kubernetes — Intermediate: have to solve problems regularly
  • ELK, Prometheus, CircleCI, Python, Bash, Postgres, MongoDB — Novice: General Understanding

Being specific in your CV and at the interview eliminates frustration, inspires confidence, and saves you from wasting time on preparation (for example, if you don’t want to learn SQL), allowing you to focus on what really needs to be improved.

Over the past 3 years, I have conducted about 180 interviews for the roles of DevOps, Senior DevOps and Team Lead in various teams and with different interviewers. I myself had to go through interviews with customers within the company. In an interview, my goal is to reveal how the candidate’s experience matches the declared one and how it meets the customer’s expectations. I also check if our expectations for an open position are fit the market, if they are lower or higher and if we can influence this. The experience of the interviewee should not coincide with the requirements for the position by 100%. But unfortunately, approximately 70% of interviewees fail the interview despite the fact that it is just a conversation about the experience declared by the candidate, without tricky questions. In fact, in an interview you need to show that you know what you have encountered and have experience with, what you don’t know, but would like to develop and motivate. An adequate assessment of your experience, general erudition and motivation are the key to a positive interview.