Why most job descriptions fail
The majority of job descriptions are written by copying the previous one, adding a few new bullet points, and posting it before anyone thinks too carefully about what the role actually requires. The result is a document full of hollow phrases — "strong communication skills", "team player", "fast-paced environment", "passionate about X" — that describe no one and therefore attract everyone.
This is a self-defeating pattern. Vague requirements attract a high volume of applications, most of which are a poor fit. Sifting through them is time-consuming. The best candidates — who have options — often skip postings that do not tell them something real about the role and the company. You end up with a lot of effort and not much to show for it.
The fix is not complicated. It requires being specific, honest, and willing to describe both the opportunity and the challenge of the role clearly enough that unsuitable candidates self-select out.
Start with the problem, not the job title
Most postings lead with the title and a paragraph of boilerplate about the company. The best postings lead with the problem the person will solve, or the impact they will have. Compare:
Generic: "We are looking for a talented Senior Backend Engineer to join our growing team and contribute to exciting projects."
Specific: "Our payments infrastructure processes £3M a day and currently has three engineers responsible for it. We need a fourth who can own reliability independently — someone who loses sleep when the service degrades, not because we ask them to, but because that is who they are."
The second version is longer, riskier, and more honest. It will attract fewer applicants. It will attract significantly more of the right ones — because it describes a real situation, not an aspiration. Senior engineers want to know what they are walking into. Junior candidates who are not ready for that level of ownership will correctly self-select out.
The single most important structural change: separate requirements from nice-to-haves
Most job descriptions list everything under "Requirements" — which means candidates have to guess which items are genuine dealbreakers and which are preferences. This has a well-documented effect on applicant diversity: research consistently shows that underrepresented groups (particularly women) tend to apply only when they meet every listed requirement, while overrepresented groups apply when they meet roughly 60% of the criteria.
The practical consequence is that your requirements list is a filter, whether you intend it or not. Every item on it costs you some applicants. Items that are genuinely required (without which the person cannot do the job at all) belong there. Items that would be helpful but are learnable on the job do not.
The structural fix is simple: two separate sections, clearly labelled. "What you need" (true requirements) and "Useful but not essential" (genuine nice-to-haves). This expands your qualified applicant pool, makes your requirements more credible (because they are actually required), and signals that you have thought carefully about what the role genuinely needs.
Write the "why join us" section like you mean it
Most companies write the same "why join us" section: "competitive salary, flexible working, collaborative culture, opportunity for growth, great team". These phrases mean nothing — every company says them, which means they communicate nothing distinctive about yours.
The candidate reading this section is asking a specific question: "Why would I choose this company and this role over the other options I have?" Generic phrases do not answer that question. Specific, honest, distinctive answers do.
Consider: what genuinely makes your team different? What is the real state of the product or codebase they will inherit? What does the best person in this role tend to go on to do? What is unusual or genuinely appealing about how you work? A sentence that only you could write is worth ten generic bullet points.
One example of a "why join us" that actually works: "You will inherit a codebase that has 12 years of technical debt and a team that is fully committed to paying it down — 20% of every sprint is reserved for it. If you want to own that project, this is your role." That is specific, honest, and self-selecting.
Salary transparency and why it matters
Job postings that include a salary range receive, on average, 30% more applications than those that do not — and a higher proportion of qualified ones, because candidates who are a poor salary fit self-select out early rather than wasting everyone's time in the process.
The most common objection to salary transparency is that it limits negotiation leverage. This argument has weakened considerably as salary transparency legislation has expanded in several US states and sectors, and as candidates increasingly share and discuss compensation data through platforms like Levels.fyi, Glassdoor, and community Slack groups. Your internal pay data is less confidential than it was five years ago.
The practical argument is simpler: nothing is more demoralising for a candidate — or more damaging to your employer brand — than reaching the final stage of a process only to discover the salary is 30% below their expectation. Publishing a range prevents this entirely.
The language of inclusion
Job description language affects who applies. Certain words and phrases have been shown to deter female applicants (the classic examples: "aggressive", "dominant", "strong" as descriptors, combined with competitive or sports metaphors). Other language deters candidates who are non-native English speakers, or who did not follow a traditional career path.
The practical approach is not to audit every word for potential bias — that way lies paralysis. It is to ask: is every requirement genuinely required? Is every phrase describing the work, or describing a type of person? And is the overall tone of the posting one where a wide range of qualified people would recognise themselves as a potential fit?
Simple changes make a significant difference: replace "ninja" with the actual skill, replace "strong communication skills" with a description of the actual communication the role requires (e.g. "presenting monthly to the senior leadership team"), and replace "passionate" with something that can be evidenced in an interview.