Why your job description fails to attract senior engineers

When hiring senior software engineers, you’re not buying, you’re selling. With this claim, last week’s post landed #1 on Hacker News and reddit and sparked some great discussions.

As a result, many people sent me their job descriptions for feedback. I’ve read over a hundred of them in the last few days. While some of them were really good, almost all of them had glaring problems, which will immediately turn away great talent. Let’s take a look at the most common ones and how to fix them.

1. Your job title is boring

The job title matters, because:

• It’s the first thing the potential candidate sees
• It can be a source of pride
• It will be on the person’s resume for years

Thus, a good job title should do three things:

• Generate interest and excitement about the company and role
• Sound impressive
• Sound professional

Striking a balance between these three is difficult and requires a bit of creativity.

Bad examples:

• Senior Software Engineer

  Reasonably impressive and professional, but boring and uninformative. This tells me absolutely nothing about the company or the role.

• iOS Developer

  Even if I really enjoy iOS development, I’d probably avoid this role. Like above, it’s boring and doesn’t really tell me anything about the job. But another concern is that this isn’t ideal on my resume - what if I want to switch to another technology in the future? Employers tend to put people into specific categories. I’d be worried this might make people think I can only do iOS development and nothing else.

• Senior Java Programmer

  Avoid “programmer”, since it can be seen as disadvantageous for future employment. I recommend sticking with “Software Engineer”.

• Rockstar Developer wanted - Help change the world!

  Most engineers cringe at buzzwords like “rockstar”, “wizard”, “ninja”, etc. Stick to more neutral terms like “specialist”, “expert”, and “professional”. Adding an exciting sentence to the title like this can be helpful, but in this case, it doesn’t carry any information and sounds untrustworthy. How exactly will I change the world?

Good examples:

• Software Engineer - Core product team, Python

  This is better, because it already tells me some details about the role. Working on the main product is exciting. It also gives me information about the tech stack I’ll be using.

