Building a strong DevOps culture is easier said than done. It starts by knowing what you are aiming for, then ensuring your entire team is working toward culture-specific goals and measurable outcomes.

“Culture can be an amorphous and ambiguous thing. Leaders can provide tangible support for DevOps initiatives by identifying specific metrics and trends that are expected to improve as a result of introducing new DevOps capabilities.”

Matt Poepsel, Senior Vice President, The Predictive Index

To consistently improve your DevOps culture, you need to assess where your culture stands today — and revisit that assessment at regular intervals. The five diagnostic questions below are worth asking yourself and your team often.

1. Are People Frequently Trying New Things?

When DevOps is working well, teams have the safety and the tooling they need to experiment, says Daniel Viveiros, CTO at CI&T. They are comfortable trying new ideas without fearing catastrophic failure.

“In our experience, we found that the new culture helps to foster an experimentation mindset. Moving things to production more often allows your company to test new ideas faster and more effectively.”

Daniel Viveiros, CTO, CI&T

High-frequency deployment and a culture of experimentation reinforce each other. As Viveiros explains: “Any company that deploys code several times a day understands the importance of breaking down big user stories into small, manageable pieces. This process is very similar to the one used to transform bold ideas into a set of hypotheses that should be quickly validated. Each hypothesis can be developed and deployed for a subset of your customer base. The collected metrics will help define the best next step.”

If experimentation is scarce, the root cause may be an emotional intelligence (EQ) deficit rather than a technical one. Steve Burton, CI/CD and DevOps evangelist at Harness, puts it directly:

“Focus as much on EQ as IQ. Make sure engineers and operators can give and receive feedback while building a DevOps culture from the ground up. The notion of ‘fail fast and learn fast’ can only evolve if feedback is received regularly and acted on by teams. Blame-game cultures are toxic and will divide teams instead of uniting them.”

Steve Burton, CI/CD and DevOps Evangelist, Harness

A practical signal to watch: do post-incident reviews focus on systemic causes, or do they devolve into finger-pointing? Teams that conduct blameless retrospectives tend to experiment more freely because failure carries a lower personal cost.

2. How Does the Rest of the Business Perceive DevOps?

Can your DevOps team clearly articulate how their work benefits the business? If not, you may be inadvertently creating an “us-versus-them” dynamic. Ben Grinnell, Managing Director and Global Head of Technology and Digital at North Highland, warns against the “trailblazer” trap:

“So often, companies run these ‘trailblazer’ projects without thinking about the fact that if you want to scale, these projects must leave a trail that others can and want to follow. Trailblazing teams are usually staffed by confident people new to the organization who have done it before elsewhere. They are encouraged to disrupt and break the rules that others are supposed to follow. It’s easy to see how you end up with an ‘us-and-them’ culture, which inhibits the transfer of skills and knowledge.”

Ben Grinnell, Managing Director, North Highland

The fix is to anchor DevOps work explicitly to business outcomes. Burton frames it this way: “Your company hired engineers to build cool things. Make sure those cool things translate to measurable business outcomes. For example, do you want your DevOps engineers to be in the business of building tools and automation, or building innovation that your customers can experience?”

Eran Kinsbruner, Lead Technical Evangelist at Perfecto, adds that business alignment also demands the right internal questions:

• Are we focusing on the most important projects to the business?
• Are we using the right technologies to deliver software that works and matches current advancements?
• Do we have sufficient visibility into everything we develop within the DevOps pipeline?
• How can we optimize the entire process, remove waste, reduce costs, and deliver more reliably?
• How can we automate more manual processes and move toward a full continuous deployment model?

Aligning DevOps teams with business goals also unlocks two cultural benefits that reinforce each other: autonomy and accountability. As Burton notes: “You can’t expect a DevOps team to have the right culture if they are boxed in with constraints and red tape from surrounding teams. Autonomy with accountability means engineers are trusted to make decisions fast and understand the impact of their actions.”

3. Who Is Blocking DevOps?

