Audit Your Own Job Posting Through a Candidate's Eyes

Most job posting advice is written from the employer's side: here's how to write one that attracts candidates. This is the same subject from the other direction — read your own current job postings the way a sharp, experienced candidate actually reads them, looking for exactly the signals that make them quietly close the tab.

Read it as if you're the candidate, right now

Pull up one of your current open postings and go through this list honestly, the way someone evaluating four other job postings in the same browsing session would.

☐ Is the salary range visible, or absent? A candidate reading this notices its absence immediately, and a growing number read "competitive salary" as code for "below market and we'd rather not say." If it's missing, that's the first, most consequential fix on this list.

☐ Could this posting have been written for any company in your industry? If every sentence would be equally true with your company name swapped out for a competitor's, a sharp candidate notices the genericness and reads it as a sign nobody put real thought into the posting — or the role.

☐ Does the requirements list match the seniority the title implies? A "Coordinator" role asking for five years of experience and three specific software certifications reads as either a mistitled senior role or a posting nobody proofread against what the role actually needs.

☐ Are the requirements split into "must-have" and "nice-to-have," or dumped into one list? A single undifferentiated list of fifteen items reads as "we don't actually know what's essential here," and it's a well-documented reason strong candidates — especially those from groups statistically more likely to self-select out — decide not to apply at all.

☐ Does any phrase sound like a warning dressed up as a selling point? "Fast-paced environment," "wears many hats," "works well under pressure" — a candidate who's job-hunted before recognizes these as common code for understaffed and reactive, whether or not that's actually true of your team.

☐ Is there anything specific and true that couldn't be said about a different job? The strongest signal a posting was written with real care is one concrete, specific detail — a real project, a genuine reason the role exists now, an honest description of what makes the day-to-day distinct. Its absence is conspicuous to a careful reader.

☐ Would the interview process, based on this posting, likely confirm or contradict what it promises? If the posting emphasizes autonomy and flexibility but you know the actual day-to-day involves closer oversight, that gap will surface in the interview or, worse, in the first few weeks — better to close it in the posting itself than let a candidate discover it later.

What this exercise usually reveals

Doing this audit honestly on an existing posting, written some time ago and not revisited since, often surfaces at least two or three of the items above — not because anyone was being careless on purpose, but because job postings tend to get written once, under time pressure, and then left unchanged through several hiring cycles without a fresh, critical read.

The fix is usually smaller than it feels

Most of these issues are addressable with a focused twenty-minute revision, not a full rewrite: add the range, split requirements into two honest tiers, cut anything that sounds like a euphemism for a problem, and add one genuinely specific, true detail about the actual work. A fuller structure for writing one from scratch covers the complete approach if the audit reveals the posting needs more than a touch-up.

Why this candidate-side framing catches things the writer's-side checklist misses

Writing a posting and auditing one you already wrote engage differently — when you're the one writing it, you know what you meant, which makes it hard to see how a stranger reading it cold would interpret the same words. Reading it deliberately as an outsider, ideally after enough time has passed that the original intent isn't fresh in your mind, catches the gap between what was meant and what actually got communicated.

Doing this before every posting goes live, not just retroactively

The real value of this checklist is running it before a posting is published, not months later during a retrospective on why a role took too long to fill. A five-minute read-through from the candidate's side, immediately before hitting publish, catches most of these issues at the cheapest possible moment to fix them — before they've already cost you a stack of applications from people who read closely enough to notice and closely enough to walk away.

Getting a second, less biased read

Even with this checklist in hand, the person who wrote the posting is the worst-positioned person to fully audit it — they know what they meant, which makes the actual gaps harder to see. Having a colleague who wasn't involved in writing it, or ideally someone outside the hiring team entirely, run through the same checklist cold produces a meaningfully more honest read than a self-review, however careful. If nobody else is available, at minimum let real time pass — a day, not five minutes — between writing and auditing, so the review isn't happening with the same mental frame that produced the draft.

A version of this worth running on old, still-active postings

It's worth applying this same audit to any posting that's been live for a while without producing the volume or quality of applicants expected — not just to new postings before they launch. A role that's been open for two months with a thin, low-fit applicant pool is a strong candidate for exactly this kind of candid, candidate-side review, since something in how it reads is very possibly part of why the pipeline has been weak.

The short version

The sharpest, most self-selecting candidates read a job posting the way they'd read a first date's opening message — for specific, honest signals, not polished generality — and they notice exactly the things a rushed, unaudited posting tends to get wrong: a missing salary range, generic language, a mismatched requirements list, and euphemisms for real problems. Auditing your own postings from that same skeptical angle, before they go live, catches what writing them from the inside almost never does.