Senior Engineers Close the Tab in 10 Seconds. Here's How to Keep Them Reading.

I read hundreds of job descriptions every year. Most are terrible - written by HR teams who don't understand the role, or by engineering managers who dump every possible requirement into a list and hope for the best. Senior engineers glance at these, roll their eyes, and close the tab. Here's how to write one that makes them stop scrolling.

Start with the problem, not the company

Bad opening

"[Company] is a fast-growing fintech startup backed by Sequoia and Tiger Global, operating at the intersection of payments and lending. We're looking for a passionate Senior Backend Engineer to join our world-class team."

Good opening

"Our payment processing system handles 2M transactions a day. It was built as a monolith three years ago, and it's starting to crack. We need someone to decompose it into services, redesign the event architecture, and get us to 10M transactions/day without downtime. You'd own this end to end."

The first version could be any company. The second tells an engineer exactly what they'd be doing, why it matters, and at what scale they'd work. That's what hooks a senior engineer.

Requirements: fewer, better

A quick survey of 30 job descriptions from our clients: the average number of "required" skills listed was 12. The average number of the eventual hire actually had: 7. Companies are listing 5 requirements they don't actually require, and each one filters out a candidate who might be perfect.

For senior roles, list 3–5 must-haves that are genuinely non-negotiable: years of experience building production systems, ability to design distributed systems at scale, strong opinions on code quality backed by experience. Notice what's not there: specific languages, specific frameworks, specific cloud providers. A senior engineer can learn Go in a month if they know Java.

Under a clearly labelled "Nice to have" section, list 2–3 bonus items. The distinction between must-have and nice-to-have signals that you've actually thought about the role.

Talk about the team

Senior engineers care deeply about who they'll work with. Instead of "you'll join a talented team," share specifics:

"The payments team is 6 engineers: 2 senior, 3 mid-level, 1 junior. We do 2-week sprints, pair on complex problems, and do post-mortems after every incident. We're not perfect - our test coverage is lower than we'd like, and our documentation is thin. But we're honest about where we're falling short."

The truth about imperfections is more attractive than a polished pitch, because senior engineers know that every team has problems. The question is whether the team acknowledges them.

Include the salary range

Job descriptions with salary ranges get 30–50% more applications from qualified candidates. For senior roles, the range can be broad: "45–65L CTC depending on experience, plus ESOPs." That's a 20L range - plenty of room for negotiation - but it tells the candidate whether the conversation is worth their time.

What the work week actually looks like

Include a "typical week" section. Companies that do this report better candidate engagement and fewer expectation mismatches post-hire.

"A typical week: 2–3 hours in meetings (standup, sprint planning, design review). The rest is focused work — roughly 60% writing code, 20% code review and design, 20% mentoring and cross-team collaboration. We're hybrid: in-office Tuesday through Thursday, remote Monday and Friday."

The growth and impact section

Don't write "opportunity for growth." Write specifically what growth looks like: "In 6 months, you'd own our payment processing infrastructure. In 12 months, depending on your interest, you could move into either a Staff IC track or a people management track." A senior engineer who sees a concrete path is much more likely to apply than one who sees a vague promise.

The anti-patterns (what to cut)

• Cut the "About Us" section - or move it to the bottom; every candidate who cares will look up your company independently

• Cut the personality adjectives - "passionate," "self-motivated," "team player" are listed by every company and evaluated by none

• Cut the exhaustive benefits list - health insurance and free meals are table stakes, not differentiators

• Cut the corporate language - if you wouldn't say it in a conversation with an engineer, don't put it in the JD

The template

Structure:

(1) The problem - 2–3 sentences about what you're trying to solve.

(2) What you'd do - 3–5 concrete responsibilities.

(3) What you'd need - 3–5 must-haves, 2–3 nice-to-haves.

(4) The team - who they'd work with.

(5) Compensation - salary range, equity, key benefits.

(6) Typical week - how time is split, remote/hybrid details.

(7) Growth path - where the role leads in 12–24 months.

Total length: 400–600 words. The companies that adopt this format report fewer total applications but significantly higher quality - the engineers who apply have read the whole thing and are genuinely interested. That's exactly the trade-off you want.