No one agrees on what DevOps means - not even employers

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?

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.

For deeper dive into how, exactly, companies are applying DevOps, continue reading here.