Job descriptions for developer roles rarely tell you what they should. The whole point of them is to provide a candidate a description of what a position is like. I’ve looked at close to a thousand job descriptions and have helped write a few. Job description writers, including me, have a tendency to come up with something “safe”. We fill job descriptions with text that sounds great, but says nothing tangible. We ask for candidate attributes that sound good, but may not actually indicate how well a candidate would actually do on the job. Most importantly, we put in things that EVERY OTHER company would also put in their job descriptions. In our desire to appeal to the largest number of candidates possible, we also make it difficult for candidates to differentiate between different companies.

Candidates are always advised to make their resumes “stand out” to increase their chances of landing an interview. Companies should take that same advice.

I have paraphrased a description of a company from an actual job description:

Based in Manhattan, {Company X} is a fast paced internet company committed to building the best web and mobile products to do awesome in {Industry X}.

Who isn’t committed to building the best web and mobile products? Or at least, who wouldn’t say they are? Other than stating the industry the company is in, this uses a lot of words to say very little.

This is from a different job description:

Great outcomes are everything. It’s what drives us to turn bold ideas into breakthrough solutions that solve the toughest problems fast–the first time. So you can change how people work and live.

This is all fluff. The paragraph can be attached to any job description at any company in the world. It may as well be “Come work for us! We do things and people pay us for it.”

Another description:

{Company X} pioneered {Industry X} by bringing great {Product X} to people around the world. Life at {Company X} is about more than making {Product X} though. It is about positively impacting everyone’s lives by creating innovative, next-generation {synonym about Industry X} experiences. Come join us in creating the future of {synonym for Industry X}.

A lot of words, a lot of fluff. None of this says anything about why I should work at this company versus another company in that same industry who will be saying the same thing. If only one company said stuff like that it may have meant something. Yet every company does it and the statements become meaningless.

From my last job search I can also guarantee you will find over a dozen companies that say “We are a different kind of agency.” Those are the exact words I saw over and over. Once again, if one company said it, the statement may have meant something. When a dozen do it, the statement becomes meaningless.

Descriptions about the actual role are not much better.

We are looking for Software Engineers who want to write great code and help build a team.

This is sure to deter the Software Engineers who want to write terrible code.

You will work within a small, agile team of smart people and solve problems from beginning to end: everything from product conceptualizations to engineering implementations.

But I want to work in a large slow moving team with mediocre people! And I would love to be pigeon holed into very specific problems.

We use Scala, PHP, Clojure, ElasticSearch, Java, and ActiveMQ on the back end, and JavaScript, React, Flux, HTML5, and CSS for the front end.

So what technology will the candidate be working in? I’d also be very impressed if they weren’t using HTML5 and CSS in a web product considering browsers require them.

We are an engineering driven organization and we are proud of our engineers. Come join them!

Thank goodness. Every other company is ashamed of their engineers.

Let us not forget the laundry list of responsibilities that amount to “duh”:

• Developing software our users need
• Resolve problems with software and respond to suggestions for improvements and enhancements
• Making informed decisions quickly, and taking ownership of services and applications at scale
• Staying on the leading edge of development practices
• Passionate about great technologies
• Troubleshoot production problems related to software applications

This one is my favorites:

Design, develop, enhance, debug, and implement software

What a novel responsibility for a software engineer.

I easily point out the absurdity of these descriptions, but not without a little bit of hypocrisy. I have written similar things in my past. The problem is that these general statements also appeal to the widest number of people because they are so general. Hiring software engineers is extremely difficult and companies want to make sure they aren’t ruling anyone out. That is why I said these types of descriptions are “safe”. They apply to everyone so theoretically, everyone can apply to the job. Yet, since every company has a similar description, these are completely meaningless. Candidates have little clue about the type of organization they are joining. They go into interviews knowing only the product the company makes and the job title. Sometimes it is hard to even figure out what kind of product a company makes!

I was asked recently to review a job description that looked like one of these. I gave the feedback that it was fine in that it looked like every other job description so it wasn’t wrong. It just didn’t stand out. I don’t have perfect answers for solving this problem, but here are a few ideas that I’ve been thinking of:

• Describe WHY a company was started with specific examples. Stay away from terms like “We wanted to improve Industry X” and go with “We have seen people hit problem X, problem Y, and problem Z in Industry X. Our company fixes it because our product does X”
• Why does the world need you company to be successful? What specifically do you want to happen? The person I talked to wanted to prove that you could pay people decent wages and still be successful in an industry notorious for taking advantage of workers. They were going to use technology in a way no one else had thought of.
• Describe some specific projects that a candidate may actually work on! The excuse for not doing this is usually that it is hard to know what a candidate may work on since they will start weeks or months after the job posting. EVERY company has a backlog that’s months if not years long. It shouldn’t be hard to pick a few things.
• Managers like to ask their directs what they want in 5 years. What about having companies describe what they expect a candidate to be able to look back on 5 years from now if they joined?
• Every company lists competitive salary as a benefit (even the ones that are notorious for underpaying staff). How about something more important: have the potential manager write about their management style and how they will help a candidate grow their career.
• Have some of the existing team members write about things they have learned while working at the company.
• Candidates like to ask “what is a typical day like?” in interviews. It is a terrible question because days are rarely typical as a software developer. However, that doesn’t mean some of the existing team members can’t describe a handful of days they had such as first day, 30th day, a day in the past week, etc.

These are the types of things candidates would ask in an interview anyway. However, time is finite! Software engineer interviews are long affairs, often 4+ hours. That is a big investment for a candidate and a company. A better job description will help match candidates and companies who fit each other better.