How to Write a Job Description That Attracts the Right People

A job description works when the right person reads it and thinks “that is my job” and the wrong person reads it and self-selects out. Most job descriptions do neither, because they are written as internal justification documents and then posted publicly without translation.

The tell is the opening paragraph about the company being a dynamic, fast-growing leader in its space. Nobody has ever chosen a job because of that sentence.

Lead With the Work

The first thing a candidate wants to know is what they will actually do on a Tuesday. Put it first, before the company boilerplate, before the values, before the mission statement.

Before:

Founded in 2015, we are a rapidly growing, innovative technology company dedicated to transforming the way businesses operate. We pride ourselves on our collaborative culture, our commitment to excellence, and our passion for pushing boundaries. We are currently seeking a talented and motivated individual to join our dynamic team.

After:

You will own the billing system: the subscription logic, the invoicing pipeline, and the reconciliation reports finance depends on every month. It is currently one large service that three people understand well, and the first six months are about making that number bigger.

The second version tells a candidate what they would spend their time on and hints honestly at the state of things. It will attract fewer applicants and better ones, which is the actual goal.

Fix the Requirements Section

This is where most descriptions do real damage. Long requirement lists disproportionately deter qualified candidates who do not match every line, and the effect is well documented as being uneven across groups. You lose people you wanted.

Two changes help.

Split must-have from nice-to-have, and be honest about which is which. Most lists have three genuine requirements and eleven preferences dressed up as requirements. If you would hire someone excellent who lacked it, it is a preference.

Write requirements as capabilities, not credentials. “Can debug a production incident in a service you did not write” describes what you need. “5+ years experience with distributed systems” is a proxy that filters on career shape rather than ability.

Cap the must-have list at five items. If you cannot get under five, you are writing two jobs.

Say the Uncomfortable Things

The best filtering mechanism available is honesty about the parts of the job people would want to know before accepting.

Is there an on-call rotation? Say so and say how often. Is there significant legacy code? Say so. Is the team rebuilding after most of it left? Say so, carefully but truthfully. Is the role 40 percent meetings? Say so.

Candidates find all of this out in week two anyway. Saying it upfront costs a few applications and saves you a bad hire and a resignation at month five.

Include the Salary

Increasingly a legal requirement in various jurisdictions, and a good idea everywhere regardless.

Omitting it does not preserve negotiating room. It filters out experienced candidates who will not spend three interview rounds discovering the range is below their floor, and it disadvantages exactly the people least comfortable asking. Post a real range, not one so wide it conveys nothing.

Write It So a Human Reads It

Job descriptions are read on a phone, on a commute, alongside eleven others. Structure accordingly. Short paragraphs, real headings, and no wall of bullet points.

Cut every phrase that is true of every job: fast-paced, wear many hats, self-starter, team player, rockstar, ninja, passionate. They convey nothing and they make the specific parts harder to find.

A Wrivio Context for this could say:

Rewrite this job description for candidates rather than for internal approval. Lead with what the person will actually do day to day. Convert credential requirements into capability descriptions. Remove generic phrases such as fast-paced, dynamic, passionate, and self-starter. Use short paragraphs and plain language. Keep every salary figure, location, contract type, and named requirement exactly as written, and do not invent responsibilities or benefits that are not in the original.

Press Ctrl+Shift+Space, paste the internal version, and check the diff. The instruction not to invent benefits matters, because a rewrite that adds “flexible working” to a role that does not offer it creates a problem at offer stage.

Test Before Posting

Two checks.

Show it to someone currently doing that job on your team and ask whether it describes their work. If they hesitate, the description is aspirational rather than accurate.

Read the must-have list and ask whether the last person you hired into this role would have met every item on their first day. Usually they would not, which tells you the list is fiction.

Common Questions

How long should it be?

Four hundred to six hundred words. Beyond that, sections stop being read.

Should we list our values?

Only if they are specific and reflected in how the team operates. Generic value statements are ignored, and false ones cause resignations.

Does inclusive language actually change who applies?

Evidence suggests the requirements list matters more than word choice. Shortening it has a bigger effect than adjusting adjectives.

What about writing it with AI?

Fine for structure and tone. Do not let it generate the responsibilities, because it will produce the generic version you were trying to escape.

Download Wrivio for Windows to turn an internal role spec into something a candidate would actually want to read.