How to write a position description

Almost every engineering position description sucks because they are general.

It might be okay for your company website but terrible for you as an engineering manager when you want to hire someone who fits well.

I am not going to stop on why those suck but focus on how to make it better.

The first thing you would want to do is to write a title.

The general title would be like: "Senior software engineer at SuperCompany." But, unfortunately, it doesn't tell much.

I strongly recommend specifying the role and team. And because I don't like this simple 'senior/middle/junior' scale, I suggest transforming it to this: "Experienced frontend engineer at SuperCompany's Chat." Now it is much better. However, you have to explain yourself whether you used 'senior,' 'experienced,' or any other word. Describe in one or two sentences what does it mean. Don't use years as experience reflection; instead, describe what you expect from this level.

For example.

Senior frontend engineer at SuperCompany's Chat.
After onboarding in our project, we believe that senior engineer shouldn't require too much guidance from other engineers to solve problems. We expect you to be capable of understanding what needs to be done, and in case you don't have all information, get it by asking questions. In other words, the more independent and self-efficient you are, the more we value your seniority as an engineer. 

This is my understanding; you can put yours. For example, working with a huge legacy code base and not breaking things is crucial for your position. But, whatever you write, be honest. The partnership wouldn't be good if the candidate or your expectations weren't met.

From the first letter to the last, you're telling a story. The story about your team, project, and company and the least important thing is the ideal candidate's description. Don't require a lot, instead propose what you think should ring your perfect candidate's bell.

You have to put some words about the company

My trick is to avoid whatever is written on the company website or Wikipedia and focus on things necessary for engineers or whoever this description is targeted.

About SuperCompany.
We're building various services, including SuperCompanyChat and SuperCompanyDrive. 
Drive is the closest team to us; we're extensively using and providing services for each other. 
The company structure is flat and divided into holistic teams with clear ownership around domains or products. 
We also have a dedicated team that builds an internal React-based design system that we all enjoy using. 
Each team has enough autonomy to define its workflow, and it is okay to work at the office or remote.

Honestly, no one wants to read another paragraph about a company that 'changes the world' and 'makes it better. Those are good intents, but just a bit corny. Think about what you would want to know as a candidate and write about it. That's simple.

I would want to know about the team as well

Many companies hire people in the pool, and then, by some logic, someone picks you, or you choose a team to join.

It scales well but also has downsides. For example, I'd like to know who I will work with, and I'd like to meet my potential manager in advance, etc. It doesn't require an explanation, right? So when I write a position description, I am trying to fit a few sentences about people.

Let's try.

About SuperCompany's Chat Team.
We are a relatively small team, but we have all we need to deliver new features. Except you, of course. 
Two very senior frontend engineers: one is leading the whole engineering part, and second, Jane Doe, also mentoring frontend intern, and you might know her from her blog [link] or meet-ups and conferences talks [link]. 
We have experienced backend and mobile engineers; we mostly use Python for the backend and React Native for mobile apps. Sometimes, the frontend team is involved in React Native projects as well. 
We have a fantastic product manager and UX people; check our recent feature with notifications settings screen: the whole team was working hard to deliver it, but on the surface of it, you can see theirs work. 

Maybe this example sounds a bit sugary. However, if you don't take a moment to have a bit of pride in what you do, then why do it in the first place? I am trying to squeeze the team's whole picture but being brief. You can also add some info about your ceremonies and regular meetings.

What we're missing is a product

I would want to understand what exactly I am going to build. It is crucial to have a clear picture in advance. So find some time and space to write a paragraph about the product.

About Product.
We're building chat. Chat sounds boring, but we have significant differences. 
Our chat is for families; we connect family members who live in different cities, counties, and continents. So our features are unique for this market: we have specific components for organizing celebrations, we have an elementary mode for grandparents, our group video chat has a circle view by default where you can easily 'fly' around and zoom between participants, and so on... Because we all have relatives worldwide, we are using it and many features we have; they came not from the product people but our teammates' feedback. 

Huh... I just wrote this part, and of course, this product does not exist, but I already want to work in that team and build it, right?

Only now, I would start the requirements part. But even before that, you may also write a few sentences about the codebase and working principles: how old it is, what frameworks and patterns are used, how you deploy, how you write tests, and so on — using the same language as you're explaining that to a colleague or a friend. So I will omit this part here and go further.

Requirements

I like to keep them simple.

Most likely, you don't need someone who knows exactly the same technologies you use. Instead, you need someone experienced who can learn any new tech stack or language.

Who are we looking for? 
You have to know how to do programming well, how and, more important, when to write abstractions, and ensure your code is covered with tests. Since we're extensively using TypeScript, and sometimes we contribute to our React Native app, you need to know or be ready to learn those technologies. We will provide proper onboarding, don't worry about it. 
We are looking for someone with solid experience and empathy: we don't blame (and expect you not to) for mistakes but require to learn from them. Although we give a lot of credit and personal freedom to make your own choices, we want to find someone who can use it for good. 

In current conditions, all engineers have a very diverse experience. There is no such thing as being 'best fit' anymore. First, you have to focus on intelligent people, regardless of the frameworks and types of projects they worked with, and second, this may sound like prominent, good people. Good and smart people are doubling your team's value. They bring you awesome ideas and solutions while making the atmosphere comfortable for the whole team.

It is easy to underestimate it and focus on just smart people.