Hiring guide
How to Write a Technical Job Description That Converts
A technical job description has two jobs to do. It needs to rank well enough that the right engineers find it, and it needs to convert once they arrive, meaning they read it, understand the role, and apply. Most job descriptions do neither well. They are written for internal sign-off rather than for the person who might take the job.
Why most technical job descriptions fail
The usual pattern is a long list of responsibilities copied from an old template, a wish list of tools and frameworks, and no mention of salary. Good engineers skim this in under a minute and move on. They are not being fussy. They are pattern-matching against dozens of similar postings and looking for the one that reads like it was written by someone who understands the role, not just the job title.
If you are hiring for a specific stack, such as TypeScript developers, Node.js developers or Python developers, the description needs to reflect how that stack is actually used in your business, not a generic list of buzzwords.
Structure that works
A technical job description should follow a predictable order, because predictability helps candidates find what they need quickly:
- What the team is building. One or two sentences on the product and the problem, not the company mission statement.
- What the person will actually do. Three to five concrete responsibilities, not twelve vague ones.
- What they need to succeed. A short list of genuinely essential skills, separate from anything that is nice to have.
- How the team works. Remote, hybrid or office, team size, how decisions get made, what the stack looks like.
- Salary and benefits. Covered in more detail below.
- The process. How many stages, roughly how long, and who the candidate will meet.
This structure works whether you are hiring software engineers, DevOps engineers or data engineers. The content changes, the shape should not.
Keywords that matter
Ranking matters because most candidates find roles through search, whether that is a job board, LinkedIn or Google. Use the actual job title candidates search for, not an internal invented one. If the role is a backend engineer, call it that, not a “software craftsperson”. Mention the core language or framework in the first two paragraphs, not buried in a bullet list at the bottom. If the role sits within a specific sector, such as fintech or AI and data, say so early, because sector experience is often a genuine filter candidates search on.
Salary transparency
This is where most technical job descriptions lose good candidates before they even open the ad. “Competitive salary” reads as a warning sign to experienced engineers, who assume it means the range is below market or that there is no clarity internally on the budget. You do not need to publish an exact number, but a realistic band signals that the role has been thought through. If you are unsure what a realistic band looks like, our salary benchmarks and UK tech salary statistics pages are a useful starting point, and the UK Tech Salary Report 2026 covers this in more depth across roles and regions, including London.
What puts candidates off
Beyond salary, the most common problems are long lists of “nice to have” skills that read as requirements, jargon that does not match how the role is actually described in the market, and no information on the interview process. Candidates who do not know whether they are facing one call or five take-home tests will often deprioritise the role, no matter how good it looks otherwise. Our free job description checker flags all three, along with a missing salary or working model, before the ad goes live.
How we help
At OpenSource, every candidate is technically screened by the founders before a client meets them, which means we see first-hand which job descriptions attract strong engineers and which ones do not. Whether you need help through contingent recruitment, retained search or an embedded model through RPO, we can help you write a technical job description that works, and support the hire from there. Explore our full range of services and our approach to software engineering recruitment, or get in touch to talk through a specific role.
FAQ
Frequently asked questions
How long should a technical job description be?
Long enough to be useful, short enough to be read. Most good technical job descriptions run to 400-600 words, with a clear structure rather than a long list of requirements. If candidates need to scroll for three minutes to find the salary, the description is too long.
Should we always include a salary range?
Yes, in some form. You do not need to publish an exact figure if that is not possible internally, but a realistic band or a clear statement of the range is expected by most candidates now. Vague statements like 'competitive salary' put off strong applicants who assume it means below market.
How many 'must have' skills should we list?
Keep it to the three or four things that genuinely determine whether someone can do the job. Long wish lists of tools and frameworks put off good candidates who would learn the rest quickly, and they rarely reflect what the role actually needs day to day.
Who should write the technical job description, the founder or a recruiter?
Ideally both. The founder or hiring manager should define what the person will actually do and what good looks like, and a recruiter who understands the market can help with structure, phrasing and realistic expectations on salary and seniority.