DevOps Resume Differentiators and Pitfalls (or, why I don’t care about all the tools you have used…

DevOps Resume Differentiators and Pitfalls (or, why I don’t care about all the tools you have used, even if ChatGPT does)

I’ve seen way more resumes than ChatGPT

From 2011 to 2021, I interviewed hundreds of Infrastructure Engineers, Operations Engineers, SREs, Sysadmins, Production Engineers — or whatever job title I worked with recruiters on to get the best candidates. It was hard. Resumes all blended together. During that decade, I reviewed thousands of resumes. I’ve seen the narrow release engineer profiles that only knows CI/CD. I’ve seen the On Prem network engineer that knows storage and VMWare. I’ve seen the Java developer that doesn’t have enough Infrastructure experience and is terrible at the command-line.

DO — show how you’ve broken new ground for your team and what you’ve learned.

I hope you have learned something new. How could you not? I hope you achieved a first for you team. You better have improved something or automated a manual task that saved time. Did you eliminate toil for the team? Remember the L in CALMS. Culture, Automation, Learning, Metrics, and Sharing.

DON’T — repeat the same tools over and over and over again in each role.

Tools like Jenkins, Gitlab, Terraform, Ansible, Helm are means to an end. Focus more on the problem and solution space and HOW tooling helped. Focus on the value to the team.

DO — tell me how you’ve made difference to developers and product teams.

Although there are different ways of working (you’ve read Team Topologies and Accelerate, right?) the whole point of automation and Cloud infrastructure is to deliver a Layer 7 service

DON’T — give me an Alphabet Soup of AWS Services.

Are you listing off all the traditional mid-2010s services before Docker and Kubenetes ruined everything? Do not list them in your resume all together.

DO — provide examples of your critical Ops experience and restoration of services.

A suprising number of resumes do not even mention tradional Ops experience (outages, troubleshooting, incidents). Even if you are were not supporting external customer-facing services, you have to have had experience maintaing SLAs. Even if you’ve never done the math with SLOs and SLIs. The “No Ops” movement did not win. Be proud of your Ops experience and put it on your resume.

DON’T — list meaningless or common buzzwords that don’t provide insights about your work.

Phrases like software development lifecycle (especially if you say all phases of it). Abbreviations like ITIL or SAFe. Saying something you did built “scalable” or “reliable.” None of this helps me. Listing “Continuous Integration.” Stop it. Provide more detail on how work imploved flow, increased the frequency of deployments.

DO — tell me you understand above the platform waterline.

Like or not, infrastructure is plumbing. In many organizations the business doesn’t care — until it does. If you worked on a game, list the title. If you know the name of the solution put it out there. If you built RDS databases or migrated ElasticSearch clusters, at least mention the type of data you dealt with.

DON’T — list tools or cloud provider functionality as an accomplishment.

Launching instances in AWS is not something you can take credit for. Managing servers with Ansible.

DO — use numbers to show scale.

The numbers of AWS accounts. The number of instances. How many regions? How many services? How many teams? How many deploys a day/week/month? How many builds?

DON’T — list task and process minutae.

Many resumes have way to much detail describing your day to day, blow by blow work. Save this for the interview.

DO — take advantage of formatting and whitespace.

While I don’t need color or fancy resume templates with your picture or Kubernetes (or AWS) logos, take some time to think about the design and how it can help you stand out in the sea of boring, overly dense resumes.