What senior engineers read first in your job spec

Experienced engineers read job descriptions the way they review a pull request. They skim for the parts that matter, look for inconsistencies and decide within a minute whether it is worth a closer look. Most specs lose them before the second paragraph.

We were developers before we were recruiters, and we still read specs through that lens. These are the questions a senior engineer is quietly asking when they open yours.

What problem will I actually work on?

"Join a fast-growing team building innovative solutions" says nothing. "We process payments for 3,000 small merchants and our reconciliation service no longer keeps up" says a lot. The second sentence tells an engineer what is hard, why it matters and whether their experience is relevant.

Lead with the problem, not the company slogan. If the work is a migration, say so. If it is a greenfield product with no users yet, say that too. Honesty filters for the right people.

Who will I work with?

Senior people care about the team more than the logo. Mention the size of the team, who they report to and how decisions get made. A line such as "You will join four backend engineers and report to the CTO, who still reviews code" is more persuasive than any list of perks.

What does the stack look like today?

List what you really use, not every tool anyone has ever installed. Separate the core from the nice-to-have. A list of 25 technologies reads as "we are not sure what we need", and strong candidates who match 80% of it will often not apply.

If parts of the stack are old, say it. Many experienced engineers enjoy modernising a legacy system, as long as nobody pretends it is something else.

How is success measured?

Describe what a good first six months look like. "Ship the new onboarding flow and reduce support tickets about it" is concrete. It also shows that you have thought about the role beyond filling a seat.

The practical details

Senior candidates have little patience for guessing games. Include:

• A salary range. It saves everyone time and signals that you respect theirs.
• Where and how you work. Remote, hybrid or on-site, and what that means in practice.
• The interview process. How many steps, who they will meet and roughly how long it takes.

Things that quietly put people off

• Requirements that contradict each other, such as "senior engineer, 2+ years of experience".
• Words like "rockstar", "ninja" or "work hard, play hard".
• A list of perks longer than the description of the work.
• Asking for a degree when the role clearly does not need one.

A simple structure that works

1. Two or three sentences on the problem and why it matters.
2. The team and how it works.
3. What you will do in the first six months.
4. The stack, split into core and nice-to-have.
5. Salary range, location and the interview process.

A good spec is not marketing copy. It is the first honest conversation between you and the person you want to hire. If you would like a second pair of eyes on yours, we are always happy to read it.