Triplebyte Hiring Blog

Hire the best engineers with Triplebyte
Start hiring

Share this article

No one agrees on what DevOps means - not even employers

By Chandra Bergmann on Nov 21, 2019

No one agrees on what DevOps means - not even employers

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.

DevOps-spectrum.png


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.

Stop wasting time on bad candidates. Start hiring great engineers.

Start Hiring

Liked what you read? Here are some of our other popular posts…

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More

Bootcamps vs. College

By Ammon Bartram on May 19, 2016

Programming bootcamps seem to make an impossible claim. Instead of spending four years in university, they say, you can learn how to be a software engineer in a three month program. On the face of it, this sounds more like an ad for Trump University than a plausible educational model.

But this is not what we’ve found at Triplebyte. We do interviews with engineers, and match them with startups where they’ll be a good fit. Companies vary widely in what skills they look for, and by mapping these differences, we’re able to help engineers pass more interviews and find jobs they would not have found on their own. Over the last year, we’ve worked with about 100 bootcamp grads, and many have gone on to get jobs at great companies. We do our interviews blind, without knowing a candidate's background, and we regularly get through an interview and give a candidate very positive scores, only to be surprised at the end when we learn that the candidate has only been programming for 6 months.

Read More

How to pass a programming interview

By Ammon Bartram on Mar 8, 2016

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More
Get the Triplebyte newsletter Subscribe

Get the Triplebyte newsletter

Be the first to get the latest Triplebyte content straight to your inbox.