Job Description Rules

A job description's real audience is the qualified person deciding in under a minute whether to apply — every buzzword, inflated requirement, and vague responsibility in it filters out good candidates before it filters out bad ones, because strong candidates self-select out of postings that read as unclear or unrealistic.

Real responsibilities over buzzwords

• Describe what the person will actually do day-to-day and in a typical week, using concrete verbs and real artifacts ("write and ship backend services in Go," "run weekly customer interviews and turn findings into roadmap input"), not abstractions ("drive synergies," "be a rockstar who wears many hats").
• Anchor each responsibility to a real outcome the team needs, not a generic duty copied from a template — a candidate can tell the difference between a role description written from the actual job and one assembled from a job-posting template, and the former gets better applicants.
• Cut corporate jargon and internal-only terminology a candidate can't be expected to know — if a phrase would need explaining in the interview anyway, explain it in the posting or replace it with plain language.

Must-have vs nice-to-have separation

• Split requirements into two explicit lists: what's actually required to do the job, and what's a bonus. Research on qualification gaps by gender shows this separation measurably widens the applicant pool — many strong candidates self-select out of a single merged list if they don't meet every item.
• Keep the must-have list short and genuinely non-negotiable — if you'd still consider a candidate missing one of the "must-haves," it isn't one; move it to nice-to-have or cut it.
• Distinguish skills from credentials in the requirements. A specific skill ("comfortable writing SQL queries against a large schema") is more honest and more filterable than a proxy credential ("Bachelor's degree required") that may screen out capable candidates who learned the skill differently.

Salary transparency

• Include a real salary range whenever legally required and, in that absence, as strong default practice — postings with a visible range consistently get more and better-matched applications, since candidates increasingly filter out listings without one before ever opening them.
• Make the range meaningfully accurate to the actual band for the role and level, not an artificially wide range spanning multiple levels just to stay non-committal — a range from $60k to $150k signals the posting hasn't actually scoped the role yet.
• State clearly what else is part of compensation (equity, bonus structure, benefits) rather than folding it vaguely into "competitive total compensation" with no further detail.

Inclusive language

• Avoid gendered or culturally coded language shown to skew applicant pools — words like "ninja," "rockstar," "dominant," or masculine-coded competitive framing measurably reduce applications from women and other underrepresented candidates without improving candidate quality.
• Write accessibility and work-arrangement details plainly and factually (remote/hybrid/onsite, time zone expectations, physical requirements if genuinely applicable) rather than leaving them ambiguous, which disproportionately discourages candidates who need that information to self-assess fit.
• Avoid age-coded language ("digital native," "recent graduate preferred" absent a real reason) and unnecessary experience-year requirements that function as an implicit age filter without being a genuine job requirement.

Cutting requirement inflation

• Audit every requirement against a real question: would someone doing this job well today actually meet this bar, or is it aspirational padding? A senior engineer writing the posting routinely lists skills at their own level, which filters out perfectly capable candidates at the role's actual level.
• Cut arbitrary years-of-experience requirements not tied to a genuine capability threshold — "5+ years" screens on tenure, not skill, and disproportionately excludes career-changers and self-taught candidates who may be fully capable.
• Resist listing every tool or technology the team has ever touched as a requirement — list what's actually needed on day one, and note that adjacent tools can be picked up on the job if that's genuinely true.
• Keep the total requirements list short enough to scan in a few seconds — a wall of 15+ bullet requirements reads as either poorly scoped or deliberately intimidating, and depresses application rates from otherwise qualified candidates.

What to avoid

• Don't disguise a demanding or understaffed role behind energetic language ("fast-paced," "wear many hats") without being specific about what that actually means in practice — vague enthusiasm reads as a red flag to experienced candidates, not as appealing.
• Don't list a requirement you don't actually enforce in practice — every unenforced requirement erodes trust in the rest of the posting once a hired candidate discovers it wasn't real.
• Don't leave the actual scope of the role implicit ("other duties as assigned" as the sole description of a major part of the job) — describe the real second half of the role explicitly, even if it's less exciting to write about.