A skills-based job description replaces the requirements wish-list with a short list of skills you will actually measure, states how each will be assessed, and separates what is genuinely required from what is merely nice to have. Anything you will not measure does not belong in the requirements section.
- If you will not measure it, it is not a requirement — move it or delete it.
- Cap the requirements list at five. Long lists mostly deter the candidates you want.
- Say how each skill will be assessed. Candidates self-select accurately when the process is visible.
- Years of experience is a proxy for depth; write the depth instead.
- Publish the salary range if you can. Its absence filters harder than any requirement in the list.
The test every requirement has to pass
Before a line goes in the requirements section, answer one question: how will we measure this?
If the answer is "we'll get a sense of it in the interview", it is not a requirement — it is a preference, and it belongs somewhere it cannot be used to reject anyone. If the answer is "we won't", delete it.
Applying only that rule usually cuts a job description in half, and the half that survives is the half you can defend.
What most job descriptions actually contain
A typical requirements list is a mix of four things that have been quietly merged:
- Skills you will measure. The real requirements.
- Proxies for skills you will not measure. Degrees, year counts, brand-name employers.
- Things the last person happened to have. Copied from the previous posting, never re-examined.
- Aspirations. The tooling you hope to adopt next year.
Only category one belongs in the requirements. Category two is what skills-based hiring is trying to remove. Category three is archaeology. Category four goes in "what you'll grow into" — that section is genuinely attractive to good candidates, so use it.
The structure
1. One sentence on what the person will own. Not the mission statement. What lands on their desk. "You will own our billing integrations — the provider adapters, the webhook pipeline, and the reconciliation job that finance depends on."
2. The first-quarter outcome. What "going well" looks like in ninety days. This is the single most useful paragraph in any job ad, and it is almost always missing. It tells a candidate whether they want the job, which is information you want them to have before they apply.
3. Three to five requirements, each phrased as a demonstrable skill.
| Instead of | Write |
|---|---|
| 5+ years backend experience | Has owned a production service, including being on call for it |
| Strong communication skills | Can write a design doc a non-engineer can act on |
| Bachelor's degree in Computer Science | Can reason about data structures and complexity trade-offs in a design discussion |
| Expert in React | Can explain a rendering performance problem and the trade-offs of two fixes |
| Team player | Has resolved a technical disagreement without escalating it |
The right-hand column is longer. It is also assessable, honest about what you actually need, and much harder to fake.
4. Nice to have, explicitly labelled. Label it and mean it. Candidates read unlabelled lists as mandatory.
5. How you will assess. Name the stages, the rough time cost, and what each one measures. Something like: one 60-minute structured interview on system design, one 90-minute paid work sample, one conversation with the team. This is not just courtesy — it improves your applicant quality, because candidates who are strong on the things you will measure now know that is what you will measure.
6. Salary range, location and working pattern. Concrete. "Competitive" is not a range and "flexible" is not a location.
Language patterns that shrink your pool
None of these are about being inoffensive. They are about not accidentally narrowing the funnel:
- Superlative-and-combat framing — "rockstar", "ninja", "crush", "relentless", "hard-charging". Reads as a warning about the culture to some candidates and as a shibboleth to others. Describe the work instead.
- Unexplained internal jargon. If a term only exists inside your company, it filters on having worked at your company.
- Inflated requirement counts. A twelve-item list is read as twelve gates by exactly the candidates who would have cleared the four that mattered.
- "Culture fit" as a stated criterion. Without a rubric it is a synonym for similarity. If you mean specific working norms — writes things down, comfortable with disagreement, works async — write those.
- Unnecessary physical or availability requirements. "Must be able to lift 20kg" in a desk role, or "always on" phrasing, both invite avoidable discrimination exposure.
A short template
Role. Senior Backend Engineer — Payments
You will own. Our billing integrations: provider adapters, the webhook pipeline, and the nightly reconciliation job finance depends on.
In your first quarter. Ship one new payment provider end to end, and cut reconciliation exceptions to under 1% of transactions.
Required — and how we assess it.
- Has owned a production service, including being on call for it (structured interview)
- Can design an idempotent, replay-safe integration against an unreliable third party (work sample)
- Can write a design doc a finance stakeholder can act on (work sample write-up)
- Reasons clearly about money handling: precision, currency, audit trail (structured interview)
Nice to have. Prior payments or fintech exposure; experience with a second cloud provider.
Process. A 60-minute structured interview, a 90-minute paid work sample, and a 45-minute conversation with two teammates. We give every applicant written feedback either way.
Range and location. [Range]. Remote within [region], or hybrid from [office location].
Then hold yourself to it
A skills-based job description is a promise about how you will decide. It only counts if the interview plan matches the requirements list, the rubric exists before the first candidate, and the final stage has a rubric too.
On CalHire the assessment is generated from the skills you set for the role and weighted by the composite you choose — test, interview, and role-fit — so the job description and the evaluation cannot drift apart. You can see how the pipeline is put together on the features page, or how it looks to a hiring team on for employers.
Frequently asked questions
- How many requirements should a job description have?
- Aim for three to five genuine requirements — the skills without which the person cannot do the job in the first quarter. Everything else belongs in a clearly-labelled "nice to have" section or should be cut. Long requirement lists are read as a checklist by candidates who already doubt they qualify, and as a suggestion by candidates who do not.
- Should I ask for a specific number of years of experience?
- Prefer describing the depth you need. "Has owned a production service through at least one serious incident" tells a candidate far more than "5+ years" and is something you can actually probe in an interview. Year counts also carry age-proxy risk while adding little predictive value.
- Does gendered or coded language in a job ad really change who applies?
- Wording changes the read. Aggressive or superlative framing ("rockstar", "crush targets", "relentless"), unexplained jargon, and inflated requirement lists all raise the perceived bar for candidates who are already less likely to apply speculatively. Plain, specific language about the work costs nothing and narrows the ad less.
- Where should the salary range go?
- In the ad, near the top. Beyond the jurisdictions where it is legally required, omitting it means candidates self-select on a guess, and the ones most likely to walk away are the ones with the least market information.