If you want to build a strong DevOps culture, you must actively look for two types of people: critics and champions. Both have an outsized influence on how quickly DevOps culture scales — or stalls.

Resistance can come from engineers who have been burned by failed transformation efforts in the past, from middle managers who see DevOps as a threat to their authority, or even from senior leadership. Mike Bursell, Chief Security Architect at Red Hat, describes one of the most common structural blockers:

“If your organization works on a model where managers are incentivized to build large teams, set specific short-term targets, micro-manage their resources, and just keep accruing larger and larger budgets, then the adoption of DevOps will be an overwhelmingly negative experience for them. They will fight against it, refuse to assign their team members to DevOps projects, and, when pushed into doing so, will attempt to stop them from participating fully in the DevOps process and generally find ways to be obstructive.”

Mike Bursell, Chief Security Architect, Red Hat

The takeaway: incentive structures and cultural blockers are inseparable. If your management incentives reward empire-building over collaboration, no amount of DevOps tooling will overcome the friction. Identifying who is blocking progress — and understanding why — is an essential diagnostic step before you can address it.

4. Are Teams Feeling Supported?

Psychological safety is a foundational ingredient of effective DevOps teams. When engineers feel supported — by their managers, their peers, and their tooling — they take appropriate risks, share knowledge freely, and escalate problems early rather than hiding them.

Signals that support is lacking include high on-call burnout, reluctance to raise issues in retrospectives, and teams siloing knowledge to protect themselves. Regular one-on-ones, clear escalation paths, and explicit recognition of collaborative behavior all contribute to a culture where people feel safe enough to do their best work.

5. Is Collaboration Being Rewarded?

In many organizations, performance systems reward individual heroics — the engineer who single-handedly saves a critical production incident, for example. DevOps culture, by contrast, rewards shared ownership: teams that prevent incidents through good practices, document their systems so others can contribute, and actively reduce bus-factor risk.

Ask yourself: does your recognition and promotion process favor individual stars, or does it celebrate teams that consistently deliver reliably together? If the answer is the former, your incentive structure is working against the culture you are trying to build.

Putting It Together: Culture as an Ongoing Practice

None of these five questions has a permanent answer. DevOps culture is not a destination — it is an ongoing practice that requires regular reflection and deliberate reinforcement. Teams change, organizational priorities shift, and new people bring new assumptions.

Treat these questions as a recurring retrospective agenda, not a one-time checklist. Revisit them quarterly, after major incidents, or whenever you onboard a significant number of new team members. The organizations that improve their DevOps culture fastest are the ones that make honest self-assessment a habit — not an event.

Original article concept sourced from enterprisersproject.com.

This guide covers the demand for DevOps skills, sample interview questions grouped by topic, and best practices for making strong hiring decisions.

Demand for DevOps Skills

As organizations continue to adopt cloud computing, the demand for professionals who can operate effectively at the intersection of development, operations, and infrastructure has grown steadily. IT engineers, software engineers, and cloud architects are among the roles seeing the most direct benefit from DevOps expertise.

Among the most sought-after technical skills for DevOps practitioners are:

• Configuration management: Experience with tools such as Puppet, Chef, and Ansible to automate infrastructure provisioning and maintain consistency across environments.
• Containerization and virtualization: Hands-on experience with platforms like Docker, Kubernetes, OpenStack, and cloud providers such as AWS, Azure, or GCP.
• Scripting and programming: Proficiency in languages commonly used in automation and tooling, including Python, Ruby, Go, Bash, and Java.
• CI/CD pipeline management: Experience designing, building, and maintaining continuous integration and continuous delivery workflows.
• Monitoring and observability: Familiarity with monitoring stacks and the ability to design alerting and incident response strategies.

Sample DevOps Interview Questions

The following questions are grouped by topic area. They are useful both for interviewers designing a structured assessment and for candidates preparing their responses.

Understanding of DevOps

What is your understanding of DevOps?

