How to write a job description that great engineers actually read

If you have ever opened a job description for a senior engineering role and felt your eyes glaze over within fifteen seconds, congratulations, you are reacting exactly the way the candidate you want to hire reacted yesterday.

Job descriptions are the most undervalued asset in your hiring funnel. They are the first thing a candidate reads, the first thing your sourcer references, the first thing that signals whether you are a serious place to work. And in 2026, with engineers receiving five to fifteen recruiter messages a week, the bar for “worth replying to” has never been higher.

After writing or rewriting hundreds of job descriptions over the last fifteen years, the pattern that separates the ones that pull strong candidates in from the ones that bounce them is almost always the same. This is what we have learned, and what we use when we sit down to scope a role with a hiring manager.

The job description is a filter, not a magnet

Most companies treat the JD like a contract. They list responsibilities, list requirements, list “nice to haves,” sign off, and post. The result is a document optimized for HR review, legal review, and consistency with other postings inside the company. None of those audiences are the audience that matters.

Strong engineers read a job description the same way they read a pull request. They scan for signal. They are looking for a few specific things: is the work actually interesting, will I work with people I respect, and is the company serious enough to scope this role properly. Everything else is noise.

The default JD template fails on all three. Responsibility lists describe motion, not impact. Requirement lists describe filters, not the bar. Generic culture statements describe aspiration, not reality. By the time the strong candidate hits “competitive comp and great benefits,” they have already moved on.

When we plot the JDs we have rewritten over the last few years against the JDs they replaced, the pattern lands in one of four places:

quadrantChart
  title What kind of JD did you write?
  x-axis "Generic" --> "Specific"
  y-axis "Boring" --> "Hooky"
  quadrant-1 Converts top candidates
  quadrant-2 Reads as marketing
  quadrant-3 Ignored
  quadrant-4 Tolerable for active only
  Default JD template: [0.18, 0.22]
  Comp posted, no story: [0.72, 0.28]
  Vibey but vague: [0.28, 0.78]
  Specific and hooky: [0.85, 0.86]

What good engineers actually scan for

When we test JDs with engineers we trust, three signals consistently determine whether they keep reading.

The problem. Not the role, the problem. “We are hiring an SRE because our incident response time is four times our SLA and we cannot ship faster until that changes” beats “Maintain reliability of production systems” every time. A candidate reading the first version immediately knows the work is real, the problem is concrete, and the company has thought about it. Reading the second, they know nothing.

The team shape. Who would I be working with, and who would I be reporting to. Strong engineers care a lot about this. A two-line answer (“You would join a team of six platform engineers reporting to Alex, our Director of Infrastructure, who came from Stripe”) tells a candidate more than three paragraphs of “collaborative culture” boilerplate.

The why now. Why is this role open today. Did the team double in headcount last quarter. Did you just close a Series B. Did your last platform lead leave to start a company. Candidates read context as a maturity signal. A company that knows why it is hiring is a company that has thought about the role.

If your JD does not give a candidate clear answers to those three questions in the first three paragraphs, you have lost most of the strong ones before they hit the requirements section.

Five lines that quietly tank your funnel

We see the same job description anti-patterns over and over. None of them are dealbreakers in isolation. All of them, in combination, signal a company that has not done the work.

1. “Years of experience” minimums that exceed the actual need. If you write “8+ years” because the head of engineering has eight years, you have just filtered out the strongest mid-level engineers in the market, who are usually the ones with the most upside. Arbitrary year counts also disproportionately filter out underrepresented candidates: a widely cited Hewlett-Packard study referenced by Harvard Business Review found that women apply only when they meet 100% of listed criteria, while men apply at 60%. Pick a real bar. “You have shipped a service to production at scale” is a better filter than a year count, and LinkedIn’s research on skills-based hiring suggests skills-led searches are meaningfully more likely to surface a successful hire.

2. A 14-bullet “responsibilities” list. Nobody reads bullets six through fourteen. If your role really needs fourteen responsibilities, you have at least two roles, or you have not scoped this one yet.

3. A 12-bullet “requirements” list. Same problem, with the added cost of scaring off candidates who could do the job but lack three of the listed technologies. The strongest engineers we know rarely match every bullet on a real requirements list. They self-select out, and your funnel narrows to candidates who are either confident bordering on overconfident, or who match because the bar is too low.

4. Buzzword stacking instead of stack honesty. “Distributed systems, Kubernetes, microservices, observability, scale” listed without context tells a candidate that the JD was written by someone who has not touched the codebase in two years. If you actually run on Kubernetes, say what you run on it and at what scale. If you do not, do not list it.

