How to write a developer job description

A job description is a filter, not an advertisement. The goal is not maximum applicants. It is a small number of right-fit applicants and zero hours wasted on wrong-fit ones. Most developer job posts fail because they are written to impress rather than to inform. Here is how to write one that works.

1. Lead with the real problem

The first paragraph should answer the only question a strong developer has: what will I actually work on? “Migrate a monolith serving 40k daily users to services” beats “join our dynamic team” every time. Name the product, the codebase’s rough age and size, and the one or two problems this hire will own in their first six months. Specific problems attract people who have solved them before.

2. State the seniority honestly

“Senior” means different things at different companies. Define it in terms of ownership: does this person execute well-scoped tickets, own a feature area, or set architecture for a team? Say which. If you need someone who can work without a product manager writing specs, say that too. Mislabeled seniority is the top cause of hires that fail in month two.

3. Cut the 20-technology laundry list

A requirements section listing React, Angular, Vue, Node, Python, Java, AWS, GCP, Kubernetes, and ten more tells candidates you copied other job posts. List the three to five technologies the person will touch weekly. Move genuinely useful extras to a “nice to have” line. Everything else, delete. Specialists self-select out of vague posts, and specialists are who you want.

4. Put a salary range in the post

Senior developers rarely apply to posts without pay information, and pay-transparency laws in a growing list of jurisdictions require a range anyway. State an honest range and what moves a candidate within it. If you pay differently by location, say how. Hiding the number does not get you a better deal. It gets you a weaker pipeline and awkward final-round dropouts.

5. Be exact about remote and timezone

“Remote” alone is ambiguous. Say: fully remote or hybrid, which timezones you hire in, how many hours of overlap with your core team you need, and whether there are on-site weeks. A developer in a compatible timezone who knows the overlap requirement upfront is a better applicant than three who find out at offer stage.

6. Describe the process and the first month

Two sentences on the hiring process (number of steps, whether there is an exercise, whether it is paid) and two on what week one looks like. This costs you nothing and signals that you respect the candidate’s time, which is the cheapest credibility you can buy.

The template

Copy this and fill in the brackets:

# [Seniority] [Role] at [Company]

**[One sentence: what the product does and who uses it.]**

You will own [the real problem: e.g. "our checkout rewrite" or
"reliability of a Node API serving 2M requests/day"]. The codebase
is [age, size, stack in one line].

## What you will do
- [Concrete responsibility 1]
- [Concrete responsibility 2]
- [Concrete responsibility 3]

## What we need
- [3 to 5 true requirements, each one weekly-use]
- Nice to have: [1 to 3 extras, honestly optional]

## Pay and logistics
- [Currency][low] to [high] [per year / per hour], based on [what]
- [Remote policy]: [timezones hired], [X] hours overlap with [zone]

## Process
[N] steps: intro call, [technical step, paid if an exercise],
final conversation. We reply to every applicant within [X] days.

Red flags in your own post

Before publishing, delete anything that matches these:

• “Rockstar,” “ninja,” “wear many hats,” or “fast-paced environment.”
• More than five required technologies.
• Seniority in the title that the salary contradicts.
• Requirements that describe three different jobs (design plus front end plus DevOps).

The shortcut

A sharp job description still leaves you with sourcing, screening, and interviewing. If you want the filtering already done, a vetted network hands you candidates who have passed technical screening, and the description above becomes your brief instead of your funnel. Either way, write the problem statement first. Nobody can outsource knowing what you need.