Uncharted Waters

Mar 25 2018   10:09PM GMT

Building Job Descriptions

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
IT careers
IT jobs

Most of the job descriptions I read are either in the form of a job advertisement, or a job description on an internal wiki. Neither are particularly helpful. In the past, I have either avoided applying because the ad listed every skill on earth when what they really needed was a junior. Or, I ran forward and applied to advertisements that were completely understated and well out of my skill range. Bad internal job descriptions can be used like a sword when it comes time for skill assessment and review.

Getting these right always feels like an impossible chore with not a lot of upside.  I like to focus on two areas with these, skill and culture.

Let’s debug two types of job descriptions. The first is completely sparse. It will say something like “be proficient at test automation”. If I skim the sentence, it seems reasonable, but when I read it again I have no clue what the company currently does, actually wants (or thinks they want), or what they might actually need. The other type is the over-communicator. These list every single technology stack that was ever touched at the company, and then shoots for the moon by asking for a host of skills they don’t have or know what to do with.

job descriptions

I like to start with the longer version, and whittle it down to the real guts of what a company is looking for, or what they actually do. I have some experience around testers, so I’ll start there. If you want a tester that can explain the testing they have done, what they need to do, and where they they have questions, ask for that. If you want someone that can write the full BDD stack (Gherkin, step files, and PageObject), just say that. If you want a person that has experience, or is at least willing to try, working in a highly agile environment that doesn’t do hand-offs between rolls, ask for that. I tend to avoid things like asking for ‘good communication’ or ‘team player’ either because they can’t be assessed, or they are just a given.

And then we come to the things that surround the job.

In general I like to avoid references to culture in internal or external job description. Culture and your value system will shine through in everything else. For example, one local start up I worked at a few years ago had a heavy emphasis on fitting in with their development group. They were a small, tight knit team and were scared of idea of someone making waves. Most of the developers were into the same thing — working on personal development projects, beer, and video games. The job advertisement filtered on these things. Generally this results in a room full of people that look and think the same. We ended up with a product that wasn’t particularly interesting or special. This wasn’t entirely because of the homogenous development group, but that certainly didn’t help things. Emphasizing ‘culture and team fit’ in my experience are diversity and inclusion (D&I) killers.

Job descriptions don’t have to be perfect, but they do need to actually represent what happens on the job. Being way off means you are either attracting the wrong candidates to open positions, or are doing bad performance reviews and skill assessment.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: