How to Write Must-Have Skills in a Job Description (So Screening Works)

Most job descriptions have a "must-have skills" section. Almost none of them are written specifically enough to actually work as a filter.

A job description already carries two jobs at once: pulling in the right people and then correctly sorting the ones who show up. Getting candidates excited enough to apply in the first place is its own craft. This is about the second half, the part where you decide who actually gets through.

That's not a small problem. Whoever screens the applications, whether it's a recruiter reading resumes by hand or an AI tool scoring them against the JD, uses that list as the yardstick. If the yardstick is vague, the shortlist that comes out the other end is vague too. You end up interviewing people who technically match every line item and still aren't right for the role.

This is something we run into constantly at Recrew, because must-have skills are exactly what feeds our screening. When a JD's requirements are specific, matching is fast and accurate. When they're not, we see it immediately in the shortlist.

Here's what actually goes wrong, and how to fix it before you post the role.

Start With the Actual Tasks, Not the Title

Before you write a single requirement, write down what the person will actually be doing in their first few weeks. Not the job title, the actual tasks that will fill a normal Tuesday. For the DevOps example later in this piece, that's the difference between "stand up new infrastructure for three product lines" and "keep existing infrastructure running and patched." Same title, different calendar.

Every must-have on the list should trace back to one of those tasks. If a skill doesn't map to something the person will actually do in the role, it's not a must-have, and it may not belong on the JD at all.

The problem with most "must-have" lists

Two things usually go wrong with a requirements section.

Nice-to-haves get mixed in with real must-haves. A hiring manager writes down everything they'd ideally want, sorts none of it, and now "5+ years of experience" sits next to "familiarity with Figma" with no signal about which one is actually non-negotiable. A screener, human or AI, has no way to weigh these differently unless someone tells it to.

The skills that are listed are named too broadly to distinguish between different people. "Strong DevOps experience" can describe someone who spends their day building infrastructure from scratch, and it can just as easily describe someone who's excellent at keeping an existing system running and rarely touches new builds. Both are legitimate, valuable skill sets. They are not the same job.

A real example of what goes wrong

We've seen this exact pattern play out on a DevOps search. The JD asked for a "DevOps engineer with strong infrastructure skills." What the team actually needed was someone who could build new infrastructure from the ground up, largely from scratch.

The requirement as written didn't say that. It just said infrastructure skills. So when resumes got scored against it, site reliability engineers and infrastructure maintainers, people who are genuinely excellent at running and stabilizing existing systems, ranked just as high as the builders the team actually needed. The words on both kinds of resumes looked similar. The actual day-to-day work was different.

Nothing about the screening was broken. The requirement just wasn't specific enough to draw the line the team needed drawn.

What a must-have actually needs to do

A must-have skill has one job: let a screener tell a real match apart from a near-miss. If two candidates with meaningfully different profiles could both plausibly claim to meet a requirement as written, the requirement isn't doing its job yet.

A few checks that catch most of the vague ones:

• Name the skill and the context it's used in: "Python" tells you almost nothing. "Python, for building and maintaining production ML pipelines" tells a screener exactly what to look for in a resume.
• Call out the specific distinction that matters for this role: Builder vs. maintainer, generalist vs. specialist, and early-stage scrappy vs. structured enterprise process. If your team actually cares about this distinction, say it directly. Don't assume the words you chose will carry that meaning on their own.
• Keep true must-haves to 3 to 5: Past that point, you're not writing a filter anymore. You're writing a wish list, and every extra "must-have" widens what counts as a false negative.
• Separate nice-to-haves clearly: This helps candidates self-select honestly, and it stops a screener from penalizing someone for missing something that was never actually required.

Everything above is about technical, tool, and domain skills, since that's where vague must-haves cause the most damage in screening. Soft skills still belong in the list when one is genuinely non-negotiable for the role, communication for a job that's client-facing all day, for instance, but keep it to one or two, and write it the same way you'd write a technical must-have: tied to a specific situation, not a trait. "Can walk a non-technical client through a delay without losing their confidence" screens far better than "strong communication skills."

