The DevOps job description that attracts people who can actually do the work

Somewhere in your applicant tracking system is a DevOps job description with fourteen required technologies, a degree requirement nobody remembers deciding on, "5+ years of Kubernetes" written when Kubernetes was seven years old, and the phrase "work hard, play hard". It was copied from the last JD, which was copied from a template, which was copied from a company with different problems.

Job descriptions are treated as paperwork. They are actually the highest-leverage filter in the funnel, because they run before you see anyone: the JD decides who applies at all. And the standard DevOps JD is precision-engineered to repel the strongest part of the candidate pool while attracting keyword-matchers.

What the standard JD gets wrong

The requirement soup. Fourteen technologies as "required" reads, to a strong engineer, as "this team does not know what the job is". Worse, LinkedIn's analysis of billions of platform interactions found that women applied to 20% fewer jobs than men, although it did not establish that unmet requirements caused the gap. Inflated must-have lists may compound an existing gender difference in application behaviour. Your list of fourteen is filtering for people who ignore requirements, which is a strange trait to select for.

Credential proxies doing capability's job. "BSc in Computer Science" and "5+ years in a similar role" are proxies for "can do the work". In infrastructure, the proxies run badly: some of the strongest operators are self-taught, came up through support or the NOC, and have production instincts no degree teaches. We wrote about that pool from the candidate's side in how to get a DevOps job without a degree; the short version for the hiring side is that the degree line is deleting your best asymmetric bets.

Responsibilities written as vague abstractions. "Drive DevOps culture", "own the CI/CD strategy", "collaborate with cross-functional stakeholders". Nobody can tell from these what they would do on a Tuesday. Strong candidates read vagueness as either a team that does not know what it needs, or a bait-and-switch.

Nothing about how you assess. The JD is silent on what happens after applying, which means the candidate assumes the default: CV keyword screen, maybe a puzzle test, four rounds of vibes. The candidates with the most options decline that ride most often.

Write the JD around provable capabilities

The single structural change: replace credentials and tool lists with capabilities a candidate could prove and you could verify. A capability line names the work, not the badge:

• Instead of "5+ years Kubernetes experience" write "you can take a misbehaving Kubernetes workload from symptom to root cause: reading events and logs, reasoning about probes, resources, networking, and RBAC as you narrow down".
• Instead of "AWS certification preferred" write "you have run production workloads on a major cloud and can explain the cost and failure-mode trade-offs of choices you made".
• Instead of "experience with IaC tools (Terraform, Pulumi, CloudFormation, Ansible, Chef, Puppet)" write "infrastructure you manage lives in version control and goes through review; you have opinions about state management you can defend".

Three things happen with capability lines. Self-taught engineers with real skill recognise themselves and apply. Keyword-matchers without the skill cannot tell if they qualify, and hesitate. And your own interview panel now has its rubric written for it, because every capability line is an assessable claim.

A structure that works

Keep it under 600 words. In order:

1. The problem paragraph. What is broken or growing that made you open this role? Real detail: the deploy that takes 40 minutes, the observability gap, the second product line arriving. Strong engineers apply to problems, not titles.
2. A concrete Tuesday. Five or six bullets of actual work from the last month: "moved our staging environment to the same Terraform modules as prod", "wrote the post-mortem for the March queue outage". Nothing vague survives this section, which is the point.
3. Capabilities: must-have. Four or five capability lines as above. If it is learnable in the first month by someone with the other four, it does not belong here.
4. Capabilities: nice-to-have, honestly labelled. "You will be fine without these" - and mean it.
5. How we assess. Name the stages and the total time. If you assess with a realistic scenario rather than puzzle trivia, say so prominently: it is a genuine differentiator to exactly the candidates you want, and it signals respect for their time.
6. Range, location policy, on-call reality. Stating the on-call rotation honestly costs you the candidates who would have quit over it in month three.

Before publishing, ask the hiring manager and an engineer doing adjacent work to classify every capability as essential on day one, learnable during onboarding, or merely useful. Keep only the first category under must-haves. This review is where a capability-based JD either survives contact with the real role or becomes another wish list.

Lines to delete today

• "Degree in Computer Science or related field" - unless a regulator requires it, it only shrinks the pool.
• Years-of-experience numbers on specific tools - they measure calendar, not competence, and they age embarrassingly.
• "Rockstar", "ninja", "work hard play hard", "wear many hats" - each one costs applications from the careful people who keep production alive.
• The fourteen-technology soup - name the three that matter; file the rest under "our stack" as information, not requirements.
• "Fast-paced environment" - every strong operator reads this as "we page a lot and call it culture".

The JD is a promise about the process

One last mechanism worth naming: a capability-based JD raises expectations you have to meet. If the ad says "we care what you can do, not where you went", and the first screening step is a keyword filter and a puzzle quiz, candidates notice the contradiction, and the ones with options walk. The JD, the screen, and the assessment have to tell the same story. The assessment end of that story is covered in how to assess DevOps engineers without a question bank.

Where we fit in

The premise of this post - name capabilities, then verify them - is the premise of SkillBricks. Candidates on the platform carry skill walls of verified, tiered capabilities earned in live, observed assessments in real environments, so "can take a workload from symptom to root cause" stops being a JD aspiration and becomes a searchable fact. Candidates are anonymous until you choose to make contact, and the evidence is browsable before any commitment.

Write the better JD either way. But if you want the capability search to start from proof instead of applications, that is what we built.