This foundational question assesses whether the candidate understands DevOps as more than a toolchain — it is a cultural and organizational approach that improves collaboration between software development and IT operations teams. A strong answer will go beyond listing tools and describe how DevOps shortens feedback loops, reduces deployment risk, and aligns engineering work with business outcomes.

Why does DevOps matter, and what problems does it solve?

This question probes the candidate’s ability to articulate the business value of DevOps. Look for answers that address both the technical benefits — such as faster, more reliable deployments and reduced mean time to recovery — and the cultural benefits, including breaking down silos between development and operations teams. Candidates who have lived through a DevOps transformation will often have concrete examples to draw on.

Agile Development

How are DevOps and Agile methodology related?

DevOps and Agile are complementary but distinct. Agile focuses on iterative software development in short cycles; DevOps extends this thinking into the deployment and operations phases. A well-prepared candidate will explain that DevOps is often seen as the natural operational companion to Agile development — both share a commitment to rapid feedback, collaboration, and continuous improvement. They should also be able to distinguish where each practice applies and how they interact in practice.

What is the role of a DevOps engineer within an Agile team?

This question uncovers whether the candidate understands their specific responsibilities in a cross-functional team. Key functions include maintaining CI/CD pipelines, enabling automated testing, managing infrastructure as code, and supporting rapid, reliable delivery of each sprint’s output. Strong candidates will also highlight the importance of acting as a bridge between developers and operations — attending standups, participating in sprint planning, and helping the team understand infrastructure constraints early.

Software Deployment

Describe your experience with software deployment pipelines.

This open-ended question lets the candidate demonstrate hands-on experience with deployment automation. Listen for familiarity with tools like Jenkins, GitLab CI, GitHub Actions, CircleCI, or ArgoCD, and whether the candidate can describe a real pipeline they have designed or maintained. The best answers will touch on how they handled environment parity, secrets management, and rollback strategies.

How have you handled a failed deployment in production?

Deployment failures are inevitable. This behavioral question assesses how the candidate responds under pressure. Look for a structured approach: detecting the failure quickly, deciding whether to roll back or hotfix, communicating clearly with stakeholders, restoring service, and conducting a blameless post-mortem to prevent recurrence. Candidates who have never experienced a production failure may not have been working at sufficient scale or ownership level.

How do you detect failures in production?

This question directly tests the candidate’s approach to monitoring and observability. A strong answer will describe a layered strategy: infrastructure metrics (CPU, memory, disk), application-level metrics (error rates, latency, throughput), log aggregation, distributed tracing, and alerting thresholds. The candidate should be able to name tools they have used — such as Prometheus, Grafana, Datadog, the ELK stack, or similar — and explain how they configured meaningful alerts rather than alert noise.

How can configuration management tools support a DevOps practice?

Configuration management tools like Ansible, Chef, Puppet, and SaltStack allow teams to define infrastructure state as code, apply it consistently across environments, and audit drift. A solid candidate will be able to compare at least two tools, describe when they would choose one over another (for example, agentless versus agent-based models), and explain how these tools integrate into a broader CI/CD pipeline or infrastructure-as-code workflow alongside tools like Terraform.

Why Asking the Right Questions Matters

Structured, topic-focused interview questions serve a practical purpose beyond filtering candidates. They allow you to:

• Map candidate strengths against specific gaps in your existing team — one candidate may be stronger on the infrastructure and operations side, while another brings deep CI/CD or development expertise.
• Objectively compare candidates using consistent criteria rather than gut feel.
• Assess depth of experience versus surface-level familiarity with buzzwords.
• Determine whether a candidate understands the full software delivery lifecycle, not just their slice of it.
• Gauge a candidate’s ability to collaborate across team boundaries — a critical soft skill in DevOps environments.

DevOps roles vary significantly between organizations. A startup may need a generalist who can own the entire pipeline, while an enterprise may need a specialist who fits into a larger platform engineering team. Tailor your questions accordingly.

Best Practices for Hiring DevOps Engineers

