How to Write a Job Description That Attracts the Right Candidates (Not Just More of Them)

Most job descriptions are written backwards. They start from a template, list every possible responsibility anyone in the role has ever touched, pile on a wishlist of "nice to have" requirements until it reads like a job for three different people, and end with a generic line about "competitive salary and growth opportunities." Then the recruiter is surprised when the applicant pool is either enormous and mostly irrelevant, or tiny because nobody felt qualified enough to apply.

A job description isn't a legal formality or an HR checkbox — it's the first filter in your entire hiring process, and it does more to shape who applies than almost anything that happens afterward. Get it right, and sourcing, screening, and interviewing all get easier downstream. Get it wrong, and no amount of AI screening or clever outreach fully makes up for a funnel that was mismatched from the start.

This is a practical guide to writing job descriptions that attract the right candidates — not just more of them.

Why most job descriptions attract the wrong pool

Before fixing this, it helps to understand why it goes wrong so consistently:

• Requirement inflation. A hiring manager, wanting to be safe, adds every skill that might conceivably be useful — "must have," "should have," and "nice to have" all blur together into one long list. Strong candidates who meet 70% of an inflated list often self-select out, assuming they don't qualify, while candidates who ignore requirements entirely apply regardless — meaning the filter fails in both directions.
• Vague, jargon-heavy language. Phrases like "dynamic self-starter" or "wear many hats" convey almost nothing concrete about the actual job, and tell a candidate more about what the company thinks sounds impressive than what they'd actually be doing day to day.
• Responsibilities without context. A bulleted list of tasks, with no sense of what success looks like or how the role fits into the team, makes it hard for a genuinely strong candidate to judge fit — and just as hard for a recruiter to write an accurate screening rubric later.
• Copy-pasted structure that doesn't match the actual role. Reusing last year's JD for a role that has since evolved, or borrowing a template built for a completely different company size or industry, quietly misrepresents the job before a candidate has even applied.
• No signal on what actually matters most. When every requirement is presented with equal weight, candidates (and later, AI screening tools) have no way to distinguish what's genuinely critical from what's a minor preference.

The core principle: write for the person you actually want, not everyone who might apply

The instinct to cast a wide net — list everything, in case it filters in more candidates — usually backfires. A job description's job isn't to maximize applicant volume; it's to help the right candidates recognize themselves in the role and self-select in, while giving mismatched candidates enough honest information to self-select out before either side wastes time.

This reframing changes almost everything about how to write one.

A practical structure that works

1. Start with a clear, specific job title — not an internal or inflated one. "Growth Marketing Manager" tells a candidate what to expect; "Marketing Ninja" or an overly specific internal title like "Associate Manager, Demand Gen Ops L3" either confuses candidates or makes the role invisible to job-board search. If the role is commonly known by a certain title in your industry, use that title, even if your internal org chart calls it something else.
2. Open with what the role actually is, in plain language, before diving into a bullet list. Two or three sentences on what this person will actually be doing and why the role exists — "You'll own [specific area], reporting to [role], working closely with [team]" — gives more useful context than a dozen bullet points alone, and helps a candidate quickly judge whether this even sounds like their kind of work.
3. Separate "must-have" from "nice-to-have," explicitly and honestly. This is one of the highest-leverage changes you can make. A short, genuinely necessary list of requirements — the things that would actually disqualify someone — followed by a clearly separate, shorter list of things that are a bonus but not required, does two things: it stops strong-but-not-perfect candidates from self-eliminating, and it gives whoever screens applications (human or AI) a much clearer rubric to score against.
4. Describe outcomes, not just tasks. Instead of "manage social media accounts," try "grow engaged audience across our social channels and report on what's working" — this tells a candidate what success actually looks like, not just what boxes to check, and it naturally attracts people who think in terms of outcomes rather than task completion.
5. Be specific and honest about compensation and logistics. Vague phrases like "competitive salary" convey nothing and increasingly frustrate candidates who expect transparency. A real range, even a wide one, filters out mismatches early and signals respect for candidates' time. The same goes for remote/hybrid/in-office expectations, travel requirements, and reporting structure — ambiguity here just gets discovered (and often resented) later in the process instead.
6. Use plain, specific language instead of jargon or buzzwords. "Strong communication skills" is close to meaningless on its own. "You'll be presenting findings to non-technical stakeholders weekly" tells a candidate exactly what kind of communication actually matters in the role, and lets them honestly self-assess against something concrete.
7. Write for the reader, not for internal audiences. It's common for JDs to accumulate language written to satisfy internal stakeholders (legal, a hiring manager's specific preferences, generic corporate boilerplate) rather than to actually inform a candidate. Read the draft back and ask, honestly, whether a stranger with no context on your company would understand what the job actually is after reading it once.

Writing for inclusivity, without diluting the substance

Language choices in a JD measurably affect who applies, and it's worth being deliberate about this rather than accidental:

