Test Your First Job Description Before You Post It
A founder making a first hire, or a first hire in a new function, has one decision before posting: run the job description as drafted, or test its language, requirements, pay framing, and company pitch against a precisely defined target-candidate audience. Getting this wrong is expensive: a flooded pipeline of irrelevant applicants buries the handful of candidates who would have been a fit, and the hire that was supposed to unblock the business stalls instead. Job postings and candidate search are a matching problem, and matching frictions carry a measurable cost in time and quality of match (NBER: Job Postings and Labor Market Matching).
Why job descriptions fail in predictable ways
The real issue isn't writing quality. It's a founder's-eye view standing in for the candidate's.
A founder writes what the company wants. A good candidate scans for what they will get. That gap explains most of the failure modes:
- Buzzword overload. "Ninja," "rockstar," "wearing many hats." Strong candidates read these as "the role isn't defined yet."
- Too many requirements. A list of 15 must-haves turns away exactly the senior candidates it's meant to attract; five would filter as well without the drop-off.
- No sense of the company. Stage, headcount, funding, and how rough the scope is stay unstated, leaving strong candidates unable to judge fit.
- Pay opacity. "Competitive salary" pushes top candidates toward whichever competitor published a number.
- Mismatched tone. Copy that leans hard into startup swagger scares off operators; copy that reads corporate scares off builders.
A founder cannot see these problems until the pipeline dries up, and by then the posting has turned away the candidates it needed most.
The traditional fixes are slow and hard to validate
None of the standard options return a fast, falsifiable answer before the posting goes live. Labor-market conditions for job seekers and employers keep shifting, so an untested assumption about what a candidate wants can go stale quickly (SHRM: State of the Labor Market).
| Method | What it tells you | Main limitation |
|---|---|---|
| Hire a recruiter | Market judgment from someone who places roles like this regularly | Retainer cost, plus a ramp period before the first candidate shows up |
| Ask your network | A handful of honest opinions from people who know you | Small sample, and friends rarely say the requirements list is scaring people off |
| Post it and iterate on real applicants | Real market signal, eventually | The bad signal (irrelevant volume, silence from the candidates you wanted) arrives after the posting is live |
| Run a controlled comparison against a target-candidate audience | A direct read on whether specific candidate segments would apply, and what stops them | Does not replace an interview, real applicant behavior, or compensation benchmarking data |
How a controlled comparison works
Subconscious runs controlled experiments that compare job-description variants (the requirements list, the pay framing, the tone, the company pitch) against a precisely defined target-candidate segment, and measures which version changes stated interest and intent to apply. That isolates which specific change moves the segment's stated intent, not general impressions of a draft.
Hiring a first marketer aimed at a defined segment, say mid-career B2B SaaS marketers at a certain funding stage, gets tested against that segment, not a generic reader. Hiring a technical co-founder gets tested against senior engineers with startup experience.
A workflow for a first hire
- Write the job description you would have posted. Do not polish it first; the test should react to the real draft.
- Define the target-candidate segment. Years of experience, current company type and level, pay band, and what the segment is likely to weigh most.
- Test the first reaction. Present the draft as it would appear in a feed and capture initial response before asking anything else.
- Isolate the dealbreakers. What in the draft would stop this segment from applying is the single most useful question in the workflow.
- Test pay framing. Compare a vague framing ("competitive salary") against a stated range and measure the shift in stated interest.
- Test the company pitch. The "about us" section is where strong candidates disengage. Compare variants of the pitch for what reads as compelling versus filler.
- Revise and re-test. Run the updated draft against a fresh sample of the same segment to confirm the change moved the result, rather than assuming it did.
What to watch for
The "we need everything" trap. A requirements list with a dozen items usually has five that matter. A comparison test shows which ones move candidate intent and which ones narrow the pool for no reason. Senior candidates do not self-select into an impossible profile.
The stage-obscurity problem. "Growing startup" reads differently from a specific, honest description of team size, funding stage, and how much ambiguity to expect. Specific framing keeps strong candidates in the funnel; vague framing loses them before they read the requirements.
The mission-money imbalance. Strong candidates weigh both mission and a competitive offer. A posting that only sells mission reads, to an experienced operator, as a company that cannot afford them. A posting that only sells pay loses candidates who are evaluating the mission. A controlled comparison shows where a specific draft is out of balance.
Limitations
A controlled comparison of job-description variants is not a substitute for interviewing actual candidates, observing real applicant behavior, running compensation benchmarking, or applying a recruiter's market judgment. It answers only which draft, tested against a defined segment, changes stated interest and intent to apply. Where the decision needs a real-world check, /how-we-work describes how a team moves from a simulated comparison to real-human validation without changing the underlying question being tested. See how these experiments are structured and validated at /research, or the approach applied to a specific hire at /demo.
The job description is not the hire. It is the door. A founder who tests it against the candidates they want before posting spends less of that hire's runway finding out the hard way.
