Last spring we posted a senior engineer role and got 240 applications. Twelve met our actual bar. Twelve. Our recruiter spent two weeks screening resumes that were never going to work, time-to-hire crept to nine weeks, and we still didn't find the person. So I went back and actually read our own job description, which I'd apparently approved months earlier without reading. It had eleven must-have requirements, used 'rockstar' three separate times, demanded a CS degree for a role where half our best engineers don't have one, and listed no compensation range at all. I'd been blaming the market. The market was fine. The posting was the problem.
Why the old posting was repelling good people
Strong candidates self-select out of bloated postings. If you list eleven must-haves, the people who apply anyway tend to be the ones who skim requirements, and the people who would've been excellent quietly assume they're under-qualified and move on. The research on this is depressingly consistent: padded requirement lists shrink your qualified pipeline, especially among under-represented candidates, who are statistically far more likely to only apply when they meet every single listed criterion. No salary range makes it worse — people assume the worst, assume you're hiding a lowball, and don't bother spending an hour on the application.
There's also a quieter cost. Every unqualified application is a resume your recruiter has to read and reject, which is time stolen from actually courting the good candidates. A bad job description doesn't just lower quality at the top of the funnel; it taxes every stage below it.
What I did instead
I ran the Inclusive Job Description Writer from a One-Line Role Brief prompt on GPT 5.2. I gave it the hiring manager's brief almost verbatim, the comp range I finally pried out of finance, and our remote policy. The numbered-rules format is exactly why I used GPT 5.2 here: it follows the "keep must-haves to five, kill deterrent words, write outcomes not tasks" instructions literally, and the bias-and-length audit at the end tells you precisely what it stripped and what your final must-have count came to. It flagged that I'd left an unnecessary degree requirement in my own brief and quietly moved it to nice-to-have, then told me it had done so.
The outcome-based responsibilities were the subtle upgrade. "Maintain the deployment pipeline" became "Own deploys and keep our release confidence high enough that we ship on Fridays." Same job, but the second version tells a candidate what success looks like and what kind of team they're joining. Good engineers read that and lean in.
What the data showed
We reposted the same role two months later with the new description. The raw application count actually dropped — 240 down to 180 — and that's the point. Fewer, dramatically better. Our recruiter's first-screen pass rate went from embarrassing to genuinely encouraging, and the resumes that came in actually mapped to the work, so screening calls stopped being a polite exercise in mutual disappointment.
I'll be honest that I was nervous about a lower application count. There's a primal recruiting instinct that says more is safer — a big pile of resumes feels like progress. It isn't. A big pile of unqualified resumes is just a big pile of work that ends in the same place. Once I reframed the goal from volume to qualified volume, the smaller number stopped scaring me and started feeling like exactly what we'd asked for.
- Applications: 240 to 180 (lower volume, on purpose)
- Qualified on first screen: 12 to 47 — almost 4x
- Time-to-hire: 9 weeks to 5 weeks
- Offer acceptance: 60% to 85%, because candidates knew the comp and the role up front and weren't surprised at the end
The two changes that moved the numbers
It wasn't subtle. The two levers were adding the salary range and cutting the must-have list from eleven items to four. The comp range cost us nothing — it was always going to be in the offer letter anyway, so all the secrecy bought us was a smaller, more suspicious pool. Shortening the must-haves forced an uncomfortable but useful conversation with the hiring manager about what we actually needed on day one versus what we'd be happy to teach. The prompt structures you toward both of those by design, which is the whole reason I trust it more than my own first draft at 5pm on a Friday when I'm tempted to just paste the last posting and change the title.
We've since rebuilt every template in our hiring library this way, and the consistency itself has become a small advantage — candidates who apply to two of our roles tell us the postings feel like they came from the same thoughtful place. Grab the Inclusive Job Description Writer from a One-Line Role Brief prompt on Prompt Dock and run it on your worst-performing posting first; you'll feel the cringe and then the relief. When a strong candidate finally lands, I hand the interview loop straight to my Structured Interview Questions & Scoring Rubric Generator prompt so the rest of the funnel is as honest and bias-aware as the posting that brought them in.