Effective DevOps hiring goes beyond the interview itself. Consider the following principles when building your hiring process and onboarding approach.

Create an environment where good engineers can do their best work

Hiring exceptional engineers is only half the equation. If your organization’s culture, processes, or tooling prevent those engineers from exercising their expertise, the talent advantage disappears quickly. Before worrying about hiring the best people on the market, evaluate whether your current environment supports autonomy, fast feedback, and psychological safety. Engineers who are trusted to make decisions and learn from failures will outperform those who are micromanaged regardless of their raw skill level.

Prioritize problem-solving ability and initiative over trivia

It is tempting to use technical screening questions as a proxy for competence — asking candidates to recite specific port numbers, obscure configuration syntax, or niche protocol details. Resist this temptation. Specific technical details can be looked up in seconds; what cannot be easily taught is the drive to identify a problem, design a solution, and see it through to completion. Focus your interview process on how candidates approach ambiguous problems, how they communicate during incidents, and how they learn from mistakes.

Assess cultural and collaborative fit alongside technical skill

DevOps is fundamentally about collaboration. A technically brilliant engineer who refuses to share knowledge, dismisses feedback, or works exclusively in silos can actively damage a DevOps culture. During interviews, pay attention to how candidates describe past team dynamics, how they talk about colleagues in other disciplines, and whether they show genuine curiosity about the problems your team is trying to solve.

Consider practical assessments

Where appropriate, supplement verbal interview questions with a practical exercise — such as reviewing a Dockerfile or a CI pipeline configuration and asking the candidate to identify issues and suggest improvements. Keep take-home assessments short and respectful of the candidate’s time, and always provide feedback regardless of outcome.

Additional Resources

For further reading on DevOps interviewing and hiring, the following articles on this site may be useful:

• 10 questions every DevOps candidate should answer
• Why you’ll NEVER nail that DevOps interview

The following ten interview questions — originally compiled by Skyhigh Networks and reported by CSO Online — are designed to gauge a security candidate’s practical cloud knowledge. Each question is paired with context on what a strong answer looks like.

1. How Can IT Function as a Business Enabler?

The era of IT as a back-office gatekeeper is over. Security teams must transition from reflexively saying “no” to actively enabling the tools employees need to do their jobs. Cloud computing offers a rare opportunity to design security controls from scratch rather than retrofit them onto legacy infrastructure. Look for candidates who demonstrate comfort collaborating with business stakeholders and who understand that a security policy nobody follows is worse than a pragmatic one people embrace.

2. What Role Does the Corporate Network Perimeter Play in Modern Security?

The traditional castle-and-moat model has collapsed. When employees access SaaS applications, work from home, and store data in third-party clouds, the network boundary is no longer a meaningful security control. Strong candidates will articulate that data is now the perimeter and describe how security must travel with data across applications, devices, and environments. Listen for familiarity with zero-trust principles and context-aware policy enforcement.

3. What Information Security Challenges Are Specific to Cloud Environments?

When data leaves a corporate network and moves to a cloud provider, security teams can lose visibility and direct control almost immediately. Key risks include:

• Insider threat — malicious or negligent employees misusing cloud access
• Compromised accounts — credential theft and account takeover
• Compliance violations — regulated data stored or processed in non-compliant regions or services
• Data loss or exfiltration — sensitive IP shared through unsanctioned applications

A strong answer demonstrates awareness that cloud shifts, but does not eliminate, the security team’s responsibility for protecting sensitive information.

4. Would You Recommend an On-Premises or Cloud-Based Solution — and Why?

This question tests whether a candidate can move beyond reflexive skepticism of cloud providers. Even security-conscious organizations have been migrating away from private data centers, driven not only by cost and agility but also by the security capabilities of major cloud providers. Candidates should be able to weigh factors such as compliance requirements, data classification, vendor security posture, and total cost of ownership — not simply default to one model or the other.

5. What Cloud Services Would You Block, and How Would You Select Sanctioned Applications?

