Job Spec Teardown - Breaking Down the Jargon in a Technical Job Post - DevOps Edition

04 Oct 2023

04 Oct 2023 by Luke Puplett - Founder

Understanding job specifications is crucial for tech recruiters. Job specs outline qualifications, responsibilities, and skills needed for roles. However, they often contain confusing industry jargon and technical terminology.

In this post, I'll do a deep dive into a real job spec for a DevOps Engineer role. My goal is to decode each section, explain requirements in plain terms, and provide context on why certain qualifications matter.

In the late 1990s I manned the telephones for Microsoft before working in big enterprise IT and then becoming a developer building trading and financial apps.

Whether you're a recruiter looking to improve your tech job spec knowledge or interested in infrastructure engineering roles, I hope this analysis provides insights. By breaking the job listing down step-by-step, I aim to demystify the technical details so you can better match candidates.

Let's start dissecting this job spec section-by-section! As we review the outlined responsibilities, skills, and characteristics, I'll offer straightforward explanations and highlight strong applicant traits. Join me in unraveling the intricacies of a DevOps engineering job specification.

Without further ado, here's the advert. It's real and as of early October 2023, you can apply for it!

Role Summary

There is no role summary.

First off, unlike the previous ad we looked at, there are no strongly titled parts to the ad. The whole thing is hastily thrown together with lots of keyword stuffing and repetition. It's a terrible advert in my opinion in many ways though I expect it probably works very well to attract a certain kind of person to a certain kind of company.

What on Earth is DevOps?

The term combines Developers and Operators, meaning software developers and the IT people for deploying and running the infrastructure of the app.

In traditional companies these were separate teams and it a pain because developers knew code but often didn't know or care about the infrastructure on which is ran. Meanwhile, the "server team" as people really call it, knew how to setup and run the infrastructure but what was running on it wasn't really their responsibility.

Worse, the web server software that (used to) run most websites sat in the middle and neither group of people knew it well or wanted to be responsible for it, e.g. Internet Information Server (IIS) in Microsoft land and Apache Tomcat in Linux world. I have experienced this unwanted baby situation many times.

Non-traditional companies like Facebook are often started and run by people who never worked anywhere before and so they do things that just seem to make the most sense, instead of following a org chart. It makes sense that the software developers build and deploy and run their apps, and monitor them and get paged at night when it breaks.

Often, the very bare metal of the server is setup by an infrastructure team but since the cloud came along, that's done by people at AWS. Since developers specialise in writing code to make things happen automatically, they got together to use code and build new tools to make creating, deploying, running and monitoring apps much easier.

DevOps is the result of that. To my mind, DevOps is when there is just a single team and a DevOps person is someone who likes the building, running, monitoring stuff more than they like to spend all day coding to make apps. Site Reliability Engineering or SRE is very similar except there's a larger, separate team who work closely with development teams.

They're sort of different skills but also sort of, not. Many developers know many of the DevOps tools and DevOps people usually know one or two coding languages. They use languages that work well for scripting and automation, that aren't used for massive apps. E.g. You'd use Rust to make a high-frequency trading app, but not to run a deployment of that app. You'd use Bash script to make changes to the infrastructure but you'd absolutely not use it to build an app.

That's it. The rest are new tools to help with all this.

You MUST have the following

It's common for recruiters to shout at their prospective candidates. I assume they get so many people applying that should not be applying that they have to resort to SHOUTING CAPS to get their message across.

• Ansible

  Apps run on computers and an expensive, fast one that slides into a rack, and is not intended to have someone sit at it and use it, is called a server. The server runs an operating system and will need to have the application it is serving installed onto it, essentially files dropped onto the server and settings tweaked.

  If you've just one server, installing it and configuring it is easy and can be done manually, and installing your web application onto it is also easy. But a large company will have tens of thousands of servers and you can't do it manually, and you also can't get an idea if one or all of them are all configured in the same way that they should be, e.g. anti-virus setup.

  So, deployment is putting the correct set files onto a server in the correct places, and configuration is the state of all the settings for the software on the server. Managing these two things for 10,000 servers and keeping it consistent and reportable takes tooling. The first two I remember were Puppet and Chef, they really changed the industry, and Ansible in another tool of this type. They use scripted instructions to ensure correct deployment and configuration.

• OpenShift

  From the same people as Ansible, this manages containers. But what's a container??

  A container is lets you instantly create a server within your server, i.e. your Linux or Mac or Windows machine is able to split itself, like a split personality. Anything that happens within the split-off part is not visible to the outside and can be discarded and recreated in a second. This works on your desktop computer, too, so you might setup a container which has your favourite apps installed and setup in the way you like, and it can be thrown away and made fresh each time.

  This is super powerful for configuring and installing apps on servers because the "container" can have all the configuration and files and be started and shutdown instantly. It's so game changing that it is the standard way to run and deploy apps. The problem then moves to configuring the various containers, listing them as available for people to use, and getting the container onto the right server hardware.

  Software called Kubernetes built by Google to operate all their stuff changed the industry and OpenShift is a customization of Kubernetes which many people prefer. It helps run all your containers, which are servers within servers.

