A job opening often starts failing before the first candidate ever sees it. It happens the moment someone opens a blank document, pastes a list of technologies and hits publish. Then dozens of applications arrive that don't fit, the team gets frustrated, and the usual conclusion is "there's no talent out there". My experience as a recruiter tells me something different: very often the talent is there, but the job description isn't speaking to it.
A job description is the first conversation you have with a candidate, even if you're not in the room. In this article I share how I work on it with my clients, and what I change when an opening isn't attracting the right people.
The most common mistake: not explaining the project
If I had to pick just one mistake, it would be this one. Most job descriptions I receive say which technologies the company uses, but they don't say what the person will build or why it matters.
For an experienced tech professional, "Java, Spring Boot, AWS and microservices" describes tools, not a job. What really helps them decide whether to apply is understanding the context:
- What product or platform will they build or maintain?
- Is it a new project, a migration, or a platform that needs to scale?
- What business problem does their work solve?
- What will they own in the first few months?
The best candidates usually have several options. Between two openings with the same stack, they will choose the one that tells a clearer story about their future work.
When I rewrite a job description, the first paragraph always answers three questions:
- Context: what the company and the team do.
- Mission: what this person will do and own.
- Impact: how their work connects to business goals.
If someone reads only that paragraph, they should already be able to say "this is for me" or "this isn't for me". Both answers save you time.
The first thing I change when an opening isn't working: the requirements
When a search isn't bringing in good profiles, my first adjustment is almost always to cut down the requirements.
Long lists have a curious effect. Highly experienced people, especially those who are rigorous about their own profile, tend not to apply if they don't meet every point. Meanwhile, others apply anyway while meeting almost none. The endless list ends up filtering out exactly the people you shouldn't lose.
Must-have versus nice-to-have
With my clients, I ask one simple question for each requirement: would you reject an excellent candidate for not having this?
- If the answer is yes, it's a must-have.
- If the answer is "no, they could learn it", it's a nice-to-have.
Ideally, the must-haves fit in five or six lines. Everything else can go in a separate list with a clear message: "if you don't tick every box, we still want to meet you".
Be precise about the technical side
"Cloud experience" says very little. "Experience deploying and monitoring services on AWS" tells the candidate exactly what you expect. The same goes for seniority: instead of asking only for years of experience, describe the decisions the person will make. Will they define the architecture? Will they lead other developers? Will they work with a lot of autonomy?
Four things I always ask clients to include
Some information is essential for candidates to make a decision, and when it's missing, it creates distrust or applications that go nowhere. That's why I ask my clients to always include these four points.
1. Salary range
Even if it's approximate. Publishing the range avoids losing weeks with candidates whose expectations have nothing to do with the budget, and it signals transparency. A candidate who sees the range and applies already knows where they stand.
2. Work model and location
Is the role remote, hybrid or on-site? If it's remote, which countries can you hire from, and which time zone does the team work in? This is key when we recruit Latin American talent for companies in the United States and Canada: "remote" can mean very different things.
3. The interview process
How many interviews there will be, with whom, and whether there is a technical assessment. A predictable process improves the candidate experience and reduces drop-off halfway through. It also shows that the company got organized before starting the search.
4. The real stack and team
Who the person will work with, how big the team is, which tools they use day to day and how they deliver their work. Not the ideal list of technologies, but the one actually in use today.
Write for people, not for a system
A good job description reads like an invitation, not like a form. A few details make a difference:
- Use inclusive language and avoid internal jargon or acronyms that only make sense inside the company.
- Use the job title professionals actually search for. A creative title can mean nobody finds the opening.
- Speak directly to the reader: "you will lead…", "you'll work with…". It helps candidates picture themselves in the role.
Make your opening easy to find
If you post openings on your own website, structured data helps search engines like Google understand them and display them better. Google documents the format in its guide on job posting structured data (see sources).
Checklist before publishing
- The first paragraph explains the project, the mission and the impact of the role.
- The must-haves fit in five or six lines.
- Nice-to-haves are separate and don't scare people away.
- The salary range is included.
- Work model, location and time zone are explicit.
- The interview process is described.
- It's clear who the person will work with and which tools they'll use.
- The language is clear, inclusive and free of internal jargon.
A job description like this doesn't just attract more candidates: it attracts the right ones, and saves the whole process weeks.
Do you have a hard-to-fill tech role? Tell us what you need and let's define it together. You may also like what great hiring managers do differently.