Advice for DevOps candidates

As a technical recruiter focussed on systems-type roles, I am frequently questioned by candidates on how to further their skills and increase their relevance in the marketplace.

Over the last year, a handful of themes have emerged from these discussions. I’ve attempted to summarize some of them here.

In a future post, I’ll talk about the DevOps “culture” and how it relates to modern organizational practices like “agile”, but for now I’d like to stick to the technology side of things.

In particular, I’ve chosen three things to discuss:

- Provisioning resources and configuration management
- Build/deployment engineering
- Application troubleshooting

These aren’t intended to be a exhaustive discussion of each topic, but rather as a point of departure for your own research. So without further ado…

PROVISIONING RESOURCES AND CONFIGURATION MANAGEMENT

Naturally, you’ll be provisioning resources (and configuring them) for a variety of purposes. Whether you’re working in a self-managed environment like vSphere or in a leased environment like AWS, it’s useful to familiarize yourself with how various modern configuration management tools handle this task.

For example, Puppet Enterprise has an interface to AWS, vSphere and GCE that allows one to programmatically interact and manipulate various pieces of virtual infrastructure.

AWS CloudFormation tackles this problem by allowing you to model your infrastructure with JSON configuration files.

While conducting this survey, you’ll encounter a variety of tools, each with their own unique properties. The point is to draw a picture of the current landscape, and form hypotheses about the best time and circumstances for each tool you encounter.

Subsequently testing these hypotheses in a live environment is highly recommended.

BUILD/DEPLOYMENT ENGINEERING

In DevOps roles, you’ll almost certainly be working on infrastructure for automated testing and deployment of web applications.

Whether it’s troubleshooting an existing setup, or doing a fresh build for a new application, your reputation with any development team lives and dies on the functioning of your build/test/deployment pipeline(s).

Again, there are many options here, and some extremely important secondary concerns to boot. For example, if you’re commercial and closed-source, how will you to protect your source code when it leaves the premises?

Another example: your CI may need to scale. If the company adds 15 developers in a year, the number of builds will skyrocket and increasing build times will cause a mutiny.

And finally, you’ll want to expose as much high-quality information about the pipeline as possible. Think release note generation, build status indicators, dashboards, chatroom notifications. And documentation. Always documentation!

In summary, you’ll be on the hook 24x7 for CI troubleshooting if you do a bad job, so spend some good time researching the options.

APPLICATION TROUBLESHOOTING

Each language and application framework have their own quirks, and being familiar with them from both the sysadmin and developer’s perspective allows you to be broadly useful in resolving issues and empowering developers.

A few examples that spring to mind:

- Assisting junior members of the dev team in setting up their development environments.
- Identifying and flagging application code that causes performance issues.
- Rewriting inefficient SQL queries.
- Planning and executing application upgrades.

So, even if it’s been a while since you written anything other than a shell script, jump back into application development because the problems you encounter and overcome each become a piece of advice for dev team.

And giving good advice is really what DevOps is all about.

‍