This site stores only what it needs: your session, your language and your theme. No advertising cookie, no third-party tracker.

SkillMatchLab
Back to home

Writing a job description that can actually be analysed

A vague description produces a vague screen, whether a human or a machine does the reading. Six rules for writing one you can genuinely use.

What makes a description unusable

Three faults come up almost every time: implicit skills that everyone on the team knows but nobody wrote down, catch-all lists where the essential sits next to the decorative, and adjectives where situations belong.

"Rigorous, autonomous, a good communicator" can be checked against no resume. What can be checked is "led a production migration alone", "onboarded two new joiners", "held an on-call rota".

Separate the essential from the desirable

This is the only distinction that genuinely changes the outcome of a screen. A description that puts seven years of Go and familiarity with an internal tool on the same footing condemns the screen to treat them the same.

In practice: four or five critical requirements at most. Beyond that it is no longer a role, it is a wish list, and the screen will reject perfectly capable people.

Name the technology and the level expected

"Knowledge of Kubernetes" covers both having followed a tutorial and having operated a production cluster. Stating the level expected avoids rejecting the good ones and interviewing the rest.

Three phrasings are enough, and all three can be verified:

  • has already shipped it to production, alone or in a pair;
  • has used it in a supervised setting, without owning it;
  • must be able to get up to speed within a few weeks.

Describe the work, not the org chart

A capable candidate chooses on the substance of the work: what there will be to do in the first six months, with which team, on which product, with how much technical debt. Reporting lines and a list of company values teach nobody anything.

That context also serves the screen: it makes it possible to recognise that someone has held this kind of role before, even when job titles differ from one company to the next.

Write to be read, machines included

Structured text — requirements in short sentences, one per line — reads well for a hurried human and for a tool alike. This is not a concession to software: it is the same clarity serving both.

A ten-line paragraph with four requirements buried inside forces everyone, humans included, to guess what matters.

An eight-line template

Short enough to fit on one screen, and enough for a serious screen:

  • the real job title — the one candidates will search for;
  • context in three sentences: product, team, state of what exists;
  • four or five critical requirements, one per line, with the level expected;
  • three important requirements;
  • what can be learned on the job, said explicitly;
  • the first six months: what there will be to do;
  • the concrete conditions: location, remote work, on-call, travel;
  • the salary range — leaving it out costs more applications than the figure does.
ResourcesReading a match score: what it tells you, and what it doesn't

See what this looks like on your own resumes

One free analysis every month, no credit card. The score, the gaps, and what to check in the interview.

Start for free