A VP of Engineering at a Series B startup told me something that stopped me cold: "We spent $20,000 on a recruiter and got worse candidates than when I rewrote our job description and posted it on LinkedIn for free."
The job description is your first conversation with every candidate. And most companies are having a terrible first conversation.
I've written job descriptions for 30+ roles across engineering, design, and product teams. I've also applied to hundreds of jobs. Here's what I've learned from both sides.
Why Most Job Descriptions Fail
Problem 1: The Wish List
Requirements:
- 7+ years of experience in software development
- Expert in React, Angular, Vue, and Svelte
- Strong knowledge of AWS, GCP, and Azure
- Experience with PostgreSQL, MongoDB, Redis, and Elasticsearch
- Proficient in Docker, Kubernetes, and Terraform
- Experience leading teams of 10+
- Strong communication skills
- MBA preferred
This isn't a job description — it's a letter to Santa. No single human matches this list. What happens? The best candidates self-select out because they honestly assess themselves against the requirements. The worst candidates apply anyway because they don't care about requirements.
Research from Hewlett-Packard found that men apply for jobs when they meet 60% of the requirements, while women apply when they meet 100%. Your inflated requirements list is actively filtering out qualified, thoughtful candidates.
Problem 2: Company Monologue
Three paragraphs about your company's mission, founding story, and office perks before you even mention the role. Candidates don't care about your kombucha tap until they know what they'd actually be doing.
Problem 3: Vague Responsibilities
"Work with cross-functional teams to deliver high-quality software solutions" could describe any engineering role at any company. It tells candidates nothing about what their Monday morning would actually look like.
Problem 4: No Salary Range
In 2026, posting a job without a salary range is like listing an apartment without the rent. Candidates scroll past. And in an increasing number of jurisdictions, it's literally illegal to omit it.
The Job Description Framework That Works
After analyzing high-performing job posts (measured by quality of applicants and time-to-fill), here's the structure that consistently outperforms:
Section 1: The Pitch (3-4 sentences)
Start with what makes this role interesting. Not your company's history — the candidate's opportunity.
Bad: "Founded in 2019, TechCorp is a leading provider of cloud-based solutions..."
Good: "We're building the API that powers real-time payments for 2,000+ businesses. The platform processes $4B annually, and it needs to handle 10x that by next year. That's where you come in."
This section answers: "Why should I stop scrolling and read this?"
Section 2: What You'll Actually Do (5-7 bullets)
Be specific. Describe the real work, not HR-approved abstractions.
Bad:
- Collaborate with stakeholders to define requirements
- Design and implement scalable solutions
- Participate in code reviews
Good:
- Own the payments processing pipeline end-to-end — from API design to deployment to monitoring
- Lead the migration from our monolithic payment service to event-driven microservices (we're targeting Q3)
- Debug production incidents involving real money (yes, it's high-stakes, and yes, you'll have solid observability tooling)
- Mentor 2 mid-level engineers who joined in the last 6 months
The candidate should be able to picture their actual week after reading this section.
Section 3: What We're Looking For (4-6 bullets)
Split into "must-haves" and "nice-to-haves." Be ruthlessly honest about which is which.
Must-haves (actual requirements — if someone doesn't have these, they genuinely can't do the job):
- 3+ years building production backend services
- Experience with event-driven architectures (Kafka, RabbitMQ, or similar)
- Comfort with on-call rotations (we use PagerDuty, incidents average 2/month)
Nice-to-haves (these would be great, but we'll teach them):
- Experience with payment systems or fintech
- Familiarity with our stack (Go, PostgreSQL, Kubernetes)
- Previous experience mentoring junior engineers
Section 4: Compensation and Benefits
Lead with salary. Then benefits. Be specific.
Compensation:
- Salary: $160,000 - $195,000 (based on experience)
- Equity: 0.05% - 0.1%
- Annual bonus: 10-15%
Benefits:
- Health/dental/vision (100% covered for employee)
- $2,500/year learning budget
- Flexible PTO (team averages 4 weeks/year)
- Remote-first (async culture, core hours 11am-3pm EST)
Vague benefits ("competitive salary," "great perks") signal that you're either hiding something or haven't thought about it.
Section 5: The Process
Tell candidates what happens after they apply:
Our Process:
1. Application review (we respond within 5 business days)
2. 30-min intro call with the hiring manager
3. Technical assessment (take-home, 2-3 hours)
4. Team interviews (2 rounds, 90 min total)
5. Offer
This reduces uncertainty and shows respect for candidates' time.
Writing Tips That Improve Response Quality
Use "You" Language
Write to the candidate directly. "You'll own the search infrastructure" is more engaging than "The candidate will be responsible for search infrastructure."
Include the Challenges
Don't paint a perfect picture. The best candidates are drawn to interesting problems, not easy ones.
"Our codebase is 8 years old and has some technical debt. You'll spend roughly 30% of your time on modernization alongside new feature work. We're honest about this because we want someone who sees it as an opportunity, not a surprise."
Authenticity attracts better candidates than marketing.
Show the Team
Who will this person work with? What's the team structure?
"You'll join a team of 6 engineers (3 senior, 2 mid, 1 junior) plus a product manager and designer. We ship weekly, do async standups, and have a Slack channel that's 50% technical discussion and 50% pet photos."
Avoid Gendered Language
Research shows that words like "rockstar," "ninja," "dominant," and "aggressive" discourage women and non-binary people from applying. Tools like the Gender Decoder can check your JD for biased language. Use neutral terms: "skilled," "experienced," "collaborative."
Automating the First Draft
Writing a good job description from scratch takes time. Most hiring managers are too busy to spend 2 hours crafting the perfect JD for every role.
Job Description Writer generates structured, bias-aware job descriptions from basic role details. Input the title, level, key responsibilities, and tech stack, and it produces a complete JD following the framework above. It's a solid first draft that you can then customize with your team's specific details and culture.
The Job Description Checklist
Before posting, verify:
- [ ] Opens with why the role is interesting (not company history)
- [ ] Responsibilities describe real, specific work
- [ ] Requirements are split into must-have and nice-to-have
- [ ] Salary range is included
- [ ] Benefits are specific, not vague
- [ ] Hiring process is outlined
- [ ] Language is inclusive (no "rockstar/ninja" language)
- [ ] "You" language is used throughout
- [ ] Challenges and context are honestly described
- [ ] Under 700 words total (longer JDs get fewer applications)
The ROI of Good Job Descriptions
The math is simple:
- Bad JD: 200 applications, 5 qualified, 50 hours of screening
- Good JD: 80 applications, 25 qualified, 15 hours of screening
You attract more of the right people and fewer of the wrong ones. Time-to-fill drops. Screening load drops. Candidate quality goes up. And the best candidates — the ones with options — are more likely to apply because your JD showed them you're a company that communicates well.
Generate a professional, inclusive job description in seconds at job-description-writer-seven.vercel.app.
Top comments (0)