Writing Job Descriptions for Engineering Roles

A job description has one job: make a qualified engineer who skims it for thirty seconds want the next conversation. Most JDs fail that test the same three ways: they bury the actual work under company boilerplate, they list twelve requirements when the team would hire on four, and they hide the salary. This guide gives a structure that converts, section by section, with the engineering-specific judgment calls.

This is the structural companion to writing inclusive job descriptions, which covers language that widens your pipeline; use both.

Before writing: the JD is an intake artifact

A JD written before the role is agreed is fiction, and the search built on it restarts in week four. The inputs come from the intake meeting: the problem this hire owns, the true must-haves versus trainables, the level, and the approved band. With those in hand the JD nearly writes itself; Yogen’s Job Description generator literally does so, producing a compelling, role-specific description from the Internal Intake Summary, which also keeps the posting honest about what the team actually agreed.

The structure that converts

1. Title candidates search for. “Senior Backend Engineer” beats “Software Engineer IV, Platform Pod.” Level in the title when your levels mean something externally; leveling guide if they do not yet.

2. The work, first (3–5 lines). What they will build in the first year, with what team, and one honest hard part. Engineers screen for real problems; “you’ll rebuild our ingest pipeline that currently falls over at 10× Black Friday load” out-converts any mission paragraph. The honest hard part does double duty: it attracts the people who like that problem and pre-filters the ones who do not.

3. Requirements: three to five, outcome-shaped. Every requirement past five costs qualified applicants, and the research on application behavior says the cost lands unevenly: strong candidates who treat lists as literal self-select out. Split honestly into “you’ll need” (the true must-haves from intake) and “nice if you have” (the trainables), and write them as outcomes where possible: “you’ve operated a production service at meaningful scale” rather than five named technologies. Outcome-based hiring requirements covers this reframe in depth.

4. Salary, posted. Range transparency is law in a growing list of jurisdictions and a conversion lever everywhere. If posting the band feels risky, the band is the problem; developing salary bands fixes that upstream.

5. The process, previewed. “Three stages over two weeks: a technical conversation, a practical exercise, a team panel.” Costs two lines, lifts completion, and signals an organized team; it is the same transparency your Candidate Packet delivers in full once someone applies.

6. Team and stack context (short). Team size, how the work gets decided, the stack as information rather than gatekeeping. Save the culture essay for the company profile pages where researching candidates actually read it.

Engineering-specific judgment calls

• Stack lists: name the core honestly, mark the rest “we also touch.” Requiring your exact stack screens out people who learn stacks in a month; that is what “trainable” means.
• Years-of-experience numbers: weak proxies that carry legal and inclusion baggage. “You’ve led a migration like this before” says what “7+ years” gestures at.
• Degree requirements: drop them unless genuinely required; they filter signal-negative for most engineering roles and narrow your pipeline along pedigree lines.
• Remote/hybrid/on-site: state it precisely, including time zones. Ambiguity here wastes everyone’s screening time downstream.
• “Fast-paced environment” and friends: template filler reads as template hiring. If the pace is genuinely intense, describe what that concretely means; candidates respect specifics and resent euphemisms.

Per-role skeletons

The structure holds across engineering roles; what changes is the hard part and the requirement shapes. A backend posting leads with scale or reliability problems and asks for production ownership; a frontend posting leads with product surface and asks for judgment about performance and accessibility trade-offs; a platform/SRE posting leads with the systems other engineers depend on and asks for incident scar tissue; an ML posting separates research from production honestly, because pretending one role is both is the field’s most common bait-and-switch. In every case the role-specific question banks show what you will actually evaluate, and the JD should promise nothing the loop will not test.

Maintain it like code

JDs rot. Re-read against reality at each re-intake, and run the two-question review before every posting: would the person we actually hired last time have cleared this requirements list, and does the posting say the hard part out loud? If either answer is no, the document is filtering for someone other than who you hire. Measure it like a funnel stage (views → applications → qualified rate, in your recruiting analytics) and the JD stops being a formality and starts being the top of your process.