Your Job Description Is Setting Your AI Screen Up to Fail

83% of job seekers say vague responsibilities or unclear requirements in a job posting signal a disorganized hiring process before they’ve even applied (Resume Genius, 2026 Job Search Statistics Report). TA teams tend to treat that as a candidate-experience problem, something that makes the company look less polished. It’s a bigger problem than that. A vague JD doesn’t just turn off good candidates. It’s the document your screening rubric gets built from, and a rubric built on a vague brief produces vague scores, no matter how good the screening technology behind it is.

The rubric is only as specific as the brief it came from

Every structured screening rubric starts life as an interpretation of a job description. If the JD says “strong communication skills required” without specifying what that means for this particular role, whether it means fielding client calls in English, coordinating across a distributed team, or writing clear internal documentation, the rubric ends up scoring for a generic version of “communication” instead of the version the role actually needs. The screening system isn’t guessing wrong. It’s accurately scoring against an ambiguous target, which produces a result that looks precise and isn’t.

This is the same failure mode research on job-search behavior keeps documenting from the candidate side. One widely cited breakdown of the problem calls it the “great expectation mismatch”: companies write postings asking for five years with a technology that’s existed for three, require on-site presence for work that doesn’t need it, and filter for pedigree signals when they meant to filter for capability (ThriveMap). Every one of those mismatches gets encoded straight into a scoring rubric that treats the JD as ground truth, because it has no other source to work from.

Where this shows up in a campus drive specifically

Campus JDs are frequently written once and reused across multiple hiring cycles with minor edits, sometimes inherited from a template that predates the person currently running the drive. At the volume a campus screen operates at, a generic rubric doesn’t just produce a handful of bad calls, it produces a systematic bias across the entire pool. Every candidate gets scored against requirements nobody actually checked still matched the role, and because the pattern is consistent, it looks like the screening system is working. Consistency and accuracy are not the same thing, and a rubric can be perfectly consistent while being consistently wrong.

We’ve written about how a rubric built specifically for one role differs from a generic one applied across every opening: the mechanism matters, but the mechanism only helps if the JD feeding it is actually specific. A JD-aware rubric built from a vague JD is still a vague rubric. It’s just vague with more confidence.

What to actually check before you screen

The fix isn’t rewriting every JD into a polished, HR-marketing document; that’s a different problem with a different fix. It’s narrower: before a screening rubric goes live for a role, someone should be able to answer three specific questions from the JD alone, not from what they know informally about the role. What does “strong communication” mean for this specific position, in a sentence, not an adjective. What’s the actual minimum bar for the technical requirement, not the aspirational one copied from a more senior posting. And does the location or shift requirement in the JD match what the role genuinely needs, or is it a leftover default. If any of those three comes back as “I’d have to ask someone,” the rubric that gets built from that JD is scoring against a target nobody actually defined.

The honest tradeoff

Tightening a JD before a drive takes real time from whoever owns the role, usually a hiring manager who has a dozen other things due that week, and skipping it is the path of least resistance for a reason. But that’s exactly the cost that shows up later as a screening rubric everyone quietly distrusts, without anyone tracing the distrust back to the three-line JD it was built from. Twenty minutes spent making a JD specific is cheaper than a drive’s worth of ambiguous scores.

If you want a second opinion on whether your current JDs would produce a specific rubric or a vague one, book a demo and we’ll walk through one of your live postings.