Most job adverts ask candidates to do something impossible: read a list of adjectives and decide whether they qualify. “Excellent communicator.” “Strong commercial awareness.” “Proactive self-starter.” Nobody reads those lines and thinks “no, that is not me”. So everyone applies, and the work of figuring out who actually fits lands back on your desk.
A requirement is only useful if a candidate can check it against their own experience and give an honest yes, no or “partly”. This guide walks through how to write requirements that pass that test. It applies whether you hire in Manchester or in Utrecht, and whatever tools you use.
Key takeaways
- A requirement is checkable when a candidate, or a reviewer, can point to proof in a CV or an answer.
- Describe the work or the outcome, not the personality. Name the level in terms of tasks, not years.
- Split compound items so that each line has one test.
- Keep the list short: three to five must-haves are easier to check than twelve.
- Test every line for fairness before you publish it.

The test: could a candidate point to the evidence?
Before a requirement goes into the advert, ask one question: if a candidate had this, where in their CV or their working life would it show up?
If the answer is a specific thing (a qualification, a tool they have used, a type of work they have done, a responsibility they have held) the requirement is checkable. If the answer is “it would come across in how they write” or “you can just tell”, it is not a requirement. It may still matter, but it belongs in the interview, not the filter.
Some quick rewrites:
- “Excellent communication skills” becomes “Has written customer-facing documents, such as reports, proposals or help articles”.
- “Strong Excel skills” becomes “Has built spreadsheets with lookups and pivot tables for regular reporting”.
- “Commercially minded” becomes “Has worked to a sales or budget target and can describe how they tracked it”.
- “Fluent Dutch” becomes “Can hold a work meeting in Dutch (roughly B2 level or higher)”.
Each rewrite is longer. A candidate reading it knows whether they have done that thing. You, reading their application, know what to look for.
Describe the work, not the person
Requirements written about personality (“dynamic”, “energetic”, “a good cultural fit”) are hard to check and easy to apply unfairly. They invite reviewers to fill the gap with gut feeling, which is where bias tends to creep in.
Requirements written about the work are different. “Has handled a caseload of customer complaints from first contact to resolution” describes something a candidate either did or did not do. It also tells them what the job involves, which helps the people who would hate it to decide not to apply.
A useful habit: write down the three to five things the person will spend most of their week doing. Then write each requirement as evidence that someone has done one of those things before, or something close to it.
Be specific about level, not about years
“Five years’ experience” is one of the most common requirements in job ads, and one of the least useful. Years are a proxy. What you usually want is a level of responsibility or a range of situations the person has handled. Someone can do the same thing for five years, and someone else can cover a lot of ground in two.
Time-based requirements also carry a legal risk. In the UK, a requirement that is harder for one age group to meet can amount to indirect discrimination under section 19 of the Equality Act 2010 unless you can show it is a proportionate means of achieving a legitimate aim. The Netherlands has comparable protection against age discrimination in employment under the Wet gelijke behandeling op grond van leeftijd bij de arbeid. Neither law bans asking for experience. Both mean you should be able to explain why the specific thing you asked for is needed.
So instead of “5+ years in accounts payable”, try “Has run a month-end close for accounts payable, including supplier reconciliations”. That says what you actually need, and a strong candidate with three years can recognise themselves in it.
Name the tool, or say you do not care which one
“Experience with CRM systems” leaves a candidate guessing. Do you use Salesforce and need someone who knows it? Or would any CRM do, because the skill is keeping customer records tidy?
Pick one:
- If a specific tool matters, name it: “Has used Salesforce to manage a sales pipeline”.
- If it does not, say so: “Has used any CRM (for example HubSpot, Salesforce or Pipedrive) to manage customer records”.
The second version widens your pool without lowering the bar. It also prevents candidates who used a different system from ruling themselves out.
Split compound requirements
“Experience in project management and stakeholder engagement in a regulated environment” is three requirements in a trench coat. A candidate who has two of the three cannot answer it honestly with a yes or a no.
Break it up:
- Has planned and delivered a project with a fixed deadline.
- Has reported progress to senior people outside their own team.
- Has worked in a regulated sector such as finance, healthcare or energy.
Now the candidate can check each one, and you can see which parts they have. You may also discover, once it is written out, that only one of the three is really essential.
Separate the yes/no facts
Some things are not about skill at all. They are facts about the candidate’s situation:
- Do they have the right to work in the UK, or in the Netherlands?
- Can they start by a certain date?
- Can they work on site in Rotterdam three days a week?
- Do they hold a driving licence, if the job involves driving?
These belong in short yes/no questions that the candidate answers themselves, not mixed into the skills list. Keep them to what the job really needs, and do not ask for information you have no reason to collect. Under UK GDPR and the GDPR in the Netherlands, collecting only what you need is a legal principle, not just good manners. The UK regulator, the ICO, has guidance on recruitment and selection that is worth reading before you design an application form.
Keep the list short
A long list does not make an advert more rigorous; it puts off people who meet the core needs. Aim for three to five requirements that genuinely decide whether someone can do the job, then a short, clearly labelled list of things that would be a bonus. (There is a separate post on how to split must-haves from nice-to-haves.)
A worked example
Here is a requirements section for a customer support lead role, before and after.
Before:
- Excellent communicator with a passion for customers
- 5+ years in customer service
- Experience with ticketing systems
- Strong leadership skills
- Degree preferred
After:
- Has handled customer queries by email or chat, including complaints, and resolved them without escalation in most cases.
- Has led or coached a small team (two or more people), including running regular one-to-ones.
- Has used a ticketing system such as Zendesk, Freshdesk or similar to manage a shared queue.
- Can write clear help articles or reply templates in English.
Yes/no questions: right to work in the UK; able to work UK hours.
The “after” version drops the degree (the work does not need it), drops the years (the coaching requirement captures the level), and turns every line into something a candidate can find, or not find, in their own history.
Why this pays off
When candidates can check themselves against your requirements, more of the people who apply are people who meet them. When you review, you are comparing evidence against clear statements instead of reading between the lines.
It takes an extra half hour to write requirements this way. That half hour comes back many times over at the review stage, and it gives every applicant a fairer, clearer picture of what you are asking for.
Twelve rewrites you can copy
| Vague requirement | Why it is hard to check | Checkable version |
|---|---|---|
| Excellent communication skills | Everyone claims it; no task named | Writes clear emails or reports for customers, suppliers or colleagues |
| Senior-level experience | Titles differ across companies | Has led a project, a team or a process change, paid or unpaid |
| Strong analytical skills | No task named | Uses data to answer a business question, for example building a monthly report |
| Proficient in Excel | “Proficient” means different things | Builds spreadsheets with formulas and checks totals for accuracy |
| Self-starter | A trait, not a task | Has started or improved a process without being asked, and can describe it |
| Busy environment experience | Unclear what pace | Has handled several customer requests or deadlines in the same day |
| Team player | A trait, not a task | Has worked on a project with people from two or more teams |
| Customer-focused | Vague | Has resolved customer complaints or questions in writing or by phone |
| Detail-oriented | Cannot be checked on a CV | Has checked records or documents for errors as a regular task |
| 5+ years of experience | Years do not show skill | Has done [named task] on [number] projects or for [named volume] |
| Degree required | May exclude people with the skill | Degree only if the law or a regulator requires it; otherwise, name the knowledge |
| Native English speaker | Signals national origin | Writes and speaks English at the level needed for [task], for example handling customer calls |
Three questions to check each line
- Could a candidate point to proof? For example, a job task, a project, a result or a sample of work. If the proof would be “I am a good communicator”, the line is not checkable.
- Could two reviewers agree? Give two colleagues the same CV and the requirement. If they mark it differently, the wording is too loose.
- Is it needed on day one? If the person could learn it in the first three months, move it to nice-to-have. See must-haves vs nice-to-haves.
A fairness check on every line
Wording can exclude people without anyone intending it. Before you publish, read each line with these questions in mind.
| Check | Example of a problem | Better wording |
|---|---|---|
| Age | “Digital native”, “recent graduate”, “up to 10 years of experience” | Name the tool or the task |
| Sex or gender | “Salesman”, “he will” | “Sales representative”, “the person” |
| Disability | “Must be able to stand for eight hours” for an office role | Describe the essential tasks and allow for adjustments |
| National origin | “Native speaker”, “must be from the area” | State the language level needed for the tasks |
| Family status | “Must be able to work late any day” | State the actual schedule needs and any flexibility |
| Other | “Cultural fit” | Describe observable behaviours linked to the work |
The official sources on equal treatment give the baseline. In the US, see the Equal Employment Opportunity Commission page on prohibited employment policies and practices. In Great Britain, see Acas on recruitment. In the EU, see the Employment Equality Directive and your national law. Our guide to interview questions you cannot ask covers a related set of risks.
A requirement card
For each must-have, fill in one short card. Keep the cards in the role brief, and share them with the recruiter and the interview panel.
| Field | Example (fictional) |
|---|---|
| Requirement | Writes clear emails to customers |
| Why it matters | The role answers 30 to 50 customer emails each day, and unclear replies create repeat contacts |
| What counts as proof | A job task that includes customer email; a writing sample; a described example of resolving a complaint in writing |
| What does not count alone | The phrase “excellent communicator” |
| How we will check | CV passage first; one question in the interview; a short writing task for finalists |
| Fairness check done | Yes, by [name], [date] |
Cards take five minutes each, and they make later steps faster. The recruiter knows what to look for in a CV. The interviewers know what to ask. The candidate can read the card and decide honestly whether to apply.
FastHire is being built around checkable requirements. It shows each job requirement next to the exact CV passage that supports it, so a reviewer can verify the evidence in seconds, and candidates can check their fit before they apply. FastHire is coming soon. It does not rank, score or reject candidates. People make every decision.
Frequently asked questions
What is a checkable job requirement?
It is a requirement written so that a reviewer or a candidate can find proof of it in a CV or in an answer, such as “writes clear emails to customers”, instead of “excellent communicator”.
How long should a requirement list be?
Three to five must-haves is a good range. More than that reduces the pool and makes checking slow.
Should I list years of experience?
Only when the years connect to a task or volume you can describe. Years alone do not show skill and can exclude people who learned quickly.
Can candidates check their fit before applying?
Yes, if the advert is specific. Put the must-haves in plain words and say how you will check them.
How do I test a new requirement?
Give two colleagues the requirement and a few real CVs. If they disagree on the marks, rewrite the wording.
Related guides
- Hiring guides for hiring managers
- Must-haves vs nice-to-haves
- How to write a role brief
- How to write a job ad that gets the right applicants
- All hiring guides for employers
This is general information, not legal advice.
