We’ve been doing a lot of hiring at interviewing.io recently, which means we’ve been writing a lot of job descriptions. We’ve written before about how important good copy is and how it can elevate less well-known brands, but the exercise of having to write job descriptions for ourselves made me realize that giving advice is a lot easier than following it and that even we, who make a living from hiring, tend to fall into some of the same traps that we tell others to avoid.
So I thought I’d write this guide to keep us honest and to hopefully say some useful stuff to others undertaking this somewhat herculean task.
Before I get into the practical do’s and don’ts, a bit of theory.
How to avoid the “audience paradox”
When you start writing a job description, the first question you should ask yourself is, Am I trying to attract the right people, or am I trying to keep the wrong people out?
Then, once you answer it, write for that audience deliberately, because it’s really hard to write for both (if you try, you’ll find that your job description will end up being way too long, and then you’ll attract… neither!)
Why is it hard to write for both? When you’re trying to attract talent, your tone is going to be different. You’re going to focus on cool stuff about the company, projects they’re going to do, the impact they’ll have, initiatives and outcomes that they’re going to own.
When you try to keep people out, the focus tends to be more on a long laundry list of requirements.
Most job descriptions that I’ve seen tend to focus on keeping the wrong people out, though I doubt that doing so was a deliberate choice — when people write these, it’s generally their first instinct to optimize for less noise. Why? Because when you post job descriptions, you inevitably get a bunch of unqualified candidates in. If you’re spending any meaningful time on hiring, others are too, and you’re probably in a hot market. In these markets, more and more unqualified candidates try to get in because salaries go up.
At the same time, in hot markets, fewer and fewer qualified candidates apply for jobs because companies start going after them (this is why sourcers and recruiters exist).
The paradox here is that, despite the noise, writing job descriptions that aim to reduce it will actually get you fewer qualified candidates (and will not cut the unqualified ones).
Unqualified candidates have nothing to lose by applying to you, and no amount of bullet points will keep them out. On the other hand, writing job descriptions that, first and foremost, get people excited might actually get you some good people. Below is a succinct way of putting it.
So, no matter what, your goal should be to attract talent rather than worrying about the noise.
If they mostly attract noise, why even write job descriptions?
It’s true that in hot markets, most hires don’t come from inbound applicants. However, writing good ones still matters. Here’s why:
- They help you collect your thoughts and align internally on what you need
- They help you figure out how you’re going to talk about the job to candidates
- Many candidates who come from outbound sources (i.e. you go out to get them rather than them coming to you) will still want to see the job description so they can have something concrete to reference when they’re trying to grok the job
The anatomy of a good job description
An “About us” section
(1 paragraph) Come up with a good general company summary. In a previous post, we listed some exercises that will help you distill what makes your company special.
(1 paragraph) Contextualize the above for the specific team/department you’re hiring for. In other words, how does this specific team/department fit in to what you’re working on as a whole? What has made that department/team special, unique, or impactful til now? For instance, if your eng team is punching above their weight because it’s a small team producing outsized results, mention that. If you’re using some programming language that has a big community around it or you’re an early adopter of a cool language, mention that. If this is a design job description, and you’re a design-first culture or the founder is a designer, mention that. And so on.
An “About you & what you’ll do here” section
List your requirements, but only list actual objective deal-breakers. People tend to get really carried away in this section and come up with huge laundry lists full of subjective things like “Follows coding best practices”. Imagine someone reading the job description, and put yourself in their shoes. Will you really weed someone out because reading that bullet will be the watershed moment in their life, where they honestly admit that they have not, in fact, been following best practices? Remember, the point of a job description is to sell good people, not keep out bad ones! Do you think that putting a bullet about following best practices is going to get someone excited to work for you? Probably not. Following best practices is table stakes, as are most other requirements of that ilk.
Here are examples of good bullets. Note that they’re specific to the role at hand and that not being able to do them would actually be a dealbreaker for the role in question:
- Deep understanding of the tools that power marketing automation, experimentation, personalization, attribution, and analytics (This is from MasterClass, for a growth engineering role)
- Has worked on SDKs for any of the languages listed above, or has deep experience working with abstract representations of code – for example, in a compiler, codegen tool, or code-oriented developer tool (This is from Stripe, for a role working on SDK dev platforms)
And here are examples of bad bullets (pulled from real job descriptions). Note that these are bad not because they’re not true (they are!) but because they won’t keep anyone out and just create noise and detract attention away from the parts that attract the best people:
- Ability to write high performance production quality code
- Experience or desire to work collaboratively in cross-functional teams
- Solid written and oral communication
- [Laundry lists of every technology the company uses] ← Would not knowing one of these or not having the requisite years of experience in one of them really rule an otherwise great candidate out? If it wouldn’t, don’t list it! These really are meant to be deal-breakers.
What you’ll do here
List all the cool things that this person will get to do and work on. This is really important. Do NOT put generic things like “Will work with key stakeholders to drive KPIs”. Put very specific things that will excite the best candidates. The purpose is to get the best people excited, nothing more.
Here are examples of good bullets:
- Implement dynamic capacity management and rate limiting infrastructure to keep systems healthy during 10x load events (This is from Stripe)
- Build a Github for design files with full support for branching, conflict resolution, and comments (This is from Figma)
- Scaling our scheduling system to match and book hundreds of interviews every hour (This is one of ours at interviewing.io)
And here are examples of bad bullets (pulled from real job descriptions). Again, these are bad not because they’re untrue but because they’re generic and unmemorable. A good litmus test is, “Can most companies say this about the work they’re doing?”. Below you can see bullets that pertain to almost every eng role ever:
- Debug production issues across services and levels of the stack
- Develop tooling and automate processes
- Translate functional and technical requirements into detailed architecture and design
- Participate in code and design reviews to maintain our high development standards
Finally, see if we actually walk the walk with our own job descriptions at interviewing.io. We currently have 2 open roles: Head of Growth & Senior Product Designer. And of course we’re always hiring engineers. If you have an interviewing.io account, you can take a look.)