Writing Job Descriptions That Actually Work
Most job postings are ignored before the candidate even finishes reading them. I spent about three years managing hiring for a mid-size company, and we processed roughly forty roles a year. The ones that converted well followed a consistent pattern, and the ones that bombed almost always shared the same flaws. You don't need anything fancy to write a job description that gets results. You just need to stop doing the things everyone else does wrong. Start with the Sample Job Description Template skeleton, which is simpler than most people make it. Here is the structure I used repeatedly and it held up across engineering, operations, and marketing roles. Job Title first, stated plainly without corporate titles like Ninja or Guru. Then a two-paragraph overview of what the person will actually do day to day. Follow that with Required Qualifications and Nice-to-Have Qualifications, clearly separated. Include compensation range, location, and work arrangement. End with a short paragraph about the team and what makes the role different from similar openings at other companies.
I learned this layout through painful iteration. In 2022 we posted a senior product manager role with a six-paragraph company history section at the top and the actual responsibilities buried on page two of the posting. We received two hundred applications and only three were qualified. Two of those three had clearly copy-pasted their cover letters because the job description made no sense. We restructured the posting the same week, put the role details first, and qualified applicants doubled within a month.
What Actually Moves the Needle
Compensation transparency is the single biggest factor in application quality. When I included a salary band in our postings, the number of unqualified applications dropped by roughly sixty percent, and the time-to-fill decreased from about four weeks to two and a half. Candidates self-filter much faster when they can see the numbers upfront. Not every candidate wants full transparency, but the filter works. The Required versus Nice-to-Have split matters a lot too. I see too many postings that list ten required skills and then act surprised when only three people apply. A realistic posting for a mid-level role should have roughly five required qualifications and maybe five nice-to-haves. If you cannot separate them mentally while writing, you are probably writing for a unicorn, not a human being. Day-to-day responsibilities should be specific enough that someone can picture Tuesday morning. "Manage cross-functional projects" tells me nothing. "You will run weekly sprint planning for a team of six engineers and coordinate launch timelines with the product and marketing leads" tells me exactly what the job is.
Get the Full Details
Common Mistakes That Waste Time
The most expensive mistake I saw was listing degree requirements as mandatory when they were not actually necessary for performance. We had a software engineer opening that required a bachelor's in computer science. We also had two excellent hires who came from bootcamps and self-study paths. By keeping the degree requirement in place, we excluded a real talent pool. Removing it cut our time-to-fill by about a week and improved the quality of final candidates noticeably. Another mistake is writing the posting in isolation. I once had a hiring manager fill out a template from our HR system without consulting the team that would actually work with the new hire. The resulting posting described responsibilities that nobody on the team wanted to do. We pulled the posting after ten days, rewrote it with input from three team members, and got legitimate interest within forty-eight hours of relaunching it. Sometimes a template approach fails completely. For highly specialized research roles or executive positions, a standard sample job description template does not work well. Those roles require custom writing that reflects the specific strategic context. Trying to force a template into that situation produces a generic posting that attracts generalists, not specialists. In those cases, write from scratch and only use templates for roles with recurring responsibilities.
Practical Tips for the Writing Process
Keep the total word count between three hundred and six hundred words. Anything longer and candidates stop reading. I timed this a few times by having new team members scan recent postings. Most stopped paying attention after the fifth or sixth block of text. Shorter is fine as long as you include the essential sections. Avoid jargon unless your audience speaks that language naturally. Internal project codenames, deprecated tool references, and acronyms that only exist in your company create unnecessary friction. A candidate from another company should be able to understand the role without calling a friend who works at your organization. Include equal opportunity language at the bottom, usually two or three sentences. It is a legal requirement in many jurisdictions and a standard expectation from candidates. Do not skip it because you think it is boilerplate fluff. Missing EEO language can trigger compliance issues later.
A Word on Tools and Automation
Most applicant tracking systems have built-in job description builders now. Greenhouse, Lever, and Ashby all offer template features. They are useful for maintaining consistency across multiple open roles, but they tend to produce dry, safe writing. You still need to edit them heavily. I treat the ATS template as a starting framework, not a finished product. If you want something faster, I keep a personal master document with reusable sections for common roles. A standard engineering posting, a standard marketing posting, a standard operations posting. When a new role opens, I copy the relevant master, adjust the specifics, and spend about twenty minutes polishing it. The whole process, from first draft to published posting, usually takes less than forty-five minutes. Without a master document, the same task took me closer to two hours because I was rewriting the same sections over and over. Templates save time but they do not replace thinking. The structure is easy. The decisions about what to include, what to omit, and how to phrase requirements are what actually determine whether a posting works. Spend your energy on those choices rather than on formatting.
When to Skip the Template Entirely
There are situations where a custom posting outperforms any template. Senior leadership roles, niche technical positions with unusual skill combinations, and roles tied to new product launches all benefit from tailored language. A template assumes familiarity with the role. When the role is genuinely unfamiliar to the market, you need to explain it clearly instead of relying on stock phrasing. I ran into this problem when we hired for a machine learning infrastructure role that did not match any existing title in our industry. Candidates kept applying to the wrong jobs because our posting used standard ML engineer language. We rewrote the posting with a custom title and a detailed explanation of what the work actually involved. The applicant quality improved immediately, and we filled the role in three weeks instead of the usual six to eight. Most roles do not fall into that category. A well-structured sample job description template handles the majority of hiring needs efficiently. The goal is not to write something unique every time. The goal is to write something clear, accurate, and honest, and to stop adding the decorative language that makes postings harder to read without making them more appealing.