There are thousands of cloud services available, and many do not meet basic enterprise security standards. A well-prepared candidate will describe a risk-based evaluation framework. Criteria for sanctioning a cloud application typically include:

• Encryption at rest and in transit
• Multi-factor authentication support
• Data center locations and sovereignty
• Data ownership clauses in the service agreement
• Audit logging and reporting capabilities
• Third-party security certifications (e.g., SOC 2, ISO 27001)

Consumer-grade cloud services are generally restricted for corporate data, with possible exceptions for specific business functions like marketing.

6. Employees Want to Access Corporate Data on Personal Devices. How Do You Respond?

A blanket refusal to support BYOD or mobile access does not make the risk disappear — it simply drives employees toward shadow IT, creating risks that are harder to monitor. A mature answer will describe a risk-tiered approach: for example, allowing employees to view but not download or copy sensitive data on personal devices, enforcing mobile device management (MDM) policies on enrolled devices, or using application-level controls rather than device-level ones. The goal is managed risk, not zero access.

7. What Technologies Secure Services Deployed in Cloud Infrastructure?

Traditional on-premises security tools — proxies, data loss prevention (DLP) systems, SIEM — do not automatically extend their coverage to cloud applications. Look for candidates who can describe the role of:

• Cloud Access Security Brokers (CASB) — act as a central policy enforcement point between users and cloud services, extending DLP, threat detection, and access controls into the cloud
• Cloud-native security tools — such as AWS GuardDuty, Azure Defender, or GCP Security Command Center
• Identity and access management (IAM) — least-privilege access, role-based controls, and privileged access management
• Encryption and key management — customer-managed keys and secrets management

8. Can You Explain the Difference Between SaaS, PaaS, and IaaS — and the Security Implications of Each?

Understanding the shared-responsibility model is non-negotiable for cloud security roles:

• IaaS (e.g., AWS EC2, Azure VMs): The provider secures the physical infrastructure. The customer is responsible for the operating system, middleware, applications, and data.
• PaaS (e.g., AWS RDS, Azure App Service): The provider adds the runtime and platform layer. The customer is responsible for application code and data.
• SaaS (e.g., Microsoft 365, Salesforce): The provider manages the full application stack. The customer is responsible for identity, access management, and how data is used within the application.

Candidates who conflate “the cloud provider handles security” with “we have no security responsibilities” are a red flag regardless of service model.

9. Describe a Cloud Deployment You Led or Participated In

Hands-on cloud experience remains scarce relative to demand, so this question differentiates candidates quickly. A strong answer includes specifics: which cloud platform, what workloads were migrated or deployed, what security controls were implemented, and what business outcome resulted. For candidates without direct cloud deployment experience, look for evidence of structured self-learning — relevant certifications (such as those from the Cloud Security Alliance, AWS, or Microsoft) and lab-based projects can be reasonable proxies.

10. Cloud Governance Requires Cross-Departmental Collaboration. Who Belongs on a Cloud Governance Committee?

Mature cloud security programs establish a formal governance structure to evaluate and categorize cloud services — typically approving, conditionally permitting, or blocking applications based on documented risk criteria. This cannot be a security-only function. A complete governance committee should include representatives from:

• Information security
• Compliance and legal
• Internal audit
• Business unit stakeholders
• IT operations or architecture
• Procurement (for vendor contract review)

A candidate who describes governance as purely a security function has likely not operated in a large enterprise environment.

Final Thoughts

Cloud literacy is now a baseline expectation for security hires, not a specialty. These questions are useful not only as interview prompts but also as a self-assessment checklist for security professionals building their own skills. The most effective cloud security practitioners combine technical depth — understanding architecture, tooling, and threat models — with the business acumen to implement controls that people will actually follow.

This article is based on interview questions originally compiled by Skyhigh Networks and published by CSO Online.

Strong DevOps teams require individuals with very special skills. The DevOps professionals you recruit must be able to balance coding chops with continuous integration/continuous deployment (CI/CD) competence, for example. If they’re heading up DevOps, they should also have a track record of being an active liaison with the business.

