You spend hours sourcing. Hours more screening. But the first filter — the JD — gets written in 15 minutes, copied from an old role, and posted as-is.

Here's what nobody says out loud: a JD doesn't just describe the job. It's a filter that runs before you see a single CV.

A JD with 20 must-have bullets, stuffed with "fast-paced," "self-starter," "wears many hats" — it doesn't screen for the best people. It screens for the people willing to apply anyway.

And your strongest candidate — the confident one, the one with options — is usually the first to hit back. You never see them in the pipeline, so you assume they don't exist.

Why a "clean" JD still pulls the wrong candidates

The problem isn't the wording. It's deeper: a JD reflects the gap between what the team needs, what the hiring manager thinks they need, and what you actually filter CVs against.

A JD is a wish list, not a set of criteria

The hiring manager lists everything they'd love a candidate to have. React, Node, AWS, Kafka, fintech background, fluent English, startup AND enterprise experience.

Nobody on the current team clears that list. But you still take it out and start filtering.

The result: you're advertising for a perfect hire on an average-hire budget.

20 must-haves is a fence, not a door

The longer the requirements list, the louder the gatekeeping signal.

A strong candidate reads 15 must-haves, spots two they're missing, and self-selects out. Not because they can't do the job — because they have three other roles open and no reason to gamble.

Weaker candidates apply anyway. So your pipeline fills with people willing to submit, not people worth hiring.

Your "must-have" and the hiring manager's aren't the same

This is the quiet killer.

You think "5 years of Java" is a must-have. The hiring manager actually just needs someone who reads a legacy codebase fast — three focused years beats five scattered ones.

But because nobody sat down and weighed each criterion, you filter against what you guessed mattered. And you cut the wrong people.

A familiar one: a Senior Backend Java role, 12 must-haves on the JD. The strongest applicant misses exactly two lines — never used Kafka, no AWS cert. You cut them. Three weeks later the seat is still empty, and the person you cut has signed elsewhere.

Weigh the JD before you weigh the CV: the Split–Weight–Lock framework

The fix isn't writing a "better" JD. It's turning the JD from a paragraph of wishes into a weighted set of criteria.

Three steps. You can do it in a Google Sheet, no tooling required.

Split

Tear the JD into three clean buckets:

• Must-have: missing it means out.
• Nice-to-have: having it earns points.
• Bonus: nice surprise.

Hard rule: no more than 5 must-haves. If you have 12 "required" lines, you haven't sorted — you're wishing.

Weight

Assign a weight to each must-have. Not every criterion carries the same load.

For example:

• Reads a large Java codebase fast — 40%
• System design thinking — 30%
• High-traffic experience — 20%
• English communication — 10%

Now a candidate missing an AWS cert but strong on the top three still advances. Because you're filtering by weight, not by a binary pass/fail checklist.

Lock

Sit with the hiring manager for 15 minutes. Point at the weights and ask: "Is this really worth 40%, or are we guessing?"

That one question surfaces every buried assumption. Usually the HM says: "Oh, Kafka's just nice-to-have — two weeks to pick up." And you've just saved five good candidates from getting cut for the wrong reason.

A good JD isn't a well-written one. A good JD is one where you and the hiring manager agree on what actually matters — and how much.

The Knoot Angle

In recruiting, every downstream decision inherits the quality of the first one. If your filter is already skewed at the JD stage, faster screening just helps you reject the wrong people faster.

That's why Knoot has a JD Analyzer module — and it doesn't write the JD for you. It does the opposite: it takes the JD you already have and breaks it into a structured set of criteria.

• Automatic sorting: the JD gets split into must-have, nice-to-have, and bonus, instead of one hard-to-filter wall of text.
• Visible weights: every requirement carries a percentage — you see at a glance what actually decides the hire and what's just a wish.
• You keep the edit rights: the AI proposes, but the recruiter and hiring manager set the final weights.
• It feeds screening: those weighted criteria become the input for CV screening — so you're never filtering blind.

JD Analyzer doesn't decide who fits. It just makes sure you and the hiring manager are filtering against the same ruler — before the first CV ever lands.

A JD is a wish list. Your job is to turn it into criteria you can actually measure — before it quietly screens out your best candidate.