Tagged: job postings

How to READ a Job Posting

After reading a recent article on DZone about writing developer job postings I started thinking about how job seekers often read and sometimes (mis)interpret job ads. At least once every few days I encounter some rant about how unrealistic job postings are, whether on a so-called Entry-Level Job that actually requires three years of experience or a spec that appears to seek an entirely unrealistic collection of skills. Must have ten years of experience with Node.js is coming to a job ad near you!

As someone who writes job descriptions for companies, I’m not here to defend those in the industry who use a highly exclusionary style that can be off-putting for many job seekers. Until some spec writers learn to do a better job of representing what makes for both an exceptional candidate and an acceptable candidate, I think it is important that readers understand how to interpret what is written to make the best judgment on whether to take the time to apply and to further set their own expectations properly regarding the likelihood of a positive response (interview).


Some key considerations when reading a job post.

Postings (Like Resumes) Are Written With SEO in Mind

You know how some people pepper their resumes or LinkedIn profile with popular buzzwords in hopes that some recruiter will be searching for that term? Well, people writing job specs do the same thing, and writers will include what we might call complimentaryskills listings without those skills actually being considered as a requirement. A Clojure shop might include “Haskell” and a company using Redis might list “MongoDB” somewhere in the posting, as we can’t expect every functional programmer or NoSQL enthusiast to only be searching for their particular stack. Maybe the “ideal” candidate is an expert in Clojure and Redis, but the company doesn’t want to miss out on the Haskell developer either.

Postings Represent “Ideal” Candidates

In most cases a job posting is an elaborate wish list with several requirements and nice-to-haves, but hiring managers or recruiters generally don’t expect candidates to be able to check off every box from the list. Technology hiring varies greatly between companies, and in my career I’ve consulted to companies that demanded at least n years with a specific framework as well as firms open to hiring engineers with programming experience on any stack.

Non-negotiable Requirements Should be Fairly Obvious

In most cases, writers of job specs will be explicit about requirements that are truly required. There will always be companies that believe four years of Java experience is inadequate but five years is just right (without even considering how we try and justify what a year of experience even means), but most shops will show flexibility on items where years of experience is listed. It’s probably a waste of time to apply for positions with more binary requirements, such as those involving citizenship, education, or a required certification.

Look for the Gotcha

Over the past few years job post writers have attempted to verify that an applicant actually read the full post by including some obscure directive in the post. Please include your salary requirement and favorite color in your cover letter.

Format, Focus, and Culture

Readers of job descriptions should be able to draw some conclusions about the hiring company based on the format of the job spec and what content the writer chose to include and emphasize. Companies advertising for a Software Engineer IV vacancy that dedicate multiple paragraphs to describe employment policies and procedures may be more likely to have a regimented environment when compared to job specs that instead choose to include the core values of the development team.

Job postings are an opportunity for a company to both describe an ideal candidate and explain why readers might want the job. The way an employer chooses to use the space may speak volumes about how the company sees itself and how they want others to see them.