Write Job Descriptions for Roles the Market Renamed While You Weren't Hiring

Workflow area: Hiring & Performance · Tier: Foundation · Hands-on time: ~25 minutes

Job descriptions are the highest-leverage two pages a hiring leader writes: they decide who applies, what interviewers probe, and what "meets expectations" means a year later. Right now they're also where AI-era confusion is most visible — postings demanding "5+ years of LLM production experience" for tools that shipped in 2023, or saying nothing about AI at all and losing candidates who now ask about tooling in the first screen. AI helps twice here: drafting from what employers are actually asking for this quarter, and scanning your draft for the biased, clichéd language that survives because it's familiar.

When to use — and when not to

• Use it for every engineering openingIC roles especially, where AI-assisted development has genuinely changed the day job the JD is supposed to describe.
• Use it to refresh evergreen JDsthe roles you hire quarterly are running on the oldest language; refresh them before the next cycle opens.
• Use it before a leveling debatea JD with concrete AI-fluency expectations per level short-circuits the "is prompt skill a senior signal?" argument (pb-24 handles the performance-review side).
• Skip inventing requirements no candidate can meetif the model proposes years-of-experience math that predates the technology, that's your cue to cut, not publish.
• Skip fully delegating the role definitionAI drafts the description; what the role is for, what it owns, and what success looks like at 12 months is a leadership decision the model cannot make.

The recipe

1. 1.

   Collect live market language first. Spend ten minutes on current postings for the same role — three from companies you compete with for talent, ideally posted this quarter. Note how they phrase AI expectations. This grounds the draft in what the market says now, not what the model remembers from training data.

2. 2.

   Draft with explicit AI-fluency calibration.

   Copy

   Draft a job description. Inputs:
   - Role: [TITLE, LEVEL, TEAM, LOCATION/REMOTE]
   - What this role owns and its first-year outcomes: [YOUR NOTES]
   - Our stack and AI tooling: [e.g., Copilot + Claude, CI gates,
     agent use at tier N of our autonomy ladder]
   - Live market language from current postings: [PASTE EXCERPTS]
   
   Requirements for the draft:
   1. AI-fluency expectations must be REALISTIC for [LEVEL]: skills
      demonstrable in an interview (effective prompting, verifying
      and debugging AI output, knowing when not to use AI) — never
      years-of-experience demands that predate the tools.
   2. Separate MUST-HAVE (≤5 items) from NICE-TO-HAVE. Every
      must-have must be assessable in our loop.
   3. Outcomes over duties: describe what the person will have
      shipped or changed at 6 and 12 months.
   4. Plain language. No rockstar/ninja/guru/wizard, no "work hard
      play hard", no "young and dynamic team."
   

3. 3.

   Run the bias and cliché scan as a separate pass. Fresh prompt, adversarial stance:

   Copy

   Scan this JD as a bias and inclusion reviewer. Flag, with the
   exact phrase and a suggested rewrite:
   - Gender-coded language (aggressive, dominant, rockstar; also
     over-corrected passivity)
   - Age proxies ("digital native", "recent graduate", culture
     descriptions that code young)
   - Unnecessary must-haves that shrink the pool (degree demands
     the role doesn't need, years-of-experience inflation)
   - Ableist or availability-coded phrasing ("fast-paced", "thrives
     under pressure") where the job doesn't genuinely require it
   - AI-expectation red flags: impossible experience math, vague
     "AI-first mindset" fluff with no assessable behavior behind it
   

   Good output names phrases, not vibes:

   Copy

   FLAG: "5+ years building with LLMs" — the market you're hiring
   from largely started in 2023. Rewrite: "hands-on experience
   shipping features that use LLM APIs, with war stories about
   what broke."
   FLAG: "code ninja who crushes tickets" — gender-coded +
   activity metric. Rewrite: "engineer who ships reliable code
   and improves the system around it."
   

4. 4.

   Generate the India and remote variants. Same conversation: "Produce two variants: (a) India-based — INR compensation banding convention, notice-period reality, hybrid/office expectation stated plainly, no US idioms; (b) remote — time-zone overlap window stated as a requirement, async-writing skill promoted to must-have, location and work-authorization constraints explicit." Vague location policies generate the most screening-call waste per word of any JD section; the variant exists to say the awkward part clearly.

5. 5.

   Human pass: verify assessability and own the promises. For every must-have, name the interview round that tests it (pb-18 designs those rounds; pb-19 sets the candidate-AI rules the JD should reference). Anything untestable moves to nice-to-have or dies. Then check the promises — comp band, remote terms, growth story — with recruiting and HR before posting, because the JD is the first commitment the candidate will hold you to.

Make it yours

• Small team or startup: one JD, honest about breadth — "you'll be the third engineer" beats a FAANG-shaped ladder listing. Realistic AI expectations are a differentiator here: small teams genuinely lean on AI leverage, so say precisely how.
• Large org or GCC: run drafts through your HR-approved template and Textio-class tooling if licensed, keep AI-fluency language consistent across all open roles at the same level (candidates compare postings), and make sure the India variant reflects actual site policy, not the parent org's.
• Hiring your first AI-heavy role (AI platform engineer, eval engineer): the market language step is mandatory, not optional — these titles mean different things at different companies, and importing another company's definition unexamined is how you hire for the wrong job.

Quality check

• Every must-have maps to a loop rounda requirement nobody assesses is decoration that filters honest candidates and waves through confident ones.
• The AI expectations survive the possibility testcould a strong real candidate at this level actually have this? Experience math that predates the tool fails the test.
• The scan's flags got resolved, not skimmedcount phrases changed; a bias scan you ran but didn't act on is worse than none, because now it's documented.
• Six-month outcomes are concrete"will have shipped X" statements a new hire could be fairly measured against; if you can't write them, the role isn't defined yet.
• The variants tell the truthoffice days, overlap hours, and comp convention stated plainly; every ambiguity here is a future offer-stage surprise.