Most tech JDs suck. And it’s not the HR’s fault.
In a typical setup, the HR writes these posts after a mere 2-minute conversation with the tech lead. The HR then writes up a job post, doing their best to guess at the technical details they don't fully understand.
The resulting JD fails to do two things it is supposed to do: describe the job, and sell it.
JD gets scrolled past by candidates. Those who do apply only learn what the job really involves when they talk to the tech lead.Every mediocre JD comes with a cost - you either miss out on great candidates or you miss the chance of impressing great candidates. Sometimes, both.
To avoid this in your next hiring cycle, use the following 7 rules to write JDs that actually work.
Rule 1: Sell yourself
When developers read a JD, they want to know who you are. A well-written JD nails this point. What does your company do? Why is it desirable? You have to give candidates a reason to be interested in your company. So, highlight your main work and one standout feature of your workplace. This could be your mission, a unique project, or your company culture. Keep it brief but compelling.
→ Write a concise description of your company's work and one key attraction.
Rule 2: Be reasonable about skills
Ditch the long list of every tech stack you've heard of. You're not building an entire tech team out of a person.
Focus on the core technologies needed for the role. Pick 3-5 must-have skills. Not more than that. And for nice-to-have skills, keep the list short. Mention that you're open to candidates who are willing to learn these on the job.
→ List only 3-5 must-have technical skills, and 2-5 nice-to-have skills.
Rule 3: Spell out the deliverables
Developers want to know what they'll actually be doing. Clearly lay out what’s expected of them in the first 6 months. This gives candidates an actual idea of what this role is. And it weeds out those who aren't interested in these specific challenges. Give them a sense of the projects they'll work on and the problems they'll solve.
→ Outline clear goals for the first 1, 3, and 6 months of the role.
Rule 4 - Talk a bit about the impact
Developers are problem-solvers at heart. They want to make things better and leave their mark. Maybe you're scaling a system to handle 10x more users. Or optimizing an algorithm to run 100x faster. These are the kinds of problems that get developers excited. Showing the potential impact of the role is a very powerful motivator.
→ Describe one major problem or challenge the role will help solve.
Rule 5 - Give clarity on the process
Tech hiring cycles are infamous for being long and tedious. So, be upfront about how long it takes for a candidate to jump through all the hoops. Clearly state your hiring steps, and be specific about what each step involves. Is there a coding test? How many interviews? Give a rough timeline.
This level of detail helps candidates decide if they want to invest time in your process. It also helps you get a pool of candidates that is truly okay going through the process.
→ List main hiring steps with a rough timeline.
For these 5 rules, make sure you loop in someone from the tech team. See, the root of bad tech job descriptions often lies in the disconnect between the HR and the tech team. It's not that the HR doesn't care or IT can't communicate. It's that we've accepted this gap as normal. It's not. So, make writing job descriptions a collaborative effort. Create a process where technical managers provide the core requirements and day-to-day realities of the role. Then, let the HR refine this into a compelling job ad.
Rule 6 - Break the silence on salary
Hiding salary information wastes everyone's time. Be transparent. List a realistic salary range, and other benefits. It shows you value openness and respect candidates' time. If you can't list an exact range, explain why. Maybe it depends on experience. Or perhaps there's room for negotiation. Just don't leave it out entirely.
→ Provide a salary range or explain how salary is determined.
Rule 7 - Avoid jargon at all cost
Nobody likes being directly sold to. But worse, everyone hates it when you try selling something in vague terms. So, when you are fleshing out the JD with the roles and responsibilities of the role, keep it simple. Use simple and direct vocabulary.
Keep it simple and direct. Don't say you're working on "cutting-edge technology". That's vague and overused. Instead, describe real problems your team is tackling. And please, avoid terms like "ninja", "guru", or "coding wizard". We're talking to adults here, not teenagers with a love for fiction. Stick to clear, professional language.
It's not boring. It's respectful.
→ Replace any jargon or buzzwords with simple, direct descriptions.
For quick reference, this is what a good JD looks like:
Nail your first impression
Good job descriptions don't happen by accident. They're the result of teamwork between the HR and tech teams. This collaboration bridges the gap in understanding.
Following these 7 rules, and taking a little help from your tech team will give you JDs that actually represent and sell the role.
Every JD is a chance to show developers you understand their world and welcome them to your world. Make it count.