Many companies trying out the model have had negative experiences. They have failed to realize hoped-for advantages such as more frequent code delivery and greater application stability. Without the right people in place—those who understand DevOps as a cultural shift—to both serve in leadership roles and work on applications and services being delivered, things can easily go wrong, says the digital/cloud strategist Jeanne Morain.

Smart businesses are determined to avoid that scenario. “Like executive roles, these positions are expensive to fix if you make a mistake,” says Greg Scharer, COO at Perrone Robotics, which develops software for self-driving vehicles and general-purpose robotics and is actively looking to fill a senior DevOps management role. “So we over-invest in talking to candidates.”

That’s good advice for anyone involved in the DevOps hiring process. If that describes you, here are 10 questions you should ask to make sure your investment pays off.

General questions

Who would you include in efforts to create processes and policies for delivering applications in a DevOps environment?

This question gets to the heart of whether your candidate understands DevOps as a cultural shift—one that requires development and operations experts working together from the start on implementation strategy, and that acknowledges the need to actively include business counterparts in the dialogue, Morain says.

“If they can’t answer, or if they don’t include the business, that’s bad,” she says. The same is true if they don’t talk about engaging not just with executives on the business side, but also with end users. “How do you develop processes for users if you don’t know how it will impact them?” she says.

What has been your approach to resolving conflicts among team members?

Good communications skills and being able to calmly and effectively intermediate disputes matters, Scharer says, given that “sometimes DevOps can be a tinderbox for conflict.” It’s not uncommon for sparks to ignite when, for instance, something goes awry upon an integration build of multiple developers’ code compilations. No one wants to think their documentation or check-in timing error was responsible for a problem.

“Developers can wind up in fights among themselves and it’s very important for the DevOps manager to bring people together, asking them for help in ways that make them believe they are respected and valued,” Scharer says. Ideally, your candidate can offer a thoughtful and logical answer of how to sort through intra-team conflicts and proactively keep similar issues from arising in the future. “If they can articulate how they overcame a challenging conflict like that, that is useful feedback for me,” he says.

What to ask about past experience

Why did your previous/current company embrace DevOps and how did you support that?

The interpretation and methodology of DevOps in each company is different. So, it’s important to know what candidates have been mandated to accomplish – whether it be database optimization, driving migrations to different tools/infrastructure, or fostering CI/CD pipelines – and what impact that work had on the engineering team’s overall strategy and objectives, says Danny An, technical recruiter for Influitive. The discussion should help you gain insight into things like how involved they were in testing, or what tools they have used.

“Since [DevOps] is so broad, learning more about where candidates are coming from and how that experience aligns with what you are doing or hoping to do can mitigate the risk of a false-positive hire,” he says.

How did the last system that you worked on as a DevOps engineer change from the time you started to the time you left, and who drove those changes?

Candidates’ answers should display an unquenchable desire to keep looking for improvements, and the willpower to make sure those improvements happen. “A great candidate will have transformed their systems for the better, by their own initiative,” says Brian Kelly, vice president of engineering at the DevSecOps company Conjur. Bonus points if they tell you they rallied others to their cause rather than just acted as a lone hero.

Candidates’ technical knowledge is important, of course, but that innate personal drive to improve the efficiency and velocity of systems is vital, says Kelly, who’s hired for DevOps roles at three different companies over the last five years.

Give me an example of a CI/CD failure you’ve experienced, and what you learned from it.

“Everyone who has learned the DevOps process will have hit a level of failure at some point,” says Morain, so you want to hear how those failures helped the candidate become a better candidate to work for your business.

One DevOps pro recalled to Morain how his team had not created a process to automate finding, fixing and immediately addressing issues that arose during a parallel implementation process as part of rolling out CI/CD. “It took days and they had to parachute someone in to rip everything out,” she says.

