The technical job description is the first thing most candidates will ever see from your company. It runs before the recruiter call, before the employer brand content, before anyone at your company has said a single word to them. It is the document that determines whether the engineers you want to hire ever enter your […]
The technical job description is the first thing most candidates will ever see from your company. It runs before the recruiter call, before the employer brand content, before anyone at your company has said a single word to them. It is the document that determines whether the engineers you want to hire ever enter your process at all.
And yet most technical job descriptions are written in under an hour, adapted from a previous version, reviewed briefly by HR and the hiring manager, and posted with minimal thought given to how they will actually read to the person you are trying to attract. They are not written to recruit. They are written to document a requirement that already exists in someone’s head.
There is a better approach. It does not take significantly more time. It takes different time — a couple of hours of structured thinking at the beginning of the search rather than a chaotic scramble two weeks in when no strong candidates have applied. This guide walks through it step by step, with the goal of producing a job description that actually works when hiring technical talent — one that attracts the right people, discourages the wrong ones, and makes a clear case for why this role is worth a senior engineer’s serious consideration.
Before you write a single word, get specific about the person who should be reading this document. Not “a senior backend engineer” — that is a job title, not a person. Who specifically are you trying to reach?
What is their career stage? Are they four years into a technical career, looking for their first senior role? Eight years in, currently a senior engineer at a mid-size company, looking for a role with more ownership? A principal engineer at a large organisation who wants to work at a smaller scale where their impact is more visible?
What motivates them right now? Are they looking for better compensation, a more interesting technical challenge, more autonomy, a better team culture, a cleaner codebase, more opportunities to learn? These motivations vary significantly by career stage and personal context, and a job description that speaks to one profile will not resonate with another.
What would make them click past your listing? A requirements list with eleven items. The phrase “10+ years of experience required” for a role that could be done well by someone with four. Generic language about culture. The absence of any salary information. All of these are signals to experienced technical candidates that the listing was not written with them in mind — and if the listing was not written with them in mind, neither was the role.
Spend ten minutes writing a one-paragraph profile of the specific person you are trying to reach. Keep it visible while you write the rest of the description. Every choice you make should be evaluated against whether it will resonate with that person or push them away.
Most technical job descriptions open with a list of responsibilities or requirements. This is backwards. Requirements are the price of admission. Before you list the price, you need to give the candidate a reason to want to pay it.
Open with context. Two to three paragraphs that explain what the company is building, what the engineering challenge is, and what specific problem this role is solving. Be specific. “We are scaling our data pipeline to handle ten million events per day and our current architecture is hitting its limits” is a context that will interest the right engineer immediately. “We are a fast-growing company looking for a data engineer to join our team” is a context that tells the candidate nothing they could not have inferred.
The context section should answer three questions for the candidate: What is the interesting problem here? Why does it matter? Why is it hard enough to be worth working on? If you cannot answer those questions in two or three honest paragraphs, the answer is usually that you have not thought carefully enough about what makes this role genuinely interesting. That is worth fixing before you post anything.
The single most impactful structural change you can make to a technical job description when hiring technical talent is to split your requirements into two clearly labeled lists: things the person must have on day one, and things that would be helpful but can be learned or are not essential.
The must-have list should contain three to five items. Maximum. These are the things that, without them, the candidate cannot do the core functions of the role. Not “five years of experience with Python” — unless the system is entirely in Python and there is no room to use anything else, that is a preference, not a requirement. “Demonstrable experience building and maintaining REST APIs at production scale” is a requirement. “Strong understanding of data consistency models in distributed systems” is a requirement. Keep this list honest and short.
The nice-to-have list can be longer. Put everything that would be beneficial but is not a gate there: familiarity with specific secondary tools, experience in specific industries, knowledge of a particular framework that your team could easily bring someone up to speed on. Framing these as preferences rather than requirements is not a lowering of standards. It is an accurate description of what is actually required, which allows stronger candidates who have everything on the short list to apply without feeling underqualified because they do not have everything on the long one.
The team description section is consistently the most generic part of most technical job descriptions. “You will work with a talented, collaborative team of engineers.” This describes every engineering team in every job description ever written. It tells the candidate nothing.
Describe the team specifically when hiring technical talent. How many engineers? What are their seniority levels? How does the team make decisions about architecture and tooling? Is there a strong culture of code review? Does engineering have a strong voice in product decisions, or does product drive and engineering deliver? Are there regular technical talks, brown bag sessions, or structured learning time? What does onboarding typically look like?
None of these details are confidential. All of them help the candidate assess whether this is an environment where they will thrive. Senior engineers in particular pay close attention to how a team is described — not just what is said but what is emphasised. A team description that focuses on process and craft signals something different from one that focuses on velocity and delivery, and the candidates who want those different things will sort themselves accordingly.
Include a salary range. If your organisation has a policy against this, push back on the policy. The cost of not including a salary range is that candidates assume the worst, apply anyway, discover in the third conversation that the range does not match their expectations, and leave the process. You have wasted their time and yours.
Including a range does not mean losing negotiation leverage. It means filtering out candidates whose expectations are outside your range before they spend hours going through your process, and attracting candidates who are comfortable with the range but might not have applied otherwise. It is a net efficiency gain in every case.
Be equally specific about the working model. “Hybrid” means different things to different companies and different candidates. Specify the expectation: two days per week in office, three days remote, with location in [city]. Or fully remote, with quarterly in-person gatherings in [location]. Or on-site five days a week with flexibility for occasional remote days. Specificity here is not restrictive — it is respectful of candidates’ time and circumstances.
End the job description with two things: a clear description of what happens after someone applies, and something genuine about why this is a good place to work.
The process description should be specific. “After you apply, you will hear from us within five working days. If there is a fit, we will schedule a fifteen-minute introductory call, followed by a technical conversation and a team meeting. The full process takes two to three weeks.” This level of transparency is uncommon and, for that reason, stands out. It signals that you have thought about the candidate experience and that you take their time seriously.
The genuine close is harder to write and more important than most organisations realise. Do not end with another list of benefits. End with a specific, honest answer to the question every candidate is implicitly asking: why would a good engineer choose this company over the other three offers they are considering?
The answer to that question might be the quality of the technical problem. It might be the team composition. It might be the stage of the company and the impact an individual engineer can have. It might be the engineering culture or the way decisions get made. Whatever it is, say it specifically and honestly. If you cannot identify a compelling answer to that question, that is worth knowing before you post the role — because candidates will form their own answer from what they read, and generic language will produce a generic answer.
Before you post, send the description to one senior engineer whose judgment you trust — ideally someone in the role you are hiring for or directly adjacent to it. Ask them one question: “If you were exploring your options right now, would this make you want to find out more?”
Their answer will tell you more than any checklist. Pay attention not just to yes or no but to what they say next. If they say “yes, but I would want to know about X,” add X. If they say “I’d be put off by the requirement for Y,” evaluate whether Y is actually necessary. If they say “it reads like every other job description I’ve seen this month,” start over with a clearer sense of what makes this role different.
This review step takes thirty minutes and has an outsized impact on the quality of candidates who apply. It is the cheapest signal available that your job description is going to work when hiring technical talent — and the one most often skipped.