How to write a job description that gets applications

The reader you are actually writing for

The person you most want is employed, reasonably happy, and giving your posting about fifteen seconds. They are not reading; they are deciding whether to read. Everything about the structure follows from that.

So the first three lines carry the whole load: what the role is for, why it exists now, and what makes it different from the four other postings open in their other tabs. A paragraph about your company's journey spends that budget on the wrong thing.

The second reader is your own hiring panel. Six weeks from now, the description is what everyone on it silently assumes they agreed to — which is why a vague one produces interviews that assess different jobs.

Write outcomes, not activities

Most responsibility lists describe what the person will be busy with: "manage the content calendar", "liaise with stakeholders", "own the roadmap". None of that says what will be different because they were there.

Outcomes are checkable and time-bound. "By month six, every product launch has a written positioning brief before design starts" tells a strong candidate whether they want the job and tells a weak one that they will be measured.

Four to six outcomes is enough. They also give you the interview plan almost for free: each outcome is a question about whether this person has produced that result before.

Be honest about requirements

Split requirements from nice-to-haves and mean it. A requirement should be something the role genuinely cannot be done without — if you would hire someone excellent who lacked it, it is a nice-to-have.

Years of experience are a weak proxy for capability and a strong filter against people who got there faster, changed field, or took time out. Where you can name the capability instead, name the capability.

The degree line deserves the same scrutiny. If you cannot say what the degree guarantees that the outcomes do not already test for, it is narrowing your pool for nothing.

Where the wording quietly narrows the pool

Beyond the requirements list, a description filters through its vocabulary. Internal job titles, product code names and acronyms only your company uses all read as "you had to be here already" — and the candidates who politely move on are the ones with options.

Superlative stacking does the same thing from the other direction. A role that wants a rockstar who thrives in ambiguity, wears many hats and is obsessed with excellence has described a personality rather than a job, and it tends to attract people who are good at describing themselves that way.

Then there is the unspoken demand hidden in tone: "fast-paced" and "we work hard and play hard" are read as hours, whether or not you meant them that way. If you do have unusual demands — on-call weeks, travel, shift cover — say so plainly instead. People self-select much better on a fact than on a vibe, and the ones who stay were not surprised.

The cheapest check is to have someone outside the team read it and tell you what the job is. If they get it wrong, the wording is the problem, not their attention.

Say the things candidates are looking for

Where the role is based and what the working arrangement really is, in plain terms — hybrid means nothing until you say which days and whether it is enforced.

The salary range, unless you have a reason not to, and check your local rules because in several jurisdictions publishing it is not optional. Either way, agree it internally before posting; setting a range after candidates are in process is painful.

Who the role reports to, who else is on the team, and what the process looks like: how many stages, roughly how long, and whether there is an exercise. Ambiguity here costs you the candidates with options.

Cut it down, then read it cold

Long descriptions do not screen better; they are skimmed harder. If a sentence would be true of the same role at any company, delete it.

Then read the whole thing as the employed, mildly curious candidate. Do the first three lines survive? Is there anything specific enough that they could not have guessed it? Would the outcomes make a strong person curious rather than wary?

Finally, check it against the interview plan and the scorecard. If the description promises one job and the interview assesses another, you will hire well for the wrong role.

Frequently asked questions

How long should a job description be?

Short enough to be read in full. If it runs past a screen and a half on a phone, the parts that do the work are competing with the parts that do not.

Should I include a salary range?

Check your local rules first — several jurisdictions now require it. Where it is optional, publishing a range still saves everyone the conversations that end at the last stage, and it signals that you have decided what the role is worth.

What is the difference between a description and a scorecard?

The description is external and sells the role; the scorecard is internal and defines how you will judge it. If you write the outcomes properly, the scorecard is mostly the same list turned into evidence you would accept.

Keep reading

Or see what the HR Agent can produce, and the example deliverables it has already produced.