That hurts. But he walked away from the experience realizing the importance of testing a pilot production environment first, which is where a strong partnership with operations helps. People who can admit to such mistakes and explain how they are the wiser because of them are assets in waiting.

Questions that probe technical knowledge

Describe your cloud expertise.

As the world moves to the cloud, many companies want DevOps engineers who have experience with cloud-based technologies, says Joseph Kotlinski, partner and manager at talent acquisition firm WinterWyman’s Information Technology Search practice. Some of these include the highly popular Amazon Web Server (AWS) and RackSpace, OpenStack, Google Elastic Cloud and Microsoft Azure, he says.

“It is important to understand not only the cloud technologies a candidate has worked with but also the depth of the candidate’s experience,” Kotlinski says. “A few years ago, all DevOps engineers had to say was they had worked with AWS. These days, if someone claims to have experience with AWS, you should probe further, and ask have they worked with EC2, S3, EBS, Glacier, Snowball, RedShift, Route53, etcetera.”

Good candidates also will be happy to tell you how many cloud instances they’re currently working with; if they’ve ever designed, implemented and/or led a migration to the cloud or scaled an environment from small to large; and how much of their time is spent working in the cloud in mixed environments.

What issues or deficiencies are “must fix ASAP”?

In DevOps, there’s always a balance to maintain between striving for technical perfection and meeting business goals. But candidates should demonstrate an understanding that there are some places where compromise isn’t appropriate if they are to maintain high personal standards of work quality, says Kelly.

“Great DevOps people will have a few things that they consider too sacred to break. For example, unreliable CI/CD systems, failing tests, or very slow release pipelines should always be getting fixed, rather than left to fester and worsen,” he says.

What are critical DevOps tool-chain integration points in relation to increased software release velocity?

Chris Ciborowski, CEO and principal consultant at enterprise DevOps consulting firm Nebulaworks, says that an integrated toolchain is the key to flow in the DevOps process. Candidates should be able to talk about the tools (version control, configuration management, continuous integration and so on) they like to put in place, why, and in what context.

A strong candidate who understands the need to deploy applications automatically to multiple environments (public cloud and on-premise) could say, for example, that he believes a key tool-chain integration point is to have automated code deployment using Jenkins, Ciborowski says. To be infrastructure-agnostic and provide a consistent mechanism to deploy applications in a familiar and easily documented fashion to upstream team members, the candidate may also talk about taking advantage of Jenkins plug-ins.

You can’t help but appreciate that approach, “which removes the need for a developer or release manager to understand the operational details of the downstream deployment endpoint, and could provide multiple deployment options without slowing releases into various infrastructure types,” Ciborowski says.

How-to questions

How would you get a web app from a developer’s laptop into production from zero?

Adam Serediuk, director of operations at intelligent communications platform vendor xMatters, uses this as an open-ended question that leaves candidates plenty of room to show whether they’re more focused on a particular skill-set or in possession of a broad range of DevOps skills.

“I want to find out about their knowledge of the whole stack.” he says. “I want them to look at building the app, version control, deployment, making sure the dev environment is a mirror of production, monitoring, and metrics like response time.” It’s a red flag if they make assumptions, if they don’t know continuous delivery, or if they don’t produce repeatable artifacts, he says.

You must design a system to onboard Shadow IT cloud applications quickly to your hybrid cloud infrastructure to reduce security and compliance risks. How do you do it?

It’s good news if your DevOps candidate talks up the idea of quickly pulling in others to form an incubator team that includes business, audit, and security to determine what the compliance and security risks are for applications to be on-boarded, says Morain.

It’s equally good news if the candidate discusses how, based on compliance risk posture, the group would categorize the applications with the most significant profiles to prioritize resources and onboarding activities, she says, and also provide guidance or different solutions on how they would automate some of the legacy processes around change, incident, and problem management.

Another indication that interviewees are worth serious consideration is if they bring up implementing new solutions such as self-healing and automatic updates to IT service management systems, to avoid issues down the line with supporting them.