5. Comp listed as “competitive.” This is the single biggest unforced error in modern JDs. Strong candidates have offers. They are not going to spend forty-five minutes on a screen call to find out you are 30% below market. Indeed’s Hiring Lab reports that postings with employer-provided salary information receive roughly 3.8x more applications than those without, and LinkedIn’s own data shows that 91% of applicants say a posted salary range affects whether they apply. Either post the band, or be ready to share it on the first conversation. Hiding it costs you more than disclosing it ever has.

If you boil all five down, the underlying pattern is the same: every line in a JD either earns the candidate’s attention or burns it. The table below is the cheat sheet we use when we sit down to rewrite one.

The shape of a description that converts

Here is the structure we use when we rewrite a JD with a hiring manager. It is not a template you fill in. It is a shape that forces clarity.

Opening (one paragraph, three to five sentences). What does the company do, what stage are you at, and what is the headline reason this role is open right now. Specific is better than aspirational.

The work (two paragraphs). What will this person actually do in the first ninety days, then in the first year. Reference real projects, real systems, real problems the team is currently grappling with. This is where the role comes alive.

The team (one paragraph). Who are the four or five people they will work most closely with. Where did they come from. What is the manager’s background. Hiring is a relationship business, and engineers want to know whose Slack messages they will be reading every day.

What we look for (one short list, five items maximum). Not requirements. Not “nice to haves.” A real bar, written as outcomes. “You have built and operated a service that handled millions of requests per day.” “You have led the technical direction of a team of three or more engineers.” Five items, each one substantial.

What we offer (clear, specific, listed). Comp band. Equity range. Remote or hybrid policy. Benefits worth highlighting. PTO. Skip the platitudes, list the facts.

One paragraph about why this role exists. This is the section every JD skips, and it is the section that converts. Why is this role on the team. What changes when this person joins. What is the team trying to become.

A short call to action. “If this sounds like the kind of work you want to be doing, send a paragraph about something you have built and we will set up a call within a week.”

That is the entire JD. It is usually 450 to 650 words. It does not need bullet lists with thirty entries. It does not need a paragraph of legal copy at the bottom. It needs to be specific, honest, and short.

Comp transparency, briefly

A note on comp, because it is the question we get most often.

Posting a comp band has three concrete effects. It filters out candidates who are above your range before either side wastes a screen call, it builds trust with everyone who hits “apply” because they know you are not playing games, and it forces internal alignment because you cannot post a band you have not yet agreed on. All three effects are net positive for the hiring team. Indeed’s data goes further: roughly 38% of workers say they will abandon an application entirely if no salary range is disclosed.

The argument against posting (we will lose negotiation leverage) is something the strongest candidates reason in reverse. If you are willing to obscure your range, what else are you willing to obscure. The candidates who care most about negotiation leverage are also the candidates who notice signal asymmetry first.

Just post the band. The cost of disclosure is almost always lower than the cost of the calls you would have had with mismatched candidates.

The cost of getting this wrong

Companies tend to underestimate how expensive a bad JD actually is, because the cost shows up in pieces and lands on different teams.

Your sourcer spends twice as long on outreach because they have to translate a dense, generic JD into a coherent pitch in every cold message. The candidates who do reply ask the same five clarifying questions on every screen, because the JD did not answer them. Hiring managers spend their first thirty minutes of every call repeating context. The recruiter ends up running interference between candidate confusion and team frustration. None of that time goes onto the time-to-fill spreadsheet, but it is real, and it compounds.

The strongest signal we see in companies that hire well is that the hiring manager and the recruiter co-write the JD together, in one sitting, before the role is posted. They stop trying to make the document neutral. They make it specific. The recruiter pushes back when the manager hand-waves a requirement. The manager pushes back when the recruiter softens an outcome. The result is a document that both of them can stand behind in any conversation, and the rest of the funnel runs faster as a consequence.

A good JD does not just attract candidates. It makes every downstream step easier, because the entire team is suddenly aligned on the same picture of the role. That alignment is the actual asset. The document is just the artifact.

What this looks like in practice

We worked with a client last quarter who had been trying to hire a Staff Backend Engineer for five months. Their original JD had eleven bullets in responsibilities, fourteen in requirements, and “competitive comp” at the bottom. They had three onsites in five months, none converted.

We rewrote the JD. Six paragraphs, no bullet walls, comp band posted, specific reference to two ongoing projects the role would lead, two named people the candidate would work with, and one paragraph explaining why the company was hiring a Staff role for the first time. Same role, same comp, different document.

Three weeks later they had four onsites and an accepted offer.

The candidates were always there. The signal was missing.

If you take one thing from this, take this: every word in your JD is real estate that a strong engineer is silently grading. Use it to be specific, honest, and a little bit interesting. The hires follow.