This article is credited to Chandra Bergmann.

Here at Triplebyte, we design and conduct background-blind technical interviews. The goal is to quantitatively determine software engineers’ strengths and weaknesses so we can match them with roles conducive to their skills. We offer interview tracks covering different specializations, including generalist, front-end, mobile, ML, and, most recently DevOps. (All of these different interview tracks can be found here!) We’ve put a lot of thought, care, and data analysis into the design of each one to ensure that they’re really evaluating the skills that companies are looking for. In preparation for the release of any new track, we interview a lot of engineers and hiring managers about what they're looking for when they hire for pertinent roles. We usually find a clear consensus on what the relevant skills are.

When we did this for DevOps, we found no such consensus.

Everyone we talked to used “DevOps” to describe a wide range of roles. On one end of the spectrum, there are back-end developers who focus on building infrastructure and automation tools. On the other end of the spectrum, there are systems experts who serve as the first line of defense against production outages but rarely write code aside from the occasional shell script. Where companies land on this spectrum depends on their answer to one question: how much coding is involved in DevOps?

This is an important question, and at first, it may seem surprising that different companies had such radically different answers. However, the ambiguous expectations companies have for their DevOps employees make complete sense in the broader context of DevOps and the problems it arose to address.

DevOps is a philosophy before it’s a job title

There’s no one straightforward definition of what DevOps is, though the ideas behind it are deceptively simple. The foundation of DevOps is the obvious-in-retrospect observation that development (the act of creating software from whole cloth) and operations (everything that goes into keeping the software running after its conception) shouldn’t be siloed. Historically, development teams and operations teams were kept separate. This wound up resulting in all kinds of problems, from communication errors to perverse incentive structures. It was only within the last decade or so that the separation between development and operations was called into question, making way for the birth of DevOps roles as we know them today. Core ideas took hold as companies found new ways to combine development and operations, ultimately allowing them to ship software more frequently, more safely, and with shorter turnaround.

The philosophy of DevOps emerged in parallel with the Agile methodology, and both arose from a similar perspective. Agile development emphasizes shipping products quickly and then iterating on them based on how they work in production. Because the philosophy of DevOps asserts that operations are an essential part of the product, it promotes the idea that the same iterative approach should be applied to operations. In other words, DevOps can be seen as almost “super-Agile,” in the sense that it encourages quick iteration not only on the product itself, but also on the operations maintaining it.

In order to further prioritize constant improvement and iteration, automation also became a central component of DevOps. Integrating development and operations teams made it easier to build software that directly addressed the needs of operations, and automating as many day-to-day needs as possible allowed operations to scale more quickly. The idea of “eliminating toil” - or minimizing day-to-day drudgery - became a big part of the DevOps philosophy. “Infrastructure as Code” - a process that makes it much simpler to maintain and evolve a complicated production environment - caught on as part of the push for automation and quickly became a big part of most DevOps roles.

However, while some ideas have solidified, a more exhaustive answer to the question of what exactly DevOps entails is still being worked out.

So, how much coding does DevOps involve?

In the absence of a firm, established definition of DevOps, companies have been interpreting the term based on their own internal requirements. Implementation details differ greatly from company to company, and each company has different needs that might change over time depending on their resources. Small-scale startups tend to focus on getting a functioning product out the door as quickly as possible, so their DevOps engineers will focus a lot more on doing whatever is necessary to keep things running. Larger companies, on the other hand, have both the resources and the need to optimize their environment to their specific use cases, emphasize best practices, and build their own ways to automate repetitive tasks.

As an example, consider LiveRamp, one of the more established companies we spoke to. They have over 1000 employees and spun off from their parent company in 2018. They are now independent and publicly traded (NYSE: RAMP), giving them the resources needed to build their own internal tooling. As a result, their DevOps positions skewed much more to the “Dev” side. While they mentioned that they preferred their DevOps engineers to have familiarity with off-the-shelf tools, they were more concerned with a candidate’s abilities to ship code, build tools from scratch, and improve directly upon existing software. These custom tools run in production and customize the way their apps run, allowing even deeper automation and helping developers ship code better and faster.

