How to write a developer job description that gets replies
A job description is the first thing a developer reads about you — and most of them stop reading fast. Engineers are used to being spammed with vague, buzzword-heavy adverts for 'rockstar ninjas' at 'fast-paced, dynamic' companies, so a spec that's specific, honest and respectful of their time stands out immediately.
The goal isn't to list every requirement you can imagine; it's to help the right person picture themselves doing the work and decide it's worth replying. Here's what actually moves the needle.
Lead with the work, not the company boilerplate
Most developers skip the 'about us' paragraph entirely. Open instead with what they'll actually build: the product, the problems you're solving, the systems they'll own, and the stack they'll use. Concrete beats generic every time — 'you'll own our payments service, currently handling 2m transactions a month' tells a candidate far more than 'exciting opportunity in a growing team'.
If your company genuinely has a hook — an interesting technical challenge, unusual scale, a mission people care about — lead with that. If it doesn't, don't fake one; engineers have finely tuned detectors for filler and it costs you credibility.
Put the salary in — really
Nothing improves the quality and quantity of applications like a real salary range. Developers overwhelmingly filter out roles that hide pay, because a missing number reads as either 'we'll lowball you' or 'we don't know what this role is worth'. Adverts with transparent salaries consistently get more, and more relevant, applicants.
Give a genuine range you'd actually pay, not a token £40k–£90k that spans three seniority levels. If your range is wide for a reason (you'll flex the title to the person), say so. Transparency up front also saves everyone the wasted final-stage conversation where expectations don't meet.
Be specific about the stack — and honest about the mess
List the actual technologies the person will work with, and clearly separate must-haves from nice-to-haves. A React developer wants to know if it's React with TypeScript or a legacy class-component codebase; a backend engineer wants to know if 'we use microservices' means a clean platform or a distributed monolith held together with hope.
It's fine — good, even — to be honest about the realities: legacy code, technical debt, an on-call rota, a migration in progress. Naming them filters for people who are comfortable with that reality and won't feel misled in week two. Honesty is a feature, not a risk.
Cut the requirements list in half
Long lists of 'essential' requirements actively deter strong candidates. Well-qualified people — and under-represented groups especially — tend to self-select out if they don't tick every box, so a fifteen-line must-have list quietly filters out exactly the people you'd want. Pick the handful of things that genuinely matter and move the rest to 'bonus'.
Be wary of proxy requirements too. 'Five years of X' rarely predicts ability as well as you think, and rigid year-counts screen out career-changers and fast learners. Describe the level of responsibility and the problems they'll handle instead — that's what actually maps to seniority.
Make remote, pay-frequency and the process crystal clear
State the location and remote policy precisely — 'hybrid' means wildly different things to different companies, and ambiguity loses people at the top of the funnel. Say how many days in the office, from where, and whether that's negotiable.
Finally, outline the interview process and roughly how long it takes. Developers are evaluating you as much as you're evaluating them, and a clear, humane process — 'a 30-minute intro, a take-home or pairing session, a final team chat, decision within a week' — signals a company that respects their time. If writing all this from scratch feels like a chore, that's partly why we built the platform: upload a rough job description and Get Me A Techie drafts a clean, anonymised advert for you to edit — see how it works for companies.
Frequently asked questions
Should I include a salary range in a developer job advert?
Yes. Transparent salary ranges reliably increase both the number and the relevance of applications, and hiding pay signals to engineers that you'll lowball or that the role is poorly defined. Give a genuine range you'd actually pay.
How long should a developer job description be?
Long enough to describe the work honestly, short enough to scan in a couple of minutes. Lead with what they'll build, keep the requirements list tight, and cut the generic company boilerplate.
Do I need to list every technology we use?
No — list what the person will actually work with and separate must-haves from nice-to-haves. A short, honest stack (including the legacy bits) filters for fit far better than an exhaustive wishlist.
Tech recruitment without the noise
Free to join for techies and companies. Anonymous until it matters, and a flat 10% only when a hire actually happens.