How to Write an IT Job Requisition That Actually Attracts People

We read hundreds of job requisitions a month, and most of them have the same problem: they were written to survive an approval process, not to attract a human being. Twelve required technologies. A responsibilities section copied from a job three reorgs ago. “Excellent communication skills.” By the time it reaches a candidate, there's nothing left that sounds like a job anyone actually does.

Here's the thing — candidates read reqs the way you read resumes. Fast, skeptically, looking for a reason to move on. A req that's vague, bloated, or obviously stale gives them that reason in the first ten seconds.

What we've learned rewriting reqs with clients over the years:

Lead with the work, not the company boilerplate The first three lines decide whether anyone keeps reading. “You'll own the migration of our claims platform to AWS, working with a team of six” beats two paragraphs about being a leading provider of innovative solutions. Candidates want to know what they'll build, fix, or run. Tell them immediately.

Separate must-have from nice-to-have, honestly When a req lists twelve required skills, one of two things is true: the list is aspirational, or the role is actually three roles. Either way, strong candidates self-reject — the person with eight of twelve moves on, and ironically it's often the best people who rule themselves out, because they take requirements seriously. Pick the four or five skills the job genuinely can't function without and call everything else a plus. Your pipeline will widen the same week.

Say the number, or at least the range Roles with posted pay ranges fill measurably faster — and in a growing list of states, posting the range is the law anyway. Hiding compensation doesn't create negotiating leverage; it creates a pile of candidates who were never in your range, plus a smaller pile who assumed the worst and didn't apply.

Kill the clichés and the ghosts “Rockstar,” “ninja,” “wear many hats,” “fast-paced environment” — this language doesn't attract energy, it signals chaos and understaffing. Same for ghost requirements: if the last three hires didn't have a CS degree and did fine, stop requiring one. Every ghost requirement quietly deletes good candidates from your pipeline.

Write for the specific person you're missing Before writing a word, ask the hiring manager: think of the best person you've had in this role — what made them work? The answer is almost never a list of technologies. It's “she could talk to the actuaries” or “he tested his own work.” Get that into the req. It reads like a real team wrote it, because one did.

One more thing. The req is a sourcing document, not a contract. Its only job is to make the right person say “that's me” and reach out. Everything that doesn't serve that goal is costing you candidates — one paragraph at a time.

Common questions
How long should a req be? Shorter than you think. A tight summary, five or six real responsibilities, four or five true requirements, the range, and the process. If it doesn't fit on one screen, candidates aren't finishing it.

Should the same req go to a staffing partner as goes on the job board? Give your partner more, not less — team context, the manager's style, why the last person left, what the interview will focus on. That context never gets posted, but it's exactly what lets a recruiter pitch the role honestly and match for fit.

Who should write it — HR, the manager, or the recruiter? Draft it with the hiring manager talking and someone else typing. Managers describe jobs accurately out loud and terribly in writing.