How to write a job description that attracts senior tech profiles
Think about the last time you forwarded a job ad to a senior engineer you know. They probably opened it on their phone between meetings, with no intention of changing jobs, and gave it a minute at most. In that minute they were trying to answer one question: is this better than what I’ve already got?
Very few job descriptions help them answer it. What we usually receive when a company sends us its ad is a list of requirements inherited from the last search, a couple of paragraphs about the mission and very little about the actual work. A senior candidate reads that and moves on.
Lead with the problem you need solving
If the ad opens with the company’s history, you’ve already spent your minute. Someone experienced wants to know what’s happening in the team and why you need a person now. Two or three sentences are enough: what you’re building, what challenge made you open the role, and what will be different if the new hire does it well.
For example: “We’re breaking a monolith into independent services while still shipping product every week. We need someone to lead that transition without slowing the team down.” That line filters better than any “we’re looking for someone passionate about technology”, and it draws in exactly the people who’d enjoy that kind of challenge.
Fewer requirements, chosen with care
Long requirement lists have a perverse effect that we see all the time. The people who fit best tend to be hard on themselves and rule themselves out if they don’t tick every box. People who don’t fit apply anyway.
Before you write a word, sit down with the team and separate what is genuinely needed to do the job in the first quarter (usually no more than three to five things) from what helps but can be learnt. While you’re at it, strike out the requirements someone added years ago that nobody is ever going to assess.
Be especially wary of years of experience. “Eight-plus years of React” measures tenure, not ability. You’ll get further by describing the level of responsibility you expect: “you’ve designed the frontend architecture of a product in production and made decisions that have held up over time”.
Show what the team is like from the inside
Who they’ll work with and how the team operates matter as much as the role itself. This is the part most often missing, and the one that raises the most questions later in interviews. It’s worth including:
- Team size, make-up and who the role reports to.
- The current stack, the technical decisions still open and the technical debt you already know about.
- Who sets priorities and how much day-to-day autonomy there is.
- Release cadence, on-call and standing meetings.
Don’t be afraid to mention what isn’t solved yet. Senior people know no company is perfect. What makes them wary is surprises, and an ad that admits its own weak spots earns a lot of trust.
They’ll also want to know where the role can lead. Is it an individual contributor position with technical influence, or is there a route into managing people? What happened to the last person in a similar role? You don’t need to promise anything. Just be realistic.
Put the salary in
Publishing a salary range saves everyone time and stops you losing a finalist in the last conversation. There’s a legal reason too. The EU Pay Transparency Directive (Directive (EU) 2023/970) had to be transposed by June 2026, and it includes an obligation to tell candidates the starting pay or its range. The exact scope depends on how each country implements it, so check with an employment lawyer.
Alongside pay, describe the working set-up as it really is (how many office days, how flexible the hours are, which countries people can work from), any bonus or equity and how it works, and whether there’s a budget for training or conferences.
Mind how it sounds
Some writing habits put candidates off without you noticing. Internal jargon is the first: team names or in-house tools that mean nothing outside the company. Then there are clichés like “ninja”, “rockstar” or “fast-paced environment”, which say little and sometimes say exactly what you didn’t mean. “Works well under pressure”, for instance, tends to read as “expect long hours”.
Check that the text speaks to any qualified person, whatever their gender or background. And keep an eye on length. If the ad doesn’t fit on two or three phone screens, something can probably go.
Explain the process before they ask
Someone who isn’t looking wants to know what the process will cost them before agreeing to a first call. Say how many stages there are, what each one looks at, whether there’s a technical exercise and what kind, and how quickly you’ll get back to people. It’s easy information to give, and it tells candidates the company has its house in order.
If you’d like a skeleton to start from, this order works well for us:
- The challenge, in two or three sentences.
- What the person will do in their first months.
- Who they’ll work with.
- What’s needed and what’s a bonus.
- Salary, working set-up and conditions.
- What the process looks like.
Before you hit publish
Find someone in the team with a profile close to the one you’re hiring for and hand them the draft with two questions: would you apply? And what’s missing? It’s the most useful review you’ll get, and it takes ten minutes.
Just don’t expect the ad to do all the work. Most senior people won’t come across it on their own, but anyone you approach will read it before replying. That’s why at Mimmic Talent we like to write it together with the company, straight from the briefing. If you’d like us to look over yours, get in touch.