Why Engineers Hate your Job Specs

How to weaponize your shitty job postings

One of the main problems I see today in software engineering hiring is the way job specifications are written. The problem is, they often barely resemble specifications at all, but feel more like generic stabs in the dark. Sort of like the equivalent of shopping for a car with as many details as “red and goes fast.” It leaves too much open to the imagination for it to be a successful criteria to empower a search. With criteria as broad as this you’ll end up spending an inordinate amount of time executing the search since so many things appear to be a match.

The truth is that statements like the above — or its equivalent in engineering hiring — “Get me a Python/Ruby/Java/OO engineer w/ 5 years experience” — guarantee a similarly frustrating shopping experience. You’ve made it needlessly difficult for yourself to identify the specific talent you want. In this trite (but surprisingly common) example you’ve indicated that you’re looking for a mid-level engineer that knows OO, but that basically includes everyone that ever graduated with a CS degree in the past 5 (to 10?) years. Astoundingly, many job “specifications” I see contain scarcely more info. I call these Shitty Job Specs.

How did we find ourselves in this mess?

I understand why hiring managers do this. Sometimes they’re not exactly sure what they want — after all, it takes real time and effort to work out the specific vision for the role. But instead of acknowledging this and then solving the real problem (their own laziness), they outsource the spec writing to HR and it turns into generic technical mush. But the hiring manager is undaunted — “I’ll know the right candidate when I see them,” they say. Really? How will they know the right candidate if they can’t write down specifically what the candidate looks like?

Another reason for generic job specs is due to the fact that a hiring manager is recruiting in a talent-constrained market (sound familiar?), and it feels like a smart move to cast as wide of a net as possible. Theoretically, one should be able to get more candidates into the top of the funnel this way, right?

Perhaps. Theoretically. But in my experience, this approach usually, and utterly, backfires. Here’s why:

Shitty job specs aren’t designed to appeal to any engineer in particular

In the current job market, engineers are faced with a plethora of options from some amazing established companies and lots of seemingly sexy startups. You need to make your opportunity stand out! The more specific you are about the challenges a specific engineer will get to work on in a specific role, the more traction you’ll get with candidates.

The idea is to make an engineer’s eyes light up when you describe what they *get to do* in the first 12 months in the role. Be specific, talk about the tools they’ll use (or get to choose), what’s hard/challenging about the role, why they should see themselves as a great fit? The more details you can squeeze into the spec to help them actually visualize their role and the projects they’ll be working on the better.

Shitty job specs don’t arm others to help you

Another bad thing about generic job specs is that they don’t help others help you. Think of how much combined reach you get via using everyone in your network as a recruiter. But *everyone else* is already asking them if they know any Python engineers. Why would they help you? Because you’ve taken the time to get specific about what you want — and perhaps you’ve even put some personality in your spec (huge bonus points here).

Make them *want* to help you — give them a job spec that’s so amazing, well-written, specific, even entertaining — that they can’t help but pass it on, post it, tell their friends about it, etc. If you make it pop — you’ll get more attention from the folks that can help because you’ll arm them with something interesting & effective that they can use to reach out to their network.

Shitty job specs don’t enable you to know what success looks like

This is a very simple point — see above — if you can’t explain what the ideal candidate looks like, how will you know when you’ve found them?

The main idea here is about not being willing to settle for less. I realize the market is tough out there right now, and maybe you’ll need to make compromises. But why start off with at the wrong end of this spectrum? When you go out the door with a generic spec, you preemptively give up the battle. If you need to settle — fine! — but know exactly what points you’re compromising on.

The larger problem is that if you don’t know what the best candidate really looks like then the other people involved in making a decision likely don’t know what he/she looks like either. A well-defined, specific description of the role enables everyone involved in the interviewing and hiring process to be on the same proverbial page.

Now go get started!

Fixing your job specs will take some work. To get specific, you’ll need to dig in and make additional efforts. You might also need to do some retraining in your organization and teach others these principles, too.

But when you get through the hard work, your postings will turn into valuable weapons that will a.) appeal to the engineers you want to reach, b.) enable others to help you expand your outreach, and c.) get your hiring team on the same page to quickly come to the right decision.

I plan to continue this post with a series of posts on additional specific steps you can take to improve your specs, so stay tuned. We’ll also continue to critique other shitty (and good) specs, too, since examples can often teach more easily than words.

If you’re curious to see some of these principles in action here’s an example of a recent job spec that I wrote for a Rails Engineer at my startup:

http://www.hakkalabs.co/jobs/hakka-labs-full-stack-rails-engineer