Write Job Descriptions To Which Developers Will Respond
The other day someone sent a job posting to a San Francisco Ruby developer mailing list I’m on. This isn’t unusual: it will surprise nobody that Ruby developers are much sought-after, so the folks on the list are accustomed to seeing plenty of job postings come through. Some of the worse ones have sparked memorably inflammatory responses.
This particular posting wasn’t a terrible one, but neither was it good. Primarily, it missed the point, calling out the perks without describing either the company or the job. It irritated me slightly, but more than anything it set me to wondering why people seemed to find it so difficult to write a job description that will truly appeal to developers. I’m somewhat guilty myself: I’ve hired a lot of developers over the years, and while I try to make descriptions useful, I know I could also do better.
This posting spurred me to write a reply to the list, which I tried to make constructive, not about the specific posting, and more than anything, hopefully useful. Based on the responses I got from developers on the list I struck a chord, so I decided to restructure it a bit and post it here, as a list of suggestions, from the point of view of the “awesome developer” you’re hoping to hire.
Make Your Company Compelling
The single most important thing any job notice should say is what the company’s goals and vision are. Make this your central message, and make it up-front and clear. It’s really important these days to remember that good developers can take their pick of dozens upon dozens of interesting (and not-so-interesting) startups, so it’s up to you to make a pitch about why spending time at your company will be fulfilling. Are you helping people? Building the solution to a big problem? Just doing something super-fun? Say so: sell the reader on your mission and vision.
Perks Are A Dime A Dozen
Every startup out there offers a number of perks from the seemingly endless list on offer. I can’t say that developers don’t care, but it’s almost true. Wherever a good developer goes to work, there will be perks. Leading a pitch with your free food and great view is not the way to sell an opportunity. Free food is not a big deal anymore. Neither is a foosball table, open bar Fridays, free Uber rides, TaskRabbit, or whatever the latest perk is.
If You REALLY Have A Special Perk?
That said, if you really have something unusual, sure, it’s worth highlighting if it’s a material difference from most companies. 4-day weeks, ability to work from anywhere in the world, bonuses to take a vacation — those sorts of things are obviously good to mention, but not as the highlight of your posting.
The Work Is More Than Just A Role
Most role descriptions are too generic. Every Ruby position involves “enhancing back-end infrastructure” and “server-side to user-facing features.” It’s better to hear about what kind of features; what’s the application for; who uses it? What will the developer actually be building, and why does it matter?
Even more important is how the role functions as part of a team. Will this developer make architectural decisions, or simply build what they’re told to build? Will they iterate side-by-side with a cool product manager? Will they deploy code every day? Will they get to spend time writing tests and coding good stuff? What’s the team like?
Describe The Team
I’ll repeat that last one: what’s the team like? How big is the company, how many devs do you already have, are there mentors available for folks more on the junior side? Maybe one of your senior developers is well-known for some cool open-source project? Working with a good collaborative team is the single most important aspect of any dev job. The more info there, the better.
Be Honest About Commitment
When a developer reads an entry like “Ability to tackle challenging problems on a tight schedule”, that’s taken as code for “You’ll be working twelve-hour days”. Just come out and say that the developer will have cool work, but will put in long hours. If that’s not the reality, then phrases like these do you more harm than good. Every startup job description in SF says something like this, so it’s generally just ignored. The commitment expected should be up-front and clear. That way if a developer’s not into it, there’s no need to waste anyone’s time, which is good for you, too.
Put Yourself In Their Shoes
Lastly, anyone writing a developer job description should take a step back, pretend to be a really good developer (like the ones you want to hire), and see what they will see. Imagine that you can quit your job today and find a new one within 48 hours if you have to. But you’re already being paid well, you have lots of perks, a nice MacBook Pro and a giant monitor (or two). What might you be dissatisfied with that could entice you to contact this company about their opening? It’s not perks, it’s not money — it’s going to be environment, team, more interesting technical challenges, learning opportunities, a company that’s doing something that feels more worthwhile. If this job description is going to attract those excellent developers, then it has to sell on those points, or it will only attract the developers who aren’t as good, or are simply mercenaries looking for a bigger paycheck or more free food. And you don’t want them.
In Closing
Much of this might seem like common sense, but as I mentioned at the beginning, I’ve also been guilty of resorting to the bullet-point list of desired skills and not stressing the important stuff. It’s time-consuming, when you just want to get the word out. But if you want to get the attention of the talented people (I’m sure this doesn’t only apply to developers!), you need to put in the extra effort. As we all know, there’s nothing more important than hiring the people you need. I hope this is helpful even if it’s no more than a reminder for you to look again and make sure you’re putting out descriptions that communicate why you’ve got a great opportunity worthy of attention.
