6 Devops interview questions
Tags: devops, techops, sre, expert
Published: 2018-02-26 21:42:01

---
title: 6 Devops interview questions
published: true
description: Here are interview questions for hiring teams, recruiters, and candidates alike.
tags: devops, techops, sre, expert, 
---


![Code Gif](https://thepracticaldev.s3.amazonaws.com/i/srn1rae6d9e67y2b3tvi.gif "Code Gif")




<a href="https://www.iheavy.com/2018/02/19/devops-skills-shortage-cloud-aws-gcp-automation/">Devops is in serious demand</a> these days.  At every meetup or tech event I attend, I hear a recruiter or startup founder talking about it.  It seems everyone wants to see benefits of talented operations brought to their business. 


<b>Find <a href="http://www.twitter.com/@hullsean">Sean Hull on twitter @hullsean</a>.</b>
 
That said the skill set is very broad, which explains why there aren't more devs picking up the batton.


I thought it would be helpful to put together a list of interview questions.  There are certainly others, but here's what I came up with.


<h2>1. Explain the gitflow release process</h2>

As a devops engineer you should have a good foundation about software delivery.  With that you should understand git very well, especially the standard workflow.

Although there are other methods to manage code, one solid & <a href="https://medium.com/@muneebsajjad/git-flow-explained-quick-and-simple-7a753313572f">proven method is gitflow</a>.  In a nutshell you have two main branches, development & master.  Developers checkout a new branch to add a feature, and push it back to development branch.  Your stage server can be built automatically off of this branch.  

Periodically you will want to release a new version of the software.  For this you merge development to master.  UAT is then built automatically off of the master branch.  When acceptance testing is done, you deploy off of master to production.  Hence the saying <a href="http://www.paulhammond.org/2010/06/trunk/">always ship trunk</a>.

Bonus points if you know that hotfixes are done directly off the master branch & pushed straight out that way.

<b>Related: <a href="https://www.iheavy.com/2011/08/05/ec2-interview-aws-interview-cloud-interview-8-questions/">8 questions to ask an AWS expert</a></b>


<h2>2. How do you provision resources?</h2>

There are a lot of tools in the devops toolbox these days.  One that is great at <a href="https://www.iheavy.com/2018/02/12/easy-cloudformation-template-comparison-simple-terraform-beginner/">provisioning resources is Terraform</a>.  With it you can specify in declarative code everything your application will need to run in the cloud.  From IAM users, roles & groups, dynamodb tables, rds instances, VPCs & subnets, security groups, ec2 instances, ebs volumes, S3 buckets and more.

You may also choose to use CloudFormation of course, but in my experience terraform is more polished.  What's more it supports multi-cloud.  Want to deploy in GCP or Azure, just port your templates & you're up and running in no time.

It takes some time to get used to the new workflow of building things in terraform rather than at the AWS cli or dashboard, but once you do you'll see benefits right away.  You gain all the advantages of versioning code we see with other software development.  Want to rollback, no problem.  Want to do unit tests against your infrastructure?  You can do that too!


<b>Related: <a href="http://www.iheavy.com/2012/06/21/4-letter-word-dividing-dev-and-ops/">Does a 4-letter-word divide dev & ops?</a></b>


<h2>3. How do you configure servers?</h2>

The four big choices for configuration management these days are Ansible, Salt, Chef & Puppet.  For my money Ansible has some nice advantages.  

First it doesn't require an agent.  As long as you have SSH access to your box, you can manage it with Ansible.  Plus your existing shell scripts are pretty easy to port to playbooks.  Ansible also does not require a server to house your playbooks.  Simply keep them in your git repository, and checkout to your desktop.  Then run ansible-playbook on the yaml file.  Voila, server configuration!


<b>Related: <a href="http://www.iheavy.com/2011/11/25/how-to-hire-a-developer-that-doesnt-suck/">How to hire a developer that doesn't suck</a></b>


<h2>4. What does testing enable?</h2>

Unit testing & integration testing are super import parts of continuous integration.  As you automate your tests, you formalize how your site & code should behave.  That way when you automate the deployment, you can also automate the test process.  Let the software do the drudgework of making sure a new feature hasn't broken anything on the site.

As you automate more tests, you accelerate the software development process, because you're doing less and less manually.  That means being more agile, and makes the business more nimble.

<b>Related: <a href="http://www.iheavy.com/2016/04/26/is-aws-too-complex-for-small-dev-teams-startups/">Is AWS too complex for small dev teams?</a></b>


<h2>5. Explain a use case for Docker</h2>

Docker a low overhead way to run virtual machines on your local box or in the cloud.  Although they're not strictly distinct machines, nor do they need to boot an OS, they give you many of those benefits.

Docker can encapsulate legacy applications, allowing you to deploy them to servers that might not otherwise be easy to setup with older packages & software versions.

Docker can be used to build test boxes, during your deploy process to facilitate continuous integration testing.

Docker can be used to provision boxes in the cloud, and with swarm you can orchestrate clusters too.  Pretty cool!

<b>Related: <a href="http://www.iheavy.com/2018/02/05/will-microservices-just-die-already/">Will Microservices just die already?</a></b>


<h2>6. How is communicating relevant to Devops</h2>

Since devops brings a new process of continuous delivery to the organization, it involves some risk.  Actually doing things the old way involves more risk in the long term, because things can and will break.  With automation, you can recovery quicker from failure.  

But this new world, requires a leap of faith.  It's not right for every organization or in every case, and you'll likely strike a balance from what the devops holy book says, and what your org can tolerate.  However inevitably communication becomes very important as you advocate for new ways of doing things.

<b>Related: <a href="https://www.iheavy.com/2017/11/06/migrate-skills-cloud-unix-devops-database/">How do I migrate my skills to the cloud?</a></b>