Engineering team growth part 1: The perfect job description

This is part one in a series on engineering team growth.

Hiring is, arguably, the most important thing you do at work. Who you hire shapes what the company will look like in the future more than many other decisions you can make. Let’s talk about one of the most important parts of the process: the job description or “JD”.

What makes the JD so important?

The JD isn’t just a thing you post on job boards to attract people to the job. A properly written JD is a document that allows stakeholders to agree on what the job is, and communicate that to your interview panel and candidate. From there, it helps to guide the interview process towards the goal of hiring the person you want to hire.

A job description that has ambiguous, impossible, or too many or too few requirements, leads to bad hiring decisions because it fails to provide clear and concise criteria for who you are hiring. You’ll end up using your highly biased gut instead of actually evaluating the candidates’ skills. Not only can that lead to a team who all looks the same, but it also mean you won’t be hiring the best people.

Writing a job description

The job description should be the single document that the entire hiring process flows from, so craft it with care. I’ve seen some companies where job descriptions are written by committees, and everyone on the committee has their pet requirements or things they think are important for the job. The result is a complex JD with laundry lists of requirements and dozens of “nice to haves”. Since you’ll never find someone who fully meets requirements written like this, you will never be able to make your decision based on objective criteria.

It’s the hiring manager’s job to sift through everyone’s ideas about the job and winnow it down to the critical elements.¹ Focus the JD on what’s actually needed for the job, both hard and soft skills. From there, the hiring manager will need to make sure all stakeholders, and especially the interview panel, are on board with that decision.

Bias seeps in when you have ambiguous requirements, don’t setup your interviews to test the requirements you agreed on, or don’t use the requirements to decide whether you are going to hire or not. A little bias might not seem that bad, but ultimately bias means you aren’t making the best hiring decision for the company.

Here are some tips to help you:

Instead of “Nice to Haves” decide what skills and experience the job really needs. Leave everything else off. ²

You should know what a good fit is before the hiring process starts. The problem with NTHs is they make the idea of a good fit more ambiguous and therefore more open to opinions and biases. Instead of knowing exactly what you are looking for, you muddy the waters with criteria that aren’t critical for a candidate’s success. The result is not an objective decision but a decision made by someone’s gut.

Instead of “Years experience” List specific skills that are actually needed for the job. ³

Years experience feels objective when you write it down – either the candidate has it or they don’t. But years experience inevitably becomes subjective when someone’s preferred candidate doesn’t quite meet the criteria, and exceptions are made. Moreover, years experience doesn’t necessarily qualify anyone to do anything – we’ve all met people with a decade of experience who somehow manage to make everything more complex.

In addition, studies have shown it also impacts who applies for the job: women are less likely to apply for jobs when they don’t strictly meet all the criteria.

EG: instead of “5 years experience with Python and Django”, try “deep knowledge of the python ecosystem, including Django. Able to navigate a complex, existing codebase and develop new features quickly.”

Instead of superlatives like “rock star”, “10xer”, “expert”, or “world-class”, use meaningful qualifiers and skills.

I’m surprised that I still see language like this in job descriptions. While I agree that, especially at a small company, the best engineers can accomplish way more than mediocre engineers, remember that you are trying to optimize for team performance, not the sum of individual performance. Language like this tends to appeal to the overconfident, brilliant jerks if you are lucky, and moderately talented, toxic creeps at worst.

It can also be a turn-off to the candidates you really do want to hire: those who use their talent and experience to grow the rest of the team in addition to producing great code themselves.

Moreover, criteria like this aren’t inherently testable.

EG: instead of “rockstar Javascript developer”, try “deep knowledge of Javascript, including Typescript, React, and Next.js. Able to quickly navigate a new codebase, find issues, add new features, and collaborate with the team to plan complex tasks like updates and migrations.”

Instead of masculine coded language like “driven” and “fearless”, use neutral or feminine coded language like “collaborative” and “compassionate”.

Research suggests that feminine coded language won’t discourage men from applying, and it will encourage women. There’s a great tool that lets you paste in your JDs and check their language.

Instead of listing only hard skills, be explicit about what soft skills you require.

You can and should include soft-skills. One I see on a lot of job postings is “excellent written and verbal communication”, which is a good start, but it could be more specific so it’s clearer what communication skills are actually needed, and how the candidate should be tested. I prefer something more specific like “Ability to communicate complex technical information to non-technical stakeholders”. That’s something you can explicitly test.

Instead of “Culture fit”, focus on cooperation and collaboration.

Although rarely listed in the job requirements, many companies implicitly or explicitly require candidates to fit into their culture. While I think it’s a great idea to make sure candidates share your values and will thrive at your company, “culture fit” requirements often become little more than stand-ins for how much the interviewer likes someone. Remember, you are not trying to select friends, you are trying to hire the people who will be best for the company.

Obviously, I’m not suggesting you should hire people who are unpleasant to work with. You can and should filter out people with personality problems, and you should interview for people with the soft skills that make them easy to work with. For example, your job description might include things like “adept at collaborating with various stakeholders.” Be wary of vague requirements like the all-too-common “thrives in a fast paced environment”, which can be hard to test for. Instead, focus on things you can test for like “able to juggle competing requirements from disparate stakeholders”.

Footnotes

1. if the politics of your org make it difficult to streamline your JD because everyone expects to have their pet things included in the published JD, you may need to have two documents: one internal and one external. However, giving your candidate a clear idea of what they’ll be evaluated on is not only fair to them, it also means the candidates will be as prepared as possible. ↩

2. nice to haves can be useful for recruiters – sometimes it’s easier to search for good matches based on nice to haves than hard requirements. ↩

3. as with nice to haves, years experience can be useful to recruiters, and can also sometimes be useful when chatting with other engineers. 2 years experience vs 5 years experience can be shorthand for the scope of work someone is able to do. ↩