Before and After

Here's what that looks like applied to the DevOps example above.

• Before: Strong DevOps experience.
• After: 3+ years building cloud infrastructure from scratch, not primarily maintaining existing systems. Hands-on with Terraform and CI/CD pipeline design. (Nice-to-have: Kubernetes at scale.)

The "after" version still fits in one line. It just tells a screener, human or AI, exactly what separates a match from a near-miss, and it moves "Kubernetes at scale" out of the must-have list and into the wish list where it belongs.

A Quick Test You Can Run Before You Post

Before a requirement goes live, try to name two people with genuinely different backgrounds who could both honestly claim to meet it as written. A builder and a maintainer, or someone from a five-person startup and someone from a 500-person enterprise team.

If two meaningfully different profiles pass that easily, the line needs another sentence of context. If you can't come up with a second profile without stretching, the requirement is probably already specific enough to leave alone. This takes about thirty seconds per line and catches most of the vague ones before they ever reach a resume.

This lines up with a concept TestGorilla calls the 70/30 rule in its current skills-based hiring research: hire for the roughly 70% of the role that's genuinely non-negotiable, and expect the remaining 30% to be learned on the job rather than demanded upfront. The teams that get the most out of this approach are the ones that have actually decided, in writing, which 70% that is, rather than leaving it to whoever happens to be reading the resume that day.

Why This Matters More With AI Screening in the Loop

When a person is reading resumes manually, a vague requirement is a minor annoyance. They can use judgment to fill the gap, even if that judgment is inconsistent from one reviewer to the next.

An AI scoring tool doesn't get to use unstated judgment. It scores against exactly what the must-have list says. If the list says "strong DevOps experience" with nothing more, the tool has no way to know the team actually meant "someone who builds, not someone who maintains." It will score both profiles as reasonable matches, because as written, both of them are.

This is the part that's easy to miss. A more specific requirements section doesn't just help candidates understand the role better. It's the actual input your screening runs on, whether that's a recruiter's judgment or a tool like Recrew's JD Builder extracting must-have criteria as its own step before scoring even starts. Better inputs are the difference between a shortlist of five strong builders and a shortlist of five people who are good at their jobs, just not the job you're hiring for.

FAQs

1. How many must-have skills should a job description have?

Three to five. Past that, you're no longer describing what's non-negotiable; you're describing everything you'd like, and a screener loses the ability to tell the difference.

2. What's the difference between a must-have and a nice-to-have?

A must-have is something the role cannot be done well without, and it should be rare enough on the market that it genuinely narrows the pool. A nice-to-have is something that would help but that a strong candidate could reasonably pick up on the job. If you're not sure which one a skill is, ask whether you'd still make an offer to an otherwise excellent candidate who was missing it. If yes, it's a nice-to-have.

3. Does a vague requirements section actually hurt AI resume screening?

Yes, directly. AI scoring tools match resumes against exactly what the must-have list says, with no ability to infer unstated context. A requirement like "strong DevOps experience" without further detail will score builders and maintainers as equally strong matches, even when the role needs one and not the other.

4. Should I write the requirements section myself or use a tool?

Either can work, as long as the must-haves end up specific enough to distinguish between adjacent skill sets. Writing it yourself works fine if you're deliberate about naming context, not just skills. A tool like Recrew's JD Builder helps when you want that specificity built in from the start rather than caught after a bad shortlist.

5. Do soft skills belong in the must-have list?

Sometimes, but sparingly. One or two genuinely role-critical soft skills communication for a client-facing role, time management for someone juggling several concurrent projects can sit alongside the technical must-haves. The same rule applies: name the situation, not the trait. "Time management" is too vague to screen against. "Can manage 4 to 5 concurrent client engagements without missing deadlines" isn't.