Job Description

At ten people a company doesn't really need one. Someone says the team could use another engineer, a few messages go out to people they've worked with before, and what the job actually involves gets worked out in conversation. There is no document describing the role because there is always somebody around who can describe it.

The gap shows up the moment people who don't know the role start making calls about it. Once there are three interview rounds and four interviewers, the same candidate produces a split verdict: one interviewer says they can't design a system, another says they ship quickly so it's fine. Neither is wrong. The meeting drags because nobody wrote down whether this role is supposed to design systems or ship quickly, so there is no basis on which to settle it.

A job description (JD) exists to fix that standard in one place before any of it starts. It doubles as the thing candidates read, but the reason to write it first is to stop the hiring side from walking into interviews with four different pictures in their heads. Drafting it forces the question of what this person is ultimately here to do, and without that agreement every later step runs on whoever's private criteria happen to apply. That is also why the document gets written before the role is posted rather than after candidates start arriving.

Most job descriptions are five blocks, usually in this order.

1. The company and the team. What the company builds and how many people the new hire would sit with. This is what candidates read first when deciding whether to keep reading, so what problem the team is working on right now lands better than company history.
2. Responsibilities. Three or four lines on what the person will actually do. Not "product development" but "rebuild the checkout screen and bring down payment failure rates" — each line specific enough to be a task, which is what makes the section useful later.
3. Requirements, split into required and preferred. Required means the work can't start without it; preferred means it helps someone get up to speed faster. A posting with eight required lines is almost always one where nobody separated the two and every wish went into the top list.
4. Terms. Employment type, location and remote policy, job level, and salary range. A job level is the grade a role sits at based on scope and responsibility, and the same job at two levels comes with different expectations. More companies publish the range now for a plain reason: leaving it out means both sides spend weeks before discovering the numbers don't meet.
5. The process. How many stages there are from resume screen to final interview, and roughly how long each takes. Any take-home assignment is disclosed here, because deciding whether to apply includes deciding whether to spend that time. Candidates who find out about a two-day assignment in week three tend to drop out then, after both sides have already spent the weeks.

The writer is the hiring manager — the manager who actually needs the role filled and makes the final call. Some companies have a recruiter write it instead, and the responsibilities section then fills up with sentences that could describe any team anywhere. The recruiter's real job is the pass after the draft: matching language across postings, checking the salary range against the company's own bands, and removing wording that could read as discriminatory.

Three groups read it, and each reads a different part.

1. Candidates read responsibilities and salary range, then decide whether to apply. For anyone contacted through sourcing, this document is also their first real description of the company.
2. Interviewers pull their criteria from it — what to filter on during resume screening, what to probe in the technical interview. The three lines under required requirements become the three things the loop verifies.
3. Recruiters reopen it first when applications aren't coming in or nobody is passing. They check whether the requirements are steep relative to the market and whether the posted range still matches the pay band.

"Let's rewrite the posting. As it stands every interviewer is evaluating something different."

The problem isn't a shortage of candidates, it's that nobody agreed on the bar.

"Is this really required? Feels like it could move down to preferred."

A proposal to loosen a condition and widen the pool of people who can apply.

"The salary range in the JD is last year's. Get it updated before this goes live."

The document is about to ship contradicting the actual terms.

When Pagedeck opened its first sales roles, Sofia wrote the draft. The block Grace spent the longest on was responsibilities. The first version said "enterprise sales," one line, which settles nothing about what an interview should confirm. Only after they worked out whether this person responds to inbound interest or goes after companies who have never heard of Pagedeck did that one line become three, and those three lines became the interview questions.

A posting isn't written once and left alone either. After three weeks brought in six applications, Grace went back to the requirements instead of promoting the role harder. Two of the five required lines moved down to preferred, and the next two weeks brought more than twenty applications.

The most common mistake is reading a job description purely as advertising. Candidates are the visible audience, so it follows that a well-written one attracts more people, and it does. But the larger use of the document is on the hiring side, where it's the agreement that sends four interviewers in with the same three lines. Treated as advertising alone, it comes out smooth to read and silent on what to verify, interviews end without converging, and the role takes two extra months to close.

On the applying side, the frequent mistake is reading required requirements as a cutoff. They say required, so missing one feels disqualifying. In practice several people's wishes get folded into that list and it lands higher than the real bar, and the hiring side isn't expecting someone who checks every box. This one is expensive because the person doing the filtering is you rather than the company. Submit and someone else makes the call; opt out and the call never happens. A useful way to read the list is as a description of the work rather than a scorecard: if the responsibilities section describes something you could plausibly do, the requirements below it are context for how the team got to that list.