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."
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.
I think you are a good data point counter to what many people do.
I think it shouldn't be about "how cool the company" is, but you should know what is the character of the company. We're not trying to be "cool", we want to hire people who will come here and do their best work, and want to see the impact they can have (we're in health tech).
That's not for everybody. People probably went to work for places like Uber because they thought it was "cool" to work there. or facebook or google. How many people get really excited about BNPL tech, where here in Australia, that's big thing. Those people may be more motivated by the $$.
There are missionaries and mercenaries, and I disagree that every company needs to only ire missionaries.
Which is great, until every job application reads as the exact same mix of positive adjectives and power words and you learn to skip the first 1-2 paragraphs of every one.
Only if you limit yourself to a particular kind of company, I think? I've worked as a dev for decades, but not for proper, actual tech companies... mostly a mixture of small biz and nonprofits. No two orgs were alike, even though my job at each one was very similar.
> That's not to say salary should be secret (dear god, no), but how cool a company is IS an important metric in and of itself.
If only I had $1 for each time I saw a company showing off foosball tables, game consoles in the hallway, picnics, team get-togethers, people laughing and being cheerful.... And in the end it's the same cubic hellhole where people are no better than anonymous cogs in the machine.
If the company describes itself as "cool" because they have pool tables, that's a great thing. It's signal that thats what "cool" is to them. Sounds like a job description that talked about not working in a cubicle hellhole would resonate with you more.
> If the company describes itself as "cool" because they have pool tables, that's a great thing. It's signal that thats what "cool" is to them.
No, not really. It just means that HR had a PR budget to sell themselves as cool, and they bought a game as a prop.
My point is that this blend of signaling is pure bait-and-switch. The mods operandi is that they sell this false idea that they are all about fun and games but in the end it's just a low-paying cubicle hellhole with crunch time as the baseline.
Well, yes, they think they're saying something which reveals a lot more to you and you know to avoid this company. I also like to ask myself - who would be attracted by such a job posting and would I want to work with them?
If you already have a page about how cool you are, it doesn't need to be repeated in every posting, and candidates for who it matters the most will have more information than shortened descriptions to avoid walls of texts in the job posting itself.
I don't see much interesting or unusual on that Cookpad page.
"You face up to reality, knowing that you can change it" -- things like that can be said about almost any job. And the rest of the things on the page too I think.
What would the opposite to facing up to reality be?
"Here, we don't accept reality. And if something is bad, it has to stay so."
They write:
"There’s a big difference between saying that you’re making good in the world and actually doing it. "
They're a recipe sharing site.
(Nevertheless, seems like maybe a nice place to work at)
I build a relationship with a few recruiters in the US, and I specifically told them that I don't want to waste their time and to start off with a compensation package any time they have something interesting. I cannot even comprehend discussing a job without salary range.
Ive lived in the top two tech city in EU (edit: Europe as of now) London and Berlin and there were always ranges in job specs, now I'm in Amsterdam and it's the only city that doesn't seem to like that (along with coding turning on the brain, i would say)
It varies a lot in the UK. Some companies share ranges in the job description, most dont. Many don't share a range publicly but you can get it in the first call with the recruiter if you ask. Some just don't give you anything. And the worst are the ones that don't give their ranges but ask for current and/or expected salary.
I see descriptions of how amazing the company is as being largely fluff. Every company thinks they're cool and amazing.
Sort of like how every candidate thinks he/she is a 'great problem solver' and 'team player'.
It's a goal that we all acknowledge is something we desire, but so subjective that everyone believes they have it and self-assertions to that effect tell one very little.
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.
Yes, if they would be interested. We hired one developer and 3 weeks later he said it is not what he was looking for (and I was very open upfront on what the work is, a combination of production DBA and development DBA).
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.
This probably works well for smaller scale hiring. At a medium org, you want to make sure to source diverse candidates and hire without bias. (We all have biases!)
That comes off similar to "what matters in the stock market is to buy low and sell high". Sure, it's true enough, but not really valuable insight.
The trick in hiring is how do you identify and hire those individuals. Diversity is one way to reach those outcomes - it's not a side quest, it's how to increase your odds on the main quest.
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).
A lot of people froth at the mouth about take home tests.
I liked the idea originally, but the only people who I've encountered that give one, require candidates to run the technical gauntlet in the in-person interviews anyway, so then I feel like it was a total waste of time.
If you're afraid of people cheating, fine, just don't do it.
I don't think it comes off as a gauntlet, but we do a take home test, review it with the interviewee at the in person, and then pair program on adding a couple of extra features to it. It's worked extremely well.
I ask candidates to list three blog posts that they recently read and enjoyed. Seems to be an easy way to filter out non-serious candidates and script kiddies.
This has worked with roughly 60 to 70% of the candidates I have interview since I implemented this rule.
Filtering out people based on a question about the blogs they read sounds kind of horrible. You'll get all noise and no signal.
I spend some time on HN and other places reading about stuff related to my field or about software in general. If you asked me that question, I would have zero chance recalling the last things I read. And it would raise a big red flag about whether you know what you're doing.
Just because you're filtering some people out, doesn't mean that your filter is good.
I also discuss the posts they read and shared with me during the interview. If they’re simply sharing random posts without understanding it in context, it becomes obvious very quickly.
This seems to work to filter out people who don’t like their work enough to read anything related to it and people who like to fake their way thru such tasks by sharing the first three Medium articles they find on the homepage.
What makes you question the “knows what they are doing” abilities of someone asking you to name three posts they liked? Is it any different from asking someone what algos they like and why?
Does whether or not they are relevant blogs to the role or industry matter at all to you? My gut feeling is that you would get a better read on the personality of a candidate when they send you links that have little or nothing to do with the job they're applying for. All three links to industry-relevant blogs will tell me is that this candidate aims to please for obvious self-advancement reasons.
I do get blogs linking to random stuff and I discuss those posts on merit. E.g., someone I was interviewing for a web dev intern position sent me a post about a woman coming out as bisexual. This post resonated with him because he felt that in our country, we need to discuss sexuality more freely. So I tried to probe how deeply they had thought about the topic or were they sharing it for its shock value.
You're right that it gives me a read on the candidate based on what they share. It's a good filter - if the candidate picks something really basic to share, it shows how well they know their tech. If they choose something more advanced but can't contextualise it, that's a sign that they are faking it to make it.
Three industry related posts isn't automatically a red flag to me because the posts may cover different sub-topics.
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.
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."