• Artifactory

  Containers, software, and the further bits and bobs that apps themselves use, are all computer files. The technical term (which I've never liked) is artifacts (or assets).

  Imagine a phone app. Apple needs you to send them the files of your phone app and they put them in a place where the App Store can get to them. Each new version has another bunch of files. These files are the artifacts and, in a sense, the App Store is shopfront for all of them.

  Big companies that make lots of software like Google or more likely a big bank a JP Morgan, use something like Artifactory as a giant catalogue of artifacts. The files need to get put into the catalogue and read from it during deployment, so various tools can talk to this software.

  One important thing is security. Software is made up of code in files which is used by other code in files and so on. This is like a supply chain and like in the food you eat, its important to make sure the sources are all good and trusted. Tools like Artifactory help with this.

• Bamboo

  Okay so software is written in code and then that is often "compiled" into a reduced, faster machine-code and spat out into files. Then it is tested to ensure it works and is fast. Then those files are often stuck in a container and the container is sent out to a server. It's a production line.

  This production line is known as a CI/CD Pipeline. The first bit stands for Continuous Integration/Continuous Deployment. It means that the team writing the code is getting their latest code through the production line and onto real servers and used by its users, all week long, all year long, with no long pauses.

  It used to be that new versions of software came along once a year, and you planned for the new version and installed it and marveled at its new features. Now, all the code changes automatically work their way onto servers all week long. When there's a new feature, it's often hiding in the software, the code has already been there for weeks, and then one day someone reveals it by adding a new button.

  Bamboo helps run this production line. This is what's known as "building" an app or "the build phase".

• BitBucket

  An app is code and code is thousands of text files of gobbledegook looking syntax. A team will all work on the same files at the same time. But they don't see each other's words coming on the screen at the same time, no, they work from a copy. Then they synch the copy up and at that point they see all their colleagues code changes. Clever software keeps track of all the changes to all the text files and manages the synching.

  There used to be several tools to do this but one has emerged to rule them all: Git. Funny name for us Brits but this tool was written to help thousands of open source developers work around the world on making Linux, so it's very good. BitBucket is a Git-compatible app which hosts code for teams of developers.

  Other tools like Bamboo can talk to BitBucket in order to get access to the code to build it and deploy it.

• Linux

  Linux is an operating system which is rather like your Mac, if you use one, but usually has no graphical interface. It's written by the open source community and has become enormously successful. You can install it onto a normal PC or a PC server. It talks to the hardware and presents the raw hardware in a uniform way for other apps to run on it.

• Scripting in Python, Bash, Perl, Ruby or Shell

  Scripting is a loose coding that used to get stuff done rather than make a visual app. It's still software but it doesn't have a GUI and is usually only one or two pages of code.

  Python is interesting because you can make all kinds of things with it, from installation scripts to websites to AI.

  Bash is a fairly modern language built-in to Linux and is like advanced DOS. Linux and macOS can just run Bash scripts as they natively understand it.

  Perl is a really old language for scripting and website used to be made from it in the 90s.

  Ruby is a very well liked scripting language which is also popular for making websites.

  Shell is just an older Bash, really.

The following is DESIRABLE, not essential

Remember folks, these skills are DESIRABLE! Do not FREAK OUT if you DO NOT KNOW this stuff.

• AWS

  This is Amazon's cloud computing platform. The cloud is really just a website where you can create a server (or service) and within a few minutes it has created it and you can start to communicate with it from your code.

  You don't need to buy and install a database server, for example, you just have AWS make one, and you'll be given its web address and login details, and then you code your app to use it. You only need to read how the AWS one works so you know what code to write.

• Docker

  This is the tool that you install to make containers, i.e. to make temporary split brains in your computer.

• Kafka

  This one is strange for this job ad. It's not a DevOps tool so I'm not going to explain it. It's a kind of database. Perhaps they use it for something in their DevOps work.

• Splunk

  This stores logs and let's you search them really quickly (if you set it up right).

• Terraform

  Developers had a great idea to use code to describe how they want their servers to be configured. That way, they could manage it all in Git (see above) along with the actual code of the apps that run on the servers.

  Terraform reads that code and "makes it happen", i.e. translates it into the changes that need to be made to the servers.

• CyberArk

  I've no idea. Seriously, I've had to Google it. It's funny, for us highly technical people that actually do the work, many tooling apps websites are unfathomable marketing speak for managers or something. It looks like cyber security software, to do with identity. No clue.

  "A team of researchers dedicated to examining emerging attack techniques so that organizations everywhere can strengthen their security posture."

  I have a friend in enterprise sales and he actually speaks like this. It's like listening to a politician use lots of words to say nothing at all.

Until next time

I hope this breakdown has provided an indispensable cheatsheet for technical recruiters and staffing professionals seeking to better understand DevOps. With the rise of agile development and cloud infrastructure, DevOps has become a critical pillar of the modern software lifecycle. Having context on the key tools and concepts discussed in job specs allows recruiters to find and evaluate qualified candidates more effectively.

This overview of popular DevOps technologies should serve as a solid foundation. Of course, there is always more to learn about implementing CI/CD pipelines, infrastructure as code, containerization, monitoring, and other aspects of the DevOps toolkit. Hands-on experience will prove invaluable. For now though, recruiters and headhunters can use this guide to boost their confidence when assessing and interviewing DevOps engineers. Understanding the core components of a candidate's background helps ensure the best mutual fit.

So there you have it - a quick but comprehensive primer on hot DevOps keywords, geared specifically for the recruiting profession. Until next time, happy hunting for top DevOps talent!

---

Learn more