• Senior Software Engineer - Save real lives with our modern health platform (C#)

  This is good because it already tells me three things: What I’ll be working on, a specific technology that is involved, and how much impact I’ll be having. Only do something like this if the claim is actually true though.

• Senior Software Engineer: Mobile analytics platform (Remote or San Francisco)

  This gives me information about the product and highlights the main perk the company provides (work remotely).

General recommendations:

• When in doubt, stick with (Senior) Software Engineer as a baseline
• Add additional information about the company, role and tech stack after the title. This also gives the applicant a bit of flexibility in terms of what they want to put on their resume. If they don’t like the stuff after the main title, they can just leave it out.
• If you have very strong perks like working remotely, you can include these as well.

2. Your requirements are bad

Often, job descriptions are written by non-technical people. Sometimes they don’t fully understand the technologies they’re dealing with. This can result in ridiculous situations where the company is asking for 5 years of experience in technologies that have only been around for 2 years.

However, if you’re reading this, chances are pretty good that you’re not doing that. That said, many of the job descriptions I received still had too many requirements in specific technologies. I believe that the thought process behind this goes something like this: “We need more senior engineers! - Let’s up the requirements. Then only people with more experience will apply.” I think this type of thinking is backwards in our market. It will actually lead to fewer senior applicants.

To explain further, consider this list of requirements:

• 5 years of experience in iOS development
• Excellent knowledge in both Objective-C and Swift
• Experience with Core Data and 3rd party libraries like AFNetworking, Alamofire
• Experience with git, JIRA, Unit testing (Quick/Nimble)

This list is asking for knowledge in very specific languages and technologies. Consider an applicant who fulfills all the requirements except for one or two minor things. They might be put off from applying, even though they’d be a great fit. Preparing an application is a lot of effort and I wouldn’t put the work in if I’m not even sure I fulfil the requirements.

More importantly, this sends a signal to applicants that you seem to care about the wrong things. Consider how fast technologies and languages change these days. It’s much more important that the person is curious, enjoys learning new things quickly, and understands the core concepts behind it. For example, in the above list, you could replace “Core Data” with “mobile databases” or “JIRA” with “issue tracking”. This shows that you value concepts over knowledge in specific tech stacks.

General recommendations:

• Have a maximum of one or two firm requirements. Some of the best job descriptions I’ve seen have none at all.
• Make it very clear which requirements are mandatory and which are nice to have.
• Ask for concepts, not specific technologies (“relational databases”, not “MySQL”)
• If you’re non-technical yourself, talk to your engineers! Let them help you understand what the actual requirements are (show them this post if necessary). That way you’ll be able to communicate them well.
• Show your full tech stack elsewhere in the job description. Don’t mix it up with the requirements. Don’t say “we want X”, instead say “we use X”. If you’re still using legacy tech, make it very clear which part of your stack is current and which is legacy. Explain your situation and how you’re transitioning to the new stack. Make it clear what tech the person in this role will be working with.
• If you want to get better, more experienced candidates, don’t up the requirements. Instead, make the job more attractive.

3. Your language isn’t targeted at engineers

The second thing in most job descriptions is usually a short description of the company. I think this is good, because the main goal of the potential applicant is to understand exactly what the job is going to be like. They can’t do that without knowing what the company does and how it operates.

This makes the company description very important. Unfortunately, most companies use vague language that isn’t specifically targeted at developers.

A few general recommendations:

• Your company description should be a very short elevator pitch geared at developers.
• Start out by simply stating what your company does.
  • Bad: “Dunder Mifflin provides amazing value to their customers and is highly focused on quality.”
  • Better: “Dunder Mifflin makes high quality office paper.”
• Consider removing any word or sentence that could describe any other company. Focus on what makes your company special and interesting.
• Make sure to include aspects that are specifically interesting to developers. For example, you could mention difficult technical challenges they’ll be working on.
• You can make bold claims, but back them up with data. Engineers are usually sceptical people because of the nature of their work.
  • Bad: “We have great work-life balance.”
  • Better: “We understand that time spent at the office doesn’t equate to productivity. On average, team members work X hours per week.”

A good company description is a work of art and quite difficult to write. I recommend asking your team for help, especially other engineers. They can also help you figure out what’s exciting for them about the company, role and technology you’re using.

4. Crucial information is missing

Almost all the job descriptions I looked at were missing the following info:

Salary range

There’s two opposing myths floating around:

• Software engineers don’t care too much about salary.
• Software engineers care mainly about salary. If you’re not paying market rate, you can’t ever hire good people.

In my experience, the truth lies somewhere in the middle. Of course, salary is very important, but many engineers would easily choose (and have chosen) a lower salary for a variety of reasons.

That said, the benefits of providing a salary range up front are undeniable. Stack Overflow ran an experiment and concluded that job listings with a salary range get 75% more clicks.

A common objection is that people will fixate on the upper bound and get disappointed when they’re at the minimum/lower bound. The solution to that is to make the salary range fairly wide and put in a buffer. For example, if your budget for a position is around $160k, make the salary range on the ad $75k - $150k. Don’t make it wider than 2x though, as this can also be seen negatively.

Management processes

It’s very important to mention what management processes and development methodologies you use. Be very specific. Don’t just say “Agile” or “Scrum”, since these words are essentially meaningless. Each company has their own understanding and implementation. For example, when describing your process, you could say this:

“We use full Scrum, including daily scrum meetings (at 10am), bi-weekly sprint reviews and sprint retrospectives. We have a physical scrum board with post-its as backlog-items in our office and also track them in JIRA.”

I’m not advocating this particular process, but this paragraph does a great job at explaining what the daily routine will look like. You should also mention practices like code review and automated testing. This shows that you care about code quality, which is a very high priority for many engineers.

Perks

According to this post, for many developers, Work-Life-Balance is another top priority, followed by flexible work arrangements. However, it’s not enough to simply state “We have great Work-Life-Balance.” You need to explain what you mean by that and back it up with data. Does your job description include answers to the following questions?

• How many hours do people work on average per week?
• Do I have to track my time?
• Do I have to be at the office at certain times?
• Can I work from home? How often?
• Do people work on weekends? Are they expected to be available for calls?

Team and company culture

See my above points on the company description. Having a dedicated website showing off the company’s culture also helps a lot.

Office environment

Most listings are missing answers to the following questions:

• How many people will be working in the same room?
• Is it noisy?
• Is there space for uninterrupted, quiet work?
• Is the office air-conditioned?
• Are there standing desks available?

To save space, you can also link to detailed answers and pictures on a dedicated company page.

Tech stack

As described above, show your full tech stack in the job description and don’t mix it up with the requirements.

Hiring process

Before I apply, I want to know what I’m going to have to go through to get hired.

Explain in detail what your hiring process looks like:

• How many interviews? With whom?
• How do you assess technical skills?
• What are the time frames?

This leads to my next point:

5. You’re making it too difficult to apply

Most job descriptions I got weren’t on the company’s website, but instead on some applicant management system’s subdomain, for example:

• boards.greenhouse.io/yourcompany/jobs/934823492
• jobs.lever.co/yourcompany/12321cd-9efd9-4621-a202-680932105c1

This is bad, because:

• The URL is often the first thing a potential applicant sees. This makes it feel a bit impersonal, since it’s not the company’s website.
• These systems are quite annoying to use. Applying through them is very tiresome.

As I’m writing this, I can already imagine some recruiters rolling their eyes. You might be thinking “I can’t even expect an applicant to fill out a basic online form?”. If this is the case, please keep in mind what kind of market you’re in. Remember that you’re selling. Remove all potential barriers and make things as easy as possible for your candidates.

General recommendations:

• Move the job descriptions to your own domain.
• Let the candidate apply through email (you can configure most applicant management systems to allow this).
• Don’t ask for a cover letter. They’re quite outdated and most people won’t bother to write one. Asking for one might still put people off from applying, so I recommend removing the field entirely.
• Show the human side of your company by including the name of a contact person.

Conclusion

Writing a great job description is a lot of work, but it really pays off. It will not only give you more applicants, but also increase the quality of your leads.

In the next post we’ll look at examples for great job descriptions. Have you seen a really good one or does your company have one? Send it to me via email!

Serious about hiring great software engineers? You might be interested in my book.

Buy the book