AI in Hiring

Better Prompts for an AI Job Description Generator

ClarityHire Team(Editorial)5 min read

Why AI job descriptions all sound the same

Ask an LLM to "write a job description for a software engineer" and you get:

We're seeking a talented Software Engineer to join our innovative team. You'll work on cutting-edge technologies, collaborate with cross-functional teams, and make an impact. Required: 5+ years of experience, strong communication skills, passion for problem-solving...

Every company gets the same job description. The words are generic, the requirements are boilerplate, the tone is indistinguishable from fifty other postings. It doesn't reflect your company, your role, or your actual needs.

The problem isn't the LLM. It's the prompt. A vague prompt gets a vague output.

How to structure a prompt that works

A working AI JD prompt has five sections:

1. Company context (2–3 sentences)

Not "we're an innovative tech company"—that's every company. Give specific context:

Acme Systems makes infrastructure automation for insurance companies. We're a $50M B2B SaaS company, 12 people on the engineering team, founded in 2018. We care about shipping solid products over moving fast, and we interview for culture-add not culture-fit.

The LLM now has real constraints. It won't suggest "move fast and break things"; it'll suggest someone who values shipping quality.

2. The actual job (role title, what they'll do, daily reality)

Not "responsibilities include..." — describe what the person does on day one:

Senior Backend Engineer, payments platform. You'll own the billing system: designing schemas, shipping features that reduce payment failures, responding to payment-related customer support. You'll work with one product manager (Carol) and one frontend engineer (Dev). You'll spend ~40% coding, ~30% design/review, ~20% on-call support, ~10% in meetings.

Specificity beats abstraction. "On day 30, you'll have shipped feature X" beats "you'll contribute to our product roadmap."

3. What they actually need to know or have (not wish-list)

Separate must-haves from nice-to-haves:

Must have:

  • 5+ years backend software engineering
  • Strong SQL and schema design
  • Shipped a payment integration (Stripe, Square, PayPal, whatever)
  • Comfortable being on-call and debugging production issues

Nice to have:

  • Scala or Rust experience (we use Scala for payments)
  • Open source contributions
  • Insurance/payments domain knowledge

Honest must-haves are rare. Most companies list 8 must-haves when they mean 4. Be real. An LLM will follow your lead and be realistic too.

4. Company culture / working style (not buzzwords)

Not "collaborative, innovative, fast-paced." Instead:

We have async-first documentation. Meetings are 30-min standup once a day plus office hours. We code-review everything; your first PR might get 10 comments. We use Postgres, no NoSQL. We ship features every two weeks. We don't do Agile or Scrum — we ship when features are done.

These details let the LLM reason about who'd thrive. An engineer who hates code review or async work won't apply. An engineer who loves deep systems thinking will be excited.

5. Compensation transparency

This one is critical and most teams skip it:

Salary: $180k–$220k depending on experience. Equity: 0.15–0.4%. Benefits: 401k match, health/dental/vision, 4 weeks PTO, parental leave 16 weeks.

Job descriptions without salary information are disrespectful. You're asking someone to apply without knowing the range? Compensation transparency also signals a company that trusts its own market position.

Failure modes to avoid

Gendered language. Most LLMs have been trained to recognize and strip gendered words ("he drives," "she nurtures") but still sometimes generate them. Add this to your prompt:

Avoid gendered language. Don't say "he/she" or adjectives that skew male (aggressive, pioneering) or female (collaborative, nurturing).

Unrealistic requirement stacks. The classic: "5+ years with this 2-year-old framework." Your prompt should call this out:

Don't require experience with tools we built in-house or that are < 3 years old in the market.

Excessive buzzwords. "Synergize, leverage, innovate, disrupt." Add:

Use plain language. Avoid buzzwords like "synergy," "leverage," "cutting-edge," "best-in-class." Be specific and honest.

Missing the role's actual problem. If you're hiring a backend engineer because your payments system is failing, say it:

We have a technical debt problem in the billing system. This role exists to fix it, not just to add headcount.

An LLM given this context will write a job description that attracts people who want to solve hard technical problems, not people looking for a title.

What a human still needs to decide

LLMs are not your whole JD. They're a draft. A human needs to:

  1. Verify the compensation band is market-correct for your location and role level.
  2. Confirm the "nice to haves" are actually nice and not deal-breakers in disguise.
  3. Own the mission statement — why this role matters to your company's future. No LLM should write "your work matters to us"; you should.
  4. Decide on remote/hybrid/office clearly. Don't let the LLM be vague.
  5. Review for legal compliance. Some jurisdictions require specific disclosures. Your legal team, not the LLM, should sign off.

ClarityHire's job description generator gives you a structured prompt interface (company context, role, must-haves, culture, comp) and generates a draft JD in 30 seconds. It's good enough to ship after a human review. It's not good enough to ship untouched.

Try the JD generator on ClarityHire

job descriptionsai writingllm promptshiringjob posting

Related Articles