Contrast LiveRamp with Cogility, a relatively early-stage ML startup. Cogility also hires through our platform, but they’re much smaller and are focused on growing as quickly as possible. As such, they don’t have as much time to focus heavily on building new internal tools from scratch. A representative from Cogility told us that, when hiring for DevOps roles, they prioritized finding candidates comfortable with off-the-shelf tools, with coding ability being only a secondary concern. (Though this isn’t to say coding isn’t involved at all: their DevOps roles will still entail writing configuration code and scripts.) DevOps positions at Cogility skew much more towards the “Ops” side: the focus is on using pre-existing software rather than making internal tools or even modifying existing tools.

Just about every company we interviewed described DevOps roles that fell at different points on the Dev-to-Ops spectrum. LiveRamp and Cogility sit on opposite ends of this spectrum, so their differences are unusually stark. Nevertheless, they serve to highlight a divide common among the companies we spoke to. Every company is different, and their differences are reflected in their approaches to DevOps.

How companies are applying DevOps

Given the degree of variance between DevOps roles in different companies, two different job postings labeled “DevOps” might be as different as apples and oranges. Still, apples and oranges are both fruit, and if you prepare yourself for an orange you will be less surprised to get an apple than, say, a piece of roasted chicken. Despite the variance, when talking to companies about what they were looking for in DevOps hires, we did find some common threads. Not all of these ideas were expressed consistently by every company, but they did come up frequently.

1. Communication. DevOps roles almost always require working closely with other teams, so communication skills are often considered a “must” for DevOps roles. This makes sense given that a major driving force behind the rise of DevOps was the need to break down communication barriers between different teams with different incentive structures.
2. Reliability. DevOps roles almost always require some on-call rotation. This stems from the “Ops” side of “DevOps” - while automation is a central component of DevOps, it’s impossible to automate everything perfectly, and it often falls on engineers in DevOps roles to handle things when the existing systems break, are being scaled, or are simply being iterated upon. Because DevOps engineers need to be able to drop everything and tackle urgent problems, it’s important for them to be able to work in an environment with frequent interruptions.
3. Familiarity with a cloud provider. DevOps roles usually require working with some cloud provider. This isn’t about “automation,” exactly, but it does come from the same philosophy of eliminating the toil associated with operations. Cloud providers (such as AWS, Google Cloud Provider, or Azure) allow companies to access computational resources while outsourcing many details of their maintenance. This can significantly increase iteration speed and decrease maintenance overhead, but it also requires a detailed understanding of how to work with whatever specific cloud provider a company is using.
4. Familiarity with containers. DevOps roles often involve working with containers and container orchestration tools. Not all companies use this approach for their infrastructure, but many do. Containers are a way of solving one of the major problems that arose when development and operations were more siloed - namely, that a program would run differently in a testing environment than in a production environment. In the past, operations teams ran their applications on different physical servers, and later on different virtual machines, to give each one its own isolated environment. Containers are a newer and lighter-weight technology that accomplish a similar goal, and they’re in the process of being adopted by most companies.
5. Security. Security should be built into every part of the DevOps lifecycle, and it’s important to be able to keep software secure without sacrificing speed or functionality. Automation of security processes is beginning to catch on, as is implementing a “DevSecOps” model, in which concerns for security are integrated all throughout the standard DevOps process.

The Takeaway

The ideas behind DevOps are relatively recent, and a consensus on how to best apply them has yet to be solidified. It may, in fact, be forever in flux. Their flexibility is a big part of what makes these ideas so exciting, and the range of skills and knowledge required to take on a DevOps position is a big part of why companies often have trouble finding good candidates to fill such roles.

That said, there’s still a very clear “DevOps” cluster of skills, which serves our purposes perfectly - the interviews we design at Triplebyte aim for breadth, and we match engineers with software engineering positions only after determining where their skills lie. Our new DevOps track covers everything from scripting to IaC to infrastructure design.

In the meantime, if you’re looking for a DevOps role, you should keep in mind the ambiguity as to how the term is applied. It can refer to a spectrum of roles, and you don’t want to get stuck in a position that requires a substantially different quantity of coding than you were expecting. And if you’re preparing for interviews, it can help to do a deep dive into the various core ways that DevOps tends to be applied.