Compelling job specs

The quest for the Holy Grail

A job spec that developers relate to is a rare sight.

I was chatting with an acquaintance that works in the recruiting space, about the never-ending battle between good an evil that is the relationship between recruiters and developers. The conversation got interesting when he said this:

I am not sure our job specs are very good.

At that point, I had a fleeting recollection that while on Twitter, I stumbled on the Zapier jobs page. Specifically I had a look at the Product Engineer spec. I also took a screenshot of the spec, for when they find their perfect candidate and the page gets removed!

I am always wowed by the quality they show in their job specs.

Ease the application process

Zapier understands that even applying for a job can be daunting. This passage sums it up:

We know applying for and taking on a new a job at any company requires a leap of faith. We want you to feel comfortable and excited to apply at Zapier. To help share a bit more about life at Zapier, here are a few resources in addition to the job description that can give you an inside look at what life is like at Zapier. Hopefully you’ll take the leap of faith and apply.

I think this is great. Having stuff like a company code of conduct, a remote work policy, and/or a description of what the day to day of what working for the company looks like, can be beneficial to the amount of applications you’ll receive.

Lay out the challenges

If your company works on something interesting and unusual, let that emerge. Interesting problems can range from GIS, to machine learning, to simply scale up a part of the system the candidate will be working on.

Specify what processes you use on your day-to-day: how invested is the company on practices like TDD or pair programming? What’s your current stack? Do you plan to change what the stack is made of in a few months/years?

No “bullet point” requirements

Many specs will list in a very dry way what they expect the candidate to know or be experienced with. Zapier explains in a nice way who they’re looking for, hot what they’re looking for.

Hard requirements can sometimes be intimidating. Many good developers are often on the “bad” side of the Dunning-Kruger curve. They will see that 3 years of experience are required, and if they have 2 years of experience they will not apply. We’re pedantic, keep it in mind.

Zapier also helps with this:

Regardless of how well you feel you fit our description, we encourage you to apply if […]

Again, when you hire someone, they’ll shape the position more than the position will shape them.

It’s not about the employer

No need to loiter too long on what the company does; if I’m on the page it’s quite likely I know about the company already. Much better to talk about the company’s philosophy, and what happens at the company outside of working hours. A list of social events, a description of a day at the office (or on the Slack channel, if 100% remote); things like these can give a picture about the culture, and can give a strong signal to the candidate on whether the company is a good fit or not.

A good candidate will do their due diligence anyway, learning as much as possible about the business.

GitHub is a bad source of truth

Zapier takes a sensible approach to open source contributions from the candidate:

Include links to your portfolio/Github profile or provide us with 500+ LOC to help us get a feel for how you write code.

If the candidate is active on OSS projects, good. Otherwise Zapier also accepts a sample. This is crucial.

Most developers, unfortunately, work in environments that take a lot from open source but don’t contribute back as much as they should. This means that developers don’t build up an OSS portfolio during working hours. And they may not be in a position to come up with weekend projects: they may have a family to be with, or simply they may have a slew of interests and can’t be bothered to code during their spare time. That doesn’t subtract from what kind of asset they can be for your company.

tl;dr

So, to sum up:

• Show what the company is like, not what it does
• List what challenges the successful candidate will have to tackle
• Talk about the candidate more than you talk about the company
• Don’t use hard requirements, e.g.: years of experience; give an idea of what you’re looking for instead
• Don’t filter based on the GitHub profile

Hope this helps. Let me know in the comments if you have other things you look for in a job spec!