How to write a job description that attracts the right candidates
A job description that pulls in the right people does four things: it keeps the must-have list short, it shows the actual day-to-day of the role, it states the pay, and it's clear about where and how the work happens. Get those right and the people you want start applying. Get them wrong and you either hear nothing or drown in the wrong applications.
We heard the same complaint in nine calls and emails last week. Heads of TA blaming the market or the tool for a role that pulls in few or no candidates. When we read the specs, the pattern was the same every time.
How do you write a job description that attracts the right candidates?
Write it for a real person, not a wish list. Most specs are a wall of requirements with no sense of what the job involves, no pay, and a title nobody searches for. That combination puts off the people you want and pulls in the ones you don't.
Start with what the role does day to day and what success looks like in the first 6 to 12 months. People apply to a role they can picture themselves in. If your description is all "you must have" and none of "here's why it's worth it," strong candidates read it and move on.
And read it back as if you were the candidate. If you couldn't tick every box yourself, they can't either. That's often where the attraction problem starts, before anyone even reaches the pipeline. Why your job ads are attracting the wrong candidates goes deeper on the fit side of this.
How many must-have requirements should a job description have?
Five or fewer. A must-have is a requirement you'd reject a strong candidate over. A nice-to-have is everything else. Most specs mix the two and treat all of them as hard filters.
Go through your list line by line and ask one question: would you turn down someone excellent who's missing this? If the answer is no, it's a nice-to-have. Move it.
The best test is whether someone already doing the job well would pass their own spec. Often they wouldn't. That's your sign the list has drifted from the actual work.
Long lists of "essentials" deter strong candidates who don't meet every line, and that effect is sharper among underrepresented groups who self-select out when they can't tick all the boxes. As a TA leader at a large enterprise put it, "No one is ever gonna have every box ticked." Cut the list and you widen the pool without lowering the bar. The best hires don't always match the job description makes the case for hiring on transferable skills.
While you're at it, swap exact tools for the underlying skill. "Experience with a cloud platform" beats "4 years AWS specifically." The person with strong Azure experience is someone you'd hire, and a literal filter drops them. If you're worried about verifying real ability, how to tell if a candidate really has the skills on their CV is worth a read.
Should you put the salary in a job description?
Yes. Candidates skip roles with no pay info, and leaving it out wastes everyone's time when the band turns out to be wrong. Put a figure or a range in.
Salary bands also cause quiet contradictions. If the level of the role says senior and the band says mid, the people who match the title won't match the money, and the people who match the money won't have the experience. Fix that before you publish.
What words should you avoid in a job description?
Drop "ninja," "wizard," "rockstar" and "guru" from the title. Nobody searches for a marketing ninja, so the title hurts your reach, and the tone skews who applies. Keep the title plain and specific.
Cut jargon and internal acronyms from the body too. If a phrase only makes sense to someone already inside your company, it's noise to the candidate reading it cold. Plain language reaches more of the people you want and puts fewer of them off. Why the talent you want isn't applying, and how to find out covers the other things that turn candidates away.
Why aren't the right people applying to my job posting?
Usually because the spec contradicts itself or asks for someone who doesn't exist. A common one: "fully remote" in the description, "three days in the office" in the hiring manager's head, and a location filter set to a single city. You've asked for someone who's remote and local at once.
Be clear and honest about the work model and location up front. Ambiguity puts people off before they apply, and a contradiction guarantees the role can't be filled as written.
Sell the role, not just the requirements. Say who they'll work with, what they'll build, and where the growth is. A description that only demands and never explains why the job is worth having loses good people to roles that bothered to make the case.
How does adaptive matching help when the JD is still imperfect?
Even a well-written JD, read literally by a keyword tool, filters out strong people. If a requirement says "5 years in Python," a candidate with 4 years and a strong track record gets dropped. That's how a tight spec produces an empty pipeline.
Archer reads the intent behind a requirement rather than the literal text. If the spec asks for a specific cloud tool, it understands you mean cloud infrastructure experience, and surfaces people with the adjacent skills you'd actually accept. Someone missing one line of the spec still shows up.
It can't rescue a contradictory brief. If the role says remote and local at once, no matching approach can invent a person who's both. Fix the spec first, then let the matching read the rest with judgement.
Archer is hackajob's AI sourcing agent for passive, in-demand talent. It finds and qualifies the people you want, reading past the keywords to what the role actually needs. Book a demo.
Written by the hackajob team, drawing on conversations with heads of TA at enterprise firms and how Archer, our AI sourcing agent, matches candidates in practice.