• Avoid gendered or unnecessarily masculine-coded language — words like "dominant," "aggressive," or "ninja/rockstar" framing have been shown in research to discourage some qualified candidates, particularly women, from applying, even when the actual role has nothing to do with those traits.
• Be careful with age-coded phrases like "digital native" or "recent graduate preferred" unless age or recency of graduation is a genuine, legally defensible requirement — these can both discourage strong candidates and create legal exposure in some jurisdictions.
• Reconsider blanket degree requirements if the actual skill matters more than the credential — "Bachelor's degree required" for a role where relevant experience would serve just as well quietly excludes capable candidates who took a different path, and increasingly, this is exactly the kind of requirement skills-based hiring approaches are moving away from.
• Keep accessibility in mind for the posting itself — a JD that's a wall of dense text with no structure is harder for many candidates to parse, including those using screen readers or those for whom the posting's language isn't a first language.

None of this means diluting genuine requirements — it means making sure every requirement in the posting is actually there for a real reason, not habit.

A quick before/after example

Before: "We're looking for a dynamic self-starter to join our fast-paced team. Must have 5+ years experience, excellent communication skills, proficiency in Excel, PowerPoint, CRM tools, project management, and be a strategic thinker who can wear many hats. Competitive salary."

After: "You'll manage our regional sales pipeline end-to-end — tracking deals in our CRM, building weekly forecasts for leadership, and coordinating directly with the field sales team. Required: 3+ years in a sales operations or similar role, hands-on CRM experience (we use Salesforce), and comfort presenting numbers to non-technical stakeholders. Nice to have: prior experience in [specific industry]. ₹8–12 LPA depending on experience, hybrid — 3 days/week in our Bangalore office."

The second version is more specific, tells a candidate exactly what the job actually is, separates genuine requirements from bonuses, and gives real compensation and logistics — all of which produces a smaller, better-matched pool of applicants than the first.

How this connects to what happens after you post

A better job description doesn't just improve who applies directly — it improves everything downstream. Clearer, more specific requirements give screening (human or AI) a sharper rubric to score against, which is exactly why context-matching sourcing tools work better against a well-written JD than a vague one: a tool like Recruitkar's AI candidate discovery, for instance, matches candidates against the actual content of a job description rather than requiring a recruiter to guess the right search keywords — so a JD that clearly separates real requirements from nice-to-haves produces a meaningfully more relevant match than one that lists everything with equal weight. This is true regardless of which sourcing approach or tool a team uses; a sharper JD sharpens everything that follows it.

A short checklist before you post

• Is the job title one candidates would actually search for?
• Does the opening paragraph explain the role in plain language, before any bullet list?
• Are "must-have" and "nice-to-have" requirements clearly and honestly separated?
• Does it describe outcomes and success, not just a list of tasks?
• Is compensation and logistics information specific, not vague?
• Would a stranger with zero context on your company understand the actual job after one read?
• Has it been checked for gendered, age-coded, or unnecessarily exclusionary language?
• Is every requirement on the list genuinely necessary, or is something there out of habit?

Common mistakes worth calling out specifically

A few patterns show up often enough to name directly, since each one is an easy, low-cost fix once you know to look for it:

• The "unicorn" requirement stack. Requiring deep expertise in five unrelated disciplines — say, advanced data analysis, hands-on design skills, sales experience, and people management, all in one mid-level role — usually signals either an unrealistic budget expectation or a role that hasn't been scoped properly. If the requirements list reads like three different jobs stitched together, it probably is.
• Years-of-experience as a lazy proxy for skill. "7+ years required" is often used as a shortcut for "senior enough to do this well," but it screens out candidates who reached the same competency faster, and lets in candidates who spent seven years doing the bare minimum. Where possible, describe the actual competency required instead of defaulting to a year count as a stand-in for it.
• Burying the actual role under process description. Some JDs spend more space describing the interview process or company perks than describing what the person will actually do all day. Candidates evaluating fit need to understand the job itself first — process and perks matter, but they belong after the substance, not instead of it.
• Reusing a JD without revisiting it. A role posted for the third time in two years, using the exact same description each time, often no longer reflects how the role has actually evolved — what the team needed 18 months ago may not be what it needs now, and candidates can tell when a posting feels stale or generic.
• Writing to impress internal stakeholders rather than inform candidates. A JD that reads more like an internal pitch deck — heavy on company achievements and light on what the actual day-to-day work involves — often fails to give candidates enough to genuinely self-assess fit, even if it looks polished.

Testing your job description before it goes live

A quick, low-effort way to sanity-check a draft before posting: share it with someone outside the immediate hiring team — ideally someone unfamiliar with the role — and ask them to explain back, in their own words, what the job actually involves and what the two or three most important requirements are. If they can't do that easily, candidates reading it cold won't be able to either, and it's worth revising before it goes live rather than discovering the confusion later through a mismatched applicant pool.

The bottom line

A job description's real job is filtering, not broadcasting — helping the right candidates recognize themselves in the role and apply, while giving everyone else enough honest information to self-select elsewhere without wasting anyone's time. That single shift in mindset — writing for the person you actually want, rather than trying to appeal to everyone who might apply — does more to fix a messy applicant pool than almost any tool or process change further down the funnel. Fix the job description first; everything after it gets easier.