Four practical "exercises" when writing JDs to help prioritize the knowledge and experiences you expect this person to bring:

1) Pretend you only have 100 words. Simple stuff, but getting ruthless is a good way to prioritize.

2) Write an "anti-JD": the type of person you don't want for the role. A tip: focus on unconscious competencies - things you expect the person to know on day 1.

3) (Similar to Aline's litmus test in the article of "Can most companies say this about the work they’re doing") If you can write "Only an idiot wouldn't ... " in front of the line, it's not a good differentiator.

4) Imagine you were going to ask the person you hire for this role to give 5 lunch and learns their first week on the job. What would the topics be and to what depth would you expect them to go?

Also, at least in my experience, the easiest way to deter "noise" from unqualified applicants is to be clear what the first interview will consist of and how it will be passed/failed.

"We expect you to come prepared to discuss the pros and cons of the following, citing previous work as much as possible: (insert relevant topics from exercises above e.g. computer vision, DevOps, Redux, recent famous papers in your field, etc) Candidates without experience or evaluated below an intermediate level of knowledge will not proceed."

How many word article was that without mentioning once "how much are you paying"?

I have a thousand open source projects I could use my time on if paying the mortgage and putting food on the table wasn't an issue.

So let's cut the jabber and get the turkey bit out of the way first. Then we can discuss how 'cool' you think you are.

You know how a cool job description is written? Salary and equity first, very short list of mandatory technologies second, nice to have third, and nothing about how cool the company is. If the first three items attract someone then they're going to google the place and figure that out.

4 pieces of anecdotical data:

1. I stopped writing good job descriptions when hiring because HR always killed it: they cut mine to half and add their crap all over. I had open positions for SQL DBAs for 9 months, all candidates were developers in the best case and BI in the worst

2. From time to time I receive calls on LinkedIn with X years of experience required, where X was even 15. When I asked about it (I had more, I was just curious) they said the real number is X/2, but they wanted to cut off people with very low experience that are rounding up.

3. No job description in Europe that I've seen included any useful info on salary. All the discussions in the past 2-3 years ended when I found they were offering below the market and below current level. All this time could have been saved on both sides if at least some range would have been offered. This applies even for positions where they made me 1 offer per week with increasing salary (a few percent) for 2-3 months in a row, which is incredibly stupid.

4. In the past 2-3 years I never saw a job description that looked really professional and interesting. The positions were more interesting than the descriptions.

The trick to writing a great job description is not to write it at all.

I've seen HR depts with spreadsheets and lists of acronyms and frameworks and really none of that matters. and "very competitive salaries" but absolutely no numbers anywhere.

You want to find the person you're going to hire, then write the job description. You're looking for fast learners and innovators, they can learn a framework in a few days at most.

For college hires, just sponsor a prize at your local school's hackathon. Anyone you meet there with an interesting project just bring onsite for an interview. For more experienced devs, better go with internal recommendations. Your top performers all have friends, and some of them might be bored right now.

And be upfront with the numbers; You'll waste less time. I knew someone who wasted 5 rounds of interview with someone (this was outside the Valley) before revealing compensation. The candidate just flat out said he needed 3x or it just wasn't worth his time.

Company: we offer very competitive salaries

Candidate: then why are you hiding the salary on your job description?

Most effective way I've found of keeping out the noise is to put a few screening questions in place. Easy ones, maybe even a three line code sample (something that's almost fun to write).

Frequently the primary audience for a job description is recruiters.

I agree with a lot of these points. I hate how most job descriptions are written, a lot of people that want x years of language and y years of framework, which I think that should be relatively rare.

What I want in a job description is "We work on X project with Y framework and Z back end", just say what you are working on and if I am interested in that. Then for the requirements make it X years of experience in domain, Y years of being a lead. Unless you are really needing that specific subject matter expert, having those requirements doesn't make sense. If I am hiring a senior developer for a Java position I don't really care if you have 5 years of Python, C#, C++, Ruby or whatever, but 5 years of backend experience could be helpful.

> And of course we’re always hiring engineers. If you have an interviewing.io account, you can take a look.)

Wait, you need to have an account just to see their open jobs? That seems like more of an antipattern than anything you could put in a job description.