JD and JS Templates Are Not the Same Thing
Most people blur them together, then wonder why their hiring process breaks down halfway through. A job description is what you show candidates. A job specification is what you hand to your hiring team internally. They overlap but serve different purposes. Getting that straight cuts down a lot of friction before you even draft the first line. I've spent years watching companies paste the same template into every open role and call it a day. The result is always the same: candidates apply for the wrong job, interviewers ask the wrong questions, and someone hires the person who sounded confident instead of the person who could actually do the work. It feels fine on the surface until you're three months in and the role is failing.
Building a Job Description And Job Specification Template
Start with the job description. It needs five things: role title, department, reporting line, a short paragraph about what the role exists to accomplish, and a bulleted list of responsibilities. Keep the responsibilities actionable and tied to outcomes, not duties. "Manage the billing system" tells a candidate nothing. "Resolve billing disputes within 24 hours and reduce monthly dispute volume by 15 percent" tells them exactly what to expect. I've seen resumes filtered on phrasing like this because it reveals whether someone actually ships results or just occupies a seat. Then build the job specification as a separate section or a parallel document. This is where you list the must-haves, nice-to-haves, education, experience range, and any certifications or technical competencies. The tricky part is separating required skills from preferred skills. Too many templates list eight requirements under "required" and only two under "preferred," which effectively means there are no required requirements. Candidates read that as "I need to have all of these already," and qualified people self-reject. Flip it. Put three non-negotiables under required. Everything else goes under preferred, even if you really want it. I ran into a specific edge-case with a senior data engineering role where the specification ended up blocking perfectly capable candidates. The template asked for five years of experience with our exact stack: Spark, Airflow, dbt, Snowflake, and Kubernetes. Realistically, nobody had all five at the senior level in our market. We were getting maybe two qualified applications per posting. I rebuilt the template around outcome-based competencies instead. The new spec required demonstrated experience with distributed data pipelines and either Apache Spark or a comparable engine, plus familiarity with SQL at an advanced level. Tool-specific requirements moved to preferred. Applications jumped to fourteen qualified candidates within two weeks. The hire lasted four years and is still there.
The format matters less than the discipline behind it. Use a simple structure. Role overview. Responsibilities. Required qualifications. Preferred qualifications. Physical or logistical requirements if relevant. Salary range or band. Location and work model. That's it. Anything longer becomes noise. Noise is where bias hides. I've also seen companies add "company values" sections that read like marketing copy. Save that for the careers page. The template should be functional, not inspirational. Here is a working template structure you can copy and adapt: Role Title
Get the Full Details
Department: Reports To: Location / Work Model:
Salary Band: Role Overview One paragraph describing the purpose and primary outcomes expected from this role.
Key Responsibilities - Outcome-oriented bullet 1 - Outcome-oriented bullet 2
- Outcome-oriented bullet 3 - Outcome-oriented bullet 4 - Outcome-oriented bullet 5
Required Qualifications - Skill or experience the candidate must demonstrate - Skill or experience the candidate must demonstrate
- Skill or experience the candidate must demonstrate Preferred Qualifications - Bonus skill or experience
- Bonus skill or experience - Bonus skill or experience Physical / Logistical Requirements
- Any travel, on-call, or physical demands, if applicable Notes for Hiring Team - Evaluation criteria
- Red flags to watch for - Sample interview questions tied to responsibilities The last section is the one most templates skip, and it is the one that prevents bad hires. Without explicit evaluation criteria, every interviewer grades the candidate differently. One person cares about culture fit. Another cares about technical depth. A third is just waiting for the interview to end. You end up with a contradictory debrief and a hire based on whoever talked loudest during calibration.
There are downsides to this approach that people don't talk about enough. A well-written template takes time. If you don't have a dedicated HR operations person, this usually adds forty-five minutes to an hour per role during the initial build. The first one is the hardest. After that, cloning and adapting drops it to about fifteen minutes. But the upfront cost is real, and teams that rush it will produce generic templates that fail on the first real interview cycle. Another limitation: templates don't fix broken roles. If the position itself is unclear, over-scoped, or reporting into ambiguity, a detailed template just makes the confusion more formal. I've seen three separate job descriptions for what was effectively one role because two managers couldn't agree on ownership. No template caught that. Only a conversation about org structure did. The template surfaces role clarity; it doesn't create it. For companies doing high-volume hiring, a single template across fifty roles won't work. You need versioning. Version the template by level, not just by function. A junior analyst template and a senior analyst template for the same team should differ in responsibility scope and qualification depth, not just in title. Mixing them creates a mismatch where seniors get evaluated on junior criteria and juniors are held to senior benchmarks. Both directions produce bad outcomes.
If you want a downloadable version, most teams build theirs in Google Docs or Word and store it in a shared drive. I prefer a plain Markdown file with frontmatter metadata so it's portable across ATS platforms and easy to diff in version control. There are also open-source template repositories on GitHub that follow standard HR formats. Search for "job description template markdown" or "ATS-compatible job specification template" and you'll find several maintained by HR tech communities. Pick one, strip it down, and rebuild it using the structure above. Common mistake I keep seeing: writing the job description after the job has been open for two weeks. At that point, you're reverse-engineering from whoever applied or whoever you casually interviewed, which biases the requirements toward existing team members' skill sets rather than the actual work. Build the template before you post. Interview against it. Adjust only if the market consistently proves your required qualifications are unrealistic. Then update the template, not the posting mid-cycle. Another counter-intuitive point: include a line about what the role does not own. It sounds unnecessary until you see a candidate whose strength directly conflicts with an unwritten assumption about the job. One time, a fantastic marketing operations candidate declined an offer because after three interviews it became clear the role would mostly handle sales enablement documentation, which was never mentioned in the description. They assumed it was a growth marketing role. Everyone on the hiring side knew it was operations. No one wrote it down. A simple "This role does not own" section in the template would have prevented that misalignment entirely.
Salary transparency is now a legal requirement in many jurisdictions. Even where it isn't, omitting it is a trust signal. Candidates notice the omission. Including a band doesn't mean you have to negotiate below it. It means you save six rounds of back-and-forth on compensation expectations that would have ended the process anyway. Use this template, revise it after every hire, and track the delta between your required qualifications and what your actual successful hires ended up having. That track record tells you more about your hiring bar than any template ever will. The template is just the starting point. The adjustments are where the actual hiring quality lives.
