Writing a JD a senior engineer will actually answer

Senior engineers read a JD the way they read a pull request: skeptically, fast, and alert to smells. Most job descriptions fail that review in the first screen. The fix is not better adjectives. It is saying true, specific things that only your company could say.

Cut the requirements theater

A wall of twelve requirements signals a committee, not a team. Senior people self-select out of lists they only 80 percent match, and the list is usually padding anyway. Name the three or four things that genuinely matter for the first year of this job and delete the rest. Every requirement you cut widens the top of your funnel with exactly the confident, senior people you want.

Describe the work, not the vibe

“Fast-paced environment, passionate team, wear many hats” describes every startup and therefore none. What a senior engineer wants to know is concrete: what will I ship in the first six months, what is the stack and its worst legacy corner, who do I work with, how are decisions made. One honest paragraph about the actual work beats five about culture.

Write the section nobody writes

The strongest JD section is the one that filters honestly: what is hard about this job. Ownership of a gnarly migration, a codebase mid-refactor, an ambiguous roadmap. Senior engineers are not scared of hard; they are scared of discovering hard in week two after being sold easy. Honesty here is a sourcing advantage because nobody else does it.

Comp clarity is respect

A salary band and an honest sentence about equity move response rates more than any other single line. Silence on comp reads as either below-market or disorganized, and senior candidates have no patience for finding out which.

We co-write the JD at the start of every search until it describes the person you actually need, because everything downstream inherits its clarity. If your current JD has been open for months with thin response, book a demo and bring it along. The rewrite is usually the unlock.