Note: This is an updated version of a post that was originally published on August 13, 2018.
It’s hardly a well-kept secret: Now is a great time to be on the DevOps job market.
As the culture and practice of DevOps spreads, companies are hiring to build out their teams. And they’re really hiring. At the time of this writing, a national search on Glassdoor for “DevOps” turns up nearly 66,000 open positions. You’ll find similar numbers on LinkedIn.
Just because the market is hot right now doesn’t mean you’re going to breeze your way into a new gig, though. You’ll still need to ace that interview—often multiple interviews—and that means careful preparation. Study the company and be sure you understand the specific requirements of the role. For DevOps interviews, you’ll also want to think about how the interviewer is going to gauge the depth of your understanding of DevOps.
You can certainly find example questions online, including company-specific interview questions for various DevOps-related positions, such as “DevOps engineer” or site reliability engineer (SRE).
Glassdoor users, for example, sometimes post questions from actual interviews. You can also find example questions on Quora or GitHub. These are all great places to start, but questions posted online don’t always come with reliable advice—if any—on how to best answer those questions.
Moreover, because you can’t actually predict the exact questions you’ll be asked in an interview, a better strategy might be to prepare for particular types of questions—and, better still, seek out trusted expertise and advice on how to develop honest and authoritative responses.
A framework of critical DevOps interview questions
To give your DevOps interview prep a serious head start, we built a framework of critical DevOps interview questions and invaluable insights on crafting answers to them.
First, we talked to a pair of New Relic pros with deep experience building and working in DevOps teams: solution consultant Eric Mittelhammer and software engineer Beth Adele Long. We also connected with Jim Johnson, senior vice president at national recruiting firm Robert Half Technology to find out the kinds of questions companies are currently asking DevOps candidates during phone and face-to-face interviews.
Q: How would you describe the functions of an ideal DevOps team?
Right off the bat, here’s an interview prompt that, as Eric notes, intersects all facets of DevOps. It’s almost inevitable that you’ll face one or more “big picture” questions like this to test your understanding of DevOps and to show that you see it as more than a set of tools or a development methodology.
This is a rather open-ended question, Eric says, and the answer can include points and anecdotes about processes, tools, and culture. But they should all center around the theme of removing obstacles that slow the pace at which code is delivered to end users by using the right tools to give you the confidence to do it.
In answering, you’ll want to hit themes like:
- Reducing the boundaries between those who own software and those who own hardware
- Empowering teams to make decisions about the tools and infrastructure they use
- Encouraging small, frequent code releases that address as narrow a scope of functionality as possible (small changes are easier to roll back and fix)
- Eliminating testing and QA environments
- Releasing directly to production and relying on instrumentation and performance metrics to validate releases
Q: How would you describe DevOps?
Here’s Jim’s—our recruiter—perspective for developing a strong response to this question:
“Make sure you highlight the main goal of any DevOps project, which is to improve collaboration in planning and delivery to achieve faster deployment of a project, service, or software to create business value. Dive further into your answer by listing some technical and collaborative examples of DevOps projects you’ve worked on, or perhaps studied, in the past. The employer wants to know your familiarity with the DevOps process and gauge your experience level.”
The bottom line with these big-picture, high-level questions about DevOps is simply to be prepared for them. On the surface, they seem straightforward, but if you haven’t developed a cogent response, they could leave you hemming and hawing during the interview, which is never a good position to be in.
Jim recommends leaning significantly on your past experience. (More on that in a moment.) If you’re just starting out, though, you can study up on DevOps success stories, as there are plenty floating around. Media giant Gannett, for example, is a great case study in DevOps success.
Related links:
- Case study: Etsy, Sprouter and Conway’s Law (IT Revolution)
- Case study: What the enterprise can learn from Etsy’s DevOps strategy (ComputerWeekly.com)
Q: Can you describe a previous success within your DevOps experience?
Being able to illustrate your big-picture understanding of DevOps with a particular project or team experience is incredibly useful in an interview setting. It lets the hiring team know that you’re the real deal, rather than someone who’s just littering their resume with a bunch of DevOps-oriented catchphrases and hoping for the best.
Even if you haven’t had significant real-world DevOps experience, try to put your past experience in the best light, and ensure that you can connect your individual contributions to the broader team and business:
“Bring up projects in which you’ve been a key player,” Jim says, “How did you help your team succeed? What technology and processes did you use? What value did this project bring to the business? Touch on the project as a whole, but also emphasize your main contributions and how your team worked together.”
Q: What skills have you learned to help you better succeed in a DevOps role? How did they help?
At just about any career stage or experience level, hiring managers in DevOps environments tend to look for people who show a commitment to continuous learning and skills development. Tool X might be the best solution for a particular process or problem today, but there’s no guarantee it will still be right for a problem that arises tomorrow. Take the time to reflect on how you’ve added new skills and experience over time, whether it was learning a new programming language, building a sandbox project to learn a new cloud platform, or taking advantage of educational opportunities offered by a previous employer.
Jim says: “Be prepared to talk about any certifications or skills you’ve gained, why you did so, and any results that may have come from it. The employer will want to know how dedicated you are to your professional development. It also shows that you went above and beyond to meet a challenge or fill a need for the business.”
Q: Explain why proper instrumentation and measurement are so integral to DevOps culture and process. How do you use them in a development and deployment workflow?
This is another great example of the need to be able to connect the dots between the technical aspects of DevOps and equally important pieces like culture and measurement.
For advice on answering such questions, Eric says it’s important to know that “DevOps relies heavily on automation and tools rather than people and process. Properly instrumented systems will let us know when they are under stress, rather than relying on humans such as testers—or even worse, end users—to discover those conditions. Candidates should be able to describe a workflow in which they make small, atomic, incremental changes. Their deployment process should be as automated as possible, and they should use instrumentation tools to verify the impact and correctness of their change.”
Don’t miss our post Guide to Measuring DevOps Success
Q: How do you define observability, and what advice would you offer an organization working to improve the observability of its systems?
According to Beth Long, some organizations will introduce the concept of observability into a conversation around measurement and instrumentation. While the use of a single term may not seem like a game-changing distinction, Long notes that it provides some very important insights into a team’s DevOps practices and culture.
“Observability is a measure of your ability to understand what’s really happening inside a system,” Long says. “It’s a critical concept today, as we deal with increasingly complex, distributed, and often ephemeral application environments where it’s often very difficult to understand the properties of an application and its performance.”
According to Long, how you go about instrumenting a system can have a huge impact on your ability to monitor and gain visibility into it. “You instrument and monitor a system as part of a broader strategy to make the system more observable,” she explains.
Long recommends that a candidate break observability down into two issues, both of which tie into DevOps practices and priorities: “First, you need to understand what types of data flow from an environment, and which of those data types are relevant and useful to your observability goals,” Long says. “Logs, traces, business analytics, data from third-party tools—all of it needs to be assessed and integrated.”
Second, Long states, it’s necessary to get a clear vision of what a team cares about. “What’s our strategy for making sense of all this data—distilling, curating, transforming it into actionable insights into the health and performance of your systems.”
Finally, Long points out that questions about observability offer potentially useful clues about an organization’s DevOps maturity level.
“Observability as a concept has been around for decades—it’s far from new,” she says. “But as a concept for working with modern application environments and for getting value from measurement and instrumentation, it’s a relatively recent development—and it suggests that an organization is at least paying attention to what’s happening on the cutting edge.”
Learn more about Observability and Instrumentation: What They Are and Why They Matter
Q: If there is a new technology or process you’d recommend for improving our DevOps strategy, how would you evaluate said improvement?
Candidates may overlook the importance of measurement to DevOps, thinking it’s something to consider after they get the job. But a high-functioning DevOps team is definitely going to want to gauge how you measure the efficacy of tools and processes.
Here’s Jim’s advice on developing a good response to this question:
“DevOps transformation relies heavily on a team’s ability to implement new tech and processes. You should explain how you go about researching, evaluating, and trying out new technologies and strategies, and how you would explain to stakeholders how this will improve the project and create value for the business.”
It’s pretty likely the interviewer is going to want to hear about how you’d evangelize the value of DevOps to the broader organization when necessary; they’re also ensuring that when it comes to things like selecting a new tool, you’ll be more thoughtful than “throwing some spaghetti against the wall to see if it sticks.”
Q: What does “infrastructure as code” mean, and how does that idea fit into DevOps culture?
Automation is one of the fundamental concepts of DevOps—it’s what makes the promised speed, agility, and efficiency possible. For many organizations, thinking of infrastructure as code is the key their overall automation strategy. As Eric explains:
“Infrastructure as Code is the practice of managing infrastructure with a single ‘source of truth’ such as a configuration or source code file that can be versioned and used by automated systems to create, provision, and configure infrastructure with minimal human involvement. This greatly increases the speed at which new systems can be provisioned and existing systems can be expanded, scaled, and improved. Furthermore, it allows the team developing the software to specify exactly what they need, without necessarily having to know how to provision it themselves.”
Depending on the organization and its job description, DevOps candidates may also want to bone up on infrastructure automation tools and container technology:
- The Best Tools for Cloud Infrastructure Automation
- What Is Container Orchestration?
- Docker vs. Kubernetes: It’s Not About One or the Other
Q: How would you go about diagnosing and fixing problems in production?
You should expect questions on process and practice; the interviewer will want to know how you go about solving problems in your day-to-day job. Eric advises focusing on the importance of metrics and using the proper tools to monitor the metrics that matter most to the organization, so you can act when necessary:
“Candidates should talk about which performance metrics are important to them and why. They should discuss both user-focused timing and latency metrics, such as response time and Apdex score, as well as application-wide quality metrics such as error rate and throughput. They should know how to use their tools to alert them to critical conditions on these metrics, and then describe how they can use them to drill down to find out what specifically is causing the problem.”
Related link: DevOps Without Measurement Is A Fail
Q: How would you take our company’s DevOps strategy to the next level?
If you’re going for a mid-level or senior position, the interviewing team will likely ask for your thoughts on the next phases of its DevOps transformation. This is definitely a “big-picture question,” but you’ll want to specifically connect your skills and experience to this particular position and organization. Jim suggests answering this way:
“The hiring manager wants you to think strategically and apply your previous experience to the challenges they’re facing. It would be beneficial to explain that you understand DevOps is a culture as well as an efficiency process, creating a collaborative environment across teams. Discuss any improvements you’d make to the collaboration factor of their DevOps strategy in addition to any technologies you’d recommend to the team.”
The importance of this question lies in the fact that successful DevOps teams—and the executives and managers responsible for building them—know that there’s no completion date for a DevOps journey. It’s about continuous evolution and improvement. You’ll want a thoughtful answer that offers specific ideas on what that continuous evolution and improvement might look like for the particular team or company interviewing you.
Finally, what should you ask the interviewer?
Conventional wisdom recommends that you always ask a few questions of your own in a job interview; it shows that you’re not only interested in that particular employer, but that you’re also “interviewing them.” Moreover, it shows you want to understand their particular iteration of DevOps culture, which is especially important given that there’s not really a one-size-fits-all blueprint.
When it’s your turn to ask the questions, Eric suggests the following:
Q: How quickly do you expect new hires to begin contributing and deploying code?
This might seem like a very specific question, but it’s a great way to tell if the employer is a DevOps shop in name only.
“Teams that are serious about DevOps will do their best to remove as much friction as possible from the development and deployment process,” Eric explains. “Ideally, a new hire should be able to commit and deploy source code on their very first day, whether that be a small bug fix, or simply adding their name to a humans.txt file.”
If the employer indicates it’s going to be a while, you might want to probe a bit deeper; it could be sign that they’re saying “DevOps!” but that their actual processes and culture aren’t there yet.
“Their answer to this question could be considered a holistic measure of the organization’s collective and cultural trust in their development team as well as the maturity of the team’s continuous integration and continuous delivery process,” Eric says. “In other words, you’re finding out how physically easy it is to move code to production.
Q. How committed is the organization to embracing and practicing a true DevOps culture?
You probably don’t want to ask this question verbatim. According to Beth Long, however, it’s critical to know which you're more likely to encounter: a healthy and balanced work environment, or a situation that may be unhealthy and even toxic in the long run.
A great way to get at this question is to ask more focused questions that gauge an organization's commitment to DevOps cultural values. “One fairly direct question that you can ask involves how an organization protects staff against burnout,” Long says. “Are team members expected to take time off every year? Are on-call rotations and incident response practices designed to spread the load?”
In addition, she states, questions about an organization’s incident response process, and especially how it learns from incidents, can be revealing. “Is an organization committed to progressive and equitable practices, such as the use of blameless postmortems to learn from incidents?” Long asks.
Finally, Long advises simply staying aware of the depth and extent of an organization’s DevOps practices: “If a DevOps platform team is all-in on embracing the culture, but other teams seem to be doing business as usual, it’s not a deal-killer—but it’s definitely a sign that you should dig deeper into its commitment to a healthy, sustainable DevOps culture.”
Walking a mile in a prospective manager’s shoes
Finally, if you’re curious about what may be going through the mind of your potential new manager, check out our post, How to Manage a DevOps Team: Q&A With the Manager of New Relic Mobile Team. Hopefully, it’ll lead you to a useful question or two.
New Relic is hiring!
Now that you've got the tools to crush your next interview, why not put them to work interviewing with one of the leaders of the DevOps revolution? We're hiring—with plenty of opportunities involving all kinds of job roles.
Les opinions exprimées sur ce blog sont celles de l'auteur et ne reflètent pas nécessairement celles de New Relic. Toutes les solutions proposées par l'auteur sont spécifiques à l'environnement et ne font pas partie des solutions commerciales ou du support proposés par New Relic. Veuillez nous rejoindre exclusivement sur l'Explorers Hub (discuss.newrelic.com) pour toute question et assistance concernant cet article de blog. Ce blog peut contenir des liens vers du contenu de sites tiers. En fournissant de tels liens, New Relic n'adopte, ne garantit, n'approuve ou n'approuve pas les informations, vues ou produits disponibles sur ces sites.