How to write an engineering job description that converts

An engineering job description converts when it leads with the actual work in the first three lines and names a comp band a candidate can decide on. Everything else (the perks list, the company mission paragraph, the wall of required skills) lowers your reply rate. A senior engineer reads the top of your post for about 15 seconds before deciding whether to keep going, and most posts spend those 15 seconds on the company instead of the job.

This is the founder companion to the posts senior engineers actually read. That piece is about the writing voice. This one is about structure: what to include, what to cut, where the comp band goes, and how long the whole thing should be. We pull every role on the board straight from a company's own job site, so we read thousands of these. The good ones share a shape.

What does a job description need to do?

It has one job: get the right person to reply, and give the wrong person enough information to opt out. Both halves matter. A post that is vague enough to attract everyone wastes your loop on mismatches. A senior engineer who is already employed (which is most of the good ones) will not apply to decode what the role actually is. They will close the tab.

So the description is a filter and a pitch at the same time. The filter is the work and the comp. The pitch is the specificity: a precise post signals a team that knows what it is building, which is the single most attractive thing to a strong engineer.

What to lead with

Lead with the work. Not the mission, not the funding, not the values. The first thing on the page should be a concrete description of what this person will build in their first 6 months.

Compare these two openings for the same role.

The right column does three things the left cannot. It names a real problem (the cron miscounts), which signals an honest team. It names the stack, so an engineer can self-select in or out. And it names a band, so nobody wastes a loop discovering you are $40,000 apart.

Should you put the salary band in the post?

Yes. This is the highest-leverage change most founders can make, and the one they resist most. A named band raises your reply rate from qualified candidates and cuts the time you spend on people you cannot afford. In several US states and cities (including New York and parts of California) a band is required by law for roles based there, so for many startups the question is already settled.

The objection is usually that a band ties your hands in negotiation. It does the opposite. A band of $180,000 to $215,000 anchors the conversation inside a range you have already decided you can pay. Without it, a strong candidate assumes the worst, or assumes too much, and either way you meet at the wrong number after three calls. Put the band in. Keep it honest, and keep the spread under about 20 percent, because a band from $140,000 to $240,000 reads as "we have no idea," which is its own red flag.

What to cut

Most engineering job descriptions are twice as long as they should be because they include things that convert nobody. Cut these first.

• The 12-item requirements list. Three or four real requirements is plenty. If you list 12, strong candidates who have 9 of them assume they are unqualified and do not apply. The 12-item list filters out the people you want and lets through the people who ignore lists.
• "Nice to have" sections. They are noise. If it matters, it is a requirement. If it does not, leave it out.
• Generic perks. Health insurance and a laptop are table stakes, not selling points. Listing them signals you think they are special.
• The mission paragraph at the top. Mission belongs near the bottom, after the work. An engineer who likes the work will read the mission. One who reads the mission first rarely gets to the work.
• Years-of-experience minimums as a proxy for level. "8+ years" screens out a brilliant engineer 5 years in and screens in a coaster with 8. Describe the scope of the work instead. The level becomes obvious.
• Buzzwords. "Rockstar," "ninja," "wear many hats," "hit the ground running." Each one lowers trust with the exact senior people you are trying to reach.

What to keep

A converting engineering job description is short and has roughly this skeleton. Aim for 250 to 400 words total, which is one screen on a laptop.

1. 01The work, first. Two or three sentences on what this person owns and the first real problem they would solve. Concrete, with a stack.
2. 02The comp band and equity range. Numerals, honest, a spread under 20 percent.
3. 03Three or four real requirements. The things that are actually non-negotiable, written as scope, not years.
4. 04Team and reporting. Who they work with, how big the eng team is, who they report to. Two sentences.
5. 05Stage and funding. One line: how recently you raised and what stage. This is the signal candidates weigh most, and you can see why on why funding recency is the best hiring signal.
6. 06Location and remote policy. Onsite, hybrid, or remote, and which city. One line, no ambiguity.
7. 07Mission and company, last. Now the candidate is bought in enough to care.

How long should an engineering job description be?

Shorter than you think. The posts that convert best run 250 to 400 words. Past about 500 words, every extra paragraph costs you readers without adding qualified applicants. A senior engineer is reading on a phone between meetings. If they have to scroll three times before they learn what they would build, you have lost them.

A worked before and after

Here is a real-shaped rewrite. The before is a composite of posts we see constantly. The after is the same role, restructured.

Before (about 520 words, converts poorly)

Senior Software Engineer. We are a fast-growing, venture-backed startup revolutionizing the future of logistics. We are looking for a passionate, world-class engineer to join our team. Requirements: 8+ years experience, expert in Python, expert in distributed systems, experience with Kubernetes, AWS, Terraform, strong communication, self-starter, comfortable in a fast-paced environment, BS in CS or equivalent, experience mentoring, and 10 more lines. Nice to have: Go, ML experience, prior startup experience. Perks: competitive salary, health insurance, unlimited PTO, free snacks. Our mission is to...

After (about 280 words, converts well)

Senior Backend Engineer, routing. You will own the engine that assigns 40,000 daily deliveries to drivers. Today it is a greedy heuristic in Python that breaks past 10,000 stops. We want a real optimization service that holds up at 5x our current volume. Python and Postgres now, room to bring in Go. $190,000 to $225,000, 0.4 to 0.9 percent equity (illustrative, not advice). You should have shipped a system at scale that you owned end to end, be fluent in Python, and be comfortable reasoning about latency and cost tradeoffs. You will be our 6th engineer, working directly with the two founders. We raised a $9,000,000 Series A in April 2026. Onsite in NYC, hybrid, 3 days a week. We move freight for mid-size retailers, and the routing problem is the company.

The after is shorter, names a number, names a real problem, and gives a 5-year engineer permission to apply. It reads as a team that knows its own system. That is the whole pitch.

A quick checklist before you post

• Does the first sentence say what the person will build. (Not what the company does.)
• Is there a real comp band with a spread under 20 percent.
• Are there 4 or fewer requirements, written as scope not years.
• Is the whole thing under 400 words.
• Did you cut every instance of "passionate," "rockstar," "ninja," and "world-class."
• Is the funding stage and recency stated in one line.
• Is the location and remote policy unambiguous.

If you want to see the pattern across live roles, scan the board: it is sorted by how recently each company raised, and the posts that lead with the work stand out immediately. For the deeper case on writing for senior readers specifically, read write job posts senior engineers read.