Some of the common concerns I hear from recruiters when talking about the (rather low) quality of their JDs:
“Our JDs are already good.”
“We receive JDs from a hiring manager and there’s nothing we can do.”
“We cannot communicate anything more about the [team/company/stack/location].”
There’s nothing to disagree, maybe they really don’t have any more information.
Maybe there’s nothing to improve… which is quite unlikely.
You want to attract more developers, so why not start with attractive JDs?
To identify space for improvement, I like to use a simple phrase from the Design Sprint methodology. It’s “How might we…“
“How might we communicate a little more about the team?”
“How might we communicate a little more about the technologies used in the company?”
“How might we make the technical stack a little more transparent?”
It’s obvious you often cannot (or don’t want to) communicate the name of your client. That’s OK. Just apply one of the phrases from the Design Sprint which starts with “How might we…?”
“How might we communicate Glassdoor rating?”
- If a link to Glassdoor company profile is not feasible, we can at least write “Glassdoor rating 4.8”
“How might we communicate the salary?”
- If we cannot write it in the job ads, we can at least send it in a private message.
- If we cannot write the one number, we can at least communicate a range.
“How might we reveal more info about the team?”
- If we cannot reveal the names of team members, we can at least mention team size and seniority.
If we have an open mind and embrace change, we can proceed to rethinking the traditional JD…
Rethink the traditional JD
JDs were never meant to be external ads. They are internal HR documents, supposed to be stored in an internal knowledge base.
But here’s what most of the IT recruiters do: they pull them out of the internal knowledge base (with the help of an HR specialist) and then copy-paste the super-boring JD to job portals — hoping this will attract software developers.
Let’s leave the JDs where they are supposed to be (in an internal HR knowledge base) and create attractive job ads instead.
We help our clients, IT recruiters, rewrite the (usually boring) JDs to more attractive Job Ads.
1. Avoid obvious mistakes
First, we need to remove all the obvious mistakes such as:
Merging two roles into one JD (Java Developer - mobile, web, desktop)
or mistakes in technologies (programming languages, frameworks, tools)
To avoid these mistakes, you should lay down strong technical foundation.
2. Focus on what matters to developers
Second, we need to focus on what matters to developers. Experience shows software developers are keen to know about the tech stack the company uses. If more stacks are used, we need to highlight the one the developer will be working with most.
In addition, developers tell us they want to know more about the company and team.
Company type: Corporation or a Startup? Product-centric or an Agency?
Team: Size and Seniority?
Software development methodologies: Waterfall or Agile?
3. Low hanging fruit
Third, developers want to know a little more about the company culture and management. We can help them by adding links to company profiles on
Glassdoor rating / reviews
Even if you cannot mention the company name, you can still mention for example “Glassdoor rating 4.8” (without a link).
Tweak it to be more attractive
We are getting to a next level here. A job ad itself is not enough as you cannot send it in a LinkedIn message when you reach out to developers.
We recommend writing a short teaser. Only three-four sentences long highlighting the most important pieces of information. Salary range, too.
A little trick how to write the teaser effectively: It helps me to imagine I’m on a call with a developer. I only have 15-20 seconds to present the opportunity and need to focus on the most important pieces of information.
We are going to talk about this in depth during our upcoming webinar.
Join us on Monday, November 25, 2019. Sign up here »