Recruiting is mostly communication work: writing job descriptions that attract the right people, sourcing messages that get replies, interview rubrics that don't bias the hire, offer letters that don't get renegotiated.
I've been running these through an AI assistant for the past year. The prompts below are the ones that survived real use — each has a fixed structure (Role, Context, Constraints, Output) and each has been tested against real inputs. I'll show the prompt, then what it produced, then why it works.
If you want the full library (50+ prompts across recruiting, people ops, and hiring strategy), I keep an updated pack here. But these 10 are the ones I reach for most weeks.
1. Job description that filters for the right people
Role: You are a hiring manager writing a job description.
Context: We're hiring a senior backend engineer. The team is 4 people, builds in Go and Postgres, ships weekly, and values ownership over hand-holding.
Constraints:
- Lead with the actual work (3-5 bullet points of "what you'll do in week 1"), not the company mission.
- Requirements section: split into "Must have" (≤5) and "Nice to have" (≤4). Each must-have is a filter — if a candidate lacks it, we pass.
- No "rockstar," "ninja," "10x," "wear many hats," "fast-paced environment," "work hard play hard."
- Salary range stated. Remote policy stated. No "competitive" — it means nothing.
- End with: "What the first 30 days look like" — concrete, not aspirational. Output: Full JD, ready to post.
Why it works: JDs attract the wrong people when they're vague and repel the right people when they're loaded with bro-culture code words. Banning the clichés forces specificity. Stating salary and remote policy upfront saves everyone time. The "first 30 days" section signals what the job actually is.
2. Sourcing message that earns a reply
Role: You are a technical recruiter writing a cold sourcing message.
Context: Candidate is a senior frontend engineer at a mid-size SaaS. Their GitHub shows React + TypeScript work. We're a Series B devtools startup.
Constraints:
- Subject line: ≤5 words, lowercase, no exclamation, references something specific from their work (a repo, a talk, a post).
- Body: ≤90 words. First line references the specific thing. Second line is the role in one sentence. Third line is why them specifically (not "your background is impressive").
- CTA: a question, not a meeting link. "Open to a 20-min chat?" not "Book time here."
- No "exciting opportunity," "game-changing," "disrupt," "revolutionize."
- PS: one sentence on compensation range + equity + remote. Honesty builds trust. Output: Subject + body + PS.
Why it works: Generic sourcing messages get ignored. The "reference something specific" constraint forces research. The lowercase short subject reads as human, not automated. Putting comp in the PS (not buried) respects the candidate's time. The question CTA lowers friction — a meeting link feels like a commitment.
3. Interview rubric from a messy job description
Role: You are a hiring manager building an interview rubric.
Context: Here's a JD for a product designer. I need a rubric for the portfolio round (4 interviewers, 45 min each).
Constraints:
- 4-5 signals per interviewer, each observable ("can articulate trade-offs" not "is strategic").
- Each signal: what to ask, what a "strong" answer looks like, what a "weak" answer looks like.
- Banned signals: "culture fit," "passion," "grit," "hunger," "is a team player." Replace with observable behaviors.
- Calibration: every interviewer scores independently BEFORE the debrief. No "well, they seemed nice" influence. Output: Per-interviewer rubric + a debrief template (scores first, discussion second).
Why it works: Interview bias creeps in through vague signals. "Culture fit" is a bias magnet — banning it forces observable criteria. The "strong/weak answer" anchors calibrate the panel. Scoring before discussion prevents the loudest interviewer from anchoring the group.
4. Interview question that tests for the job, not trivia
Role: You are an interviewer designing a technical screen.
Context: We're hiring a backend engineer. The job involves designing APIs, not memorizing Big-O.
Constraints:
- One scenario-based question that mirrors real work (e.g., "design the API for a rate limiter" not "what's the time complexity of a hash map").
- The question has multiple valid answers, not one "right" one.
- Follow-up probes: 3, escalating in ambiguity. The third should be unanswerable without asking a clarifying question — tests whether they push back.
- Provide a "what good looks like" and "what bad looks like" for scoring. Output: Question + probes + scoring guide.
Why it works: Trivia questions test test-prep, not ability. Scenario questions test the actual job. The deliberately-ambiguous third probe separates candidates who guess from those who clarify — a core engineering skill. The scoring guide keeps it fair across interviewers.
5. Candidate rejection that doesn't burn the bridge
Role: You are a recruiter writing a rejection email.
Context: Candidate made it to the final round but wasn't selected. They were strong — we'd reconsider for a different role.
Constraints:
- First line: the decision, clearly. No "we've decided to move forward with other candidates" softening.
- One specific thing they did well (from the rubric, not generic).
- One specific growth area, framed as "for roles like this" not "you need to."
- If we'd reconsider: say so explicitly, with a timeframe.
- No "keep your resume on file" unless we mean it. Output: Email, ≤150 words.
Why it works: Vague rejections feel disrespectful and damage your employer brand. Specific feedback (from the rubric) shows the process was real. The "for roles like this" reframe makes the growth area actionable, not personal. The "would reconsider" line is honest — it either opens a door or doesn't.
6. Offer letter that survives the first counteroffer
Role: You are a hiring manager writing an offer letter.
Context: Senior engineer, base $X, equity Y, remote. They have a competing offer.
Constraints:
- Lead with the role and start date — the decision-relevant facts.
- Compensation: base, equity (with vesting schedule and strike), bonus, sign-on. Each on its own line. No "total compensation" aggregation that hides the base.
- Benefits summary: ≤5 bullets, the ones that actually matter (health, PTO, remote, learning budget). Skip the 401k match boilerplate.
- One sentence on why we made the offer (ties to the interview — shows it wasn't arbitrary).
- Expiry date stated. No "we look forward to your response" pressure language. Output: Offer letter, one page.
Why it works: Offers lose candidates when the details are buried. Putting each comp component on its own line (no "total comp" sleight of hand) builds trust. Tying the offer to the interview signals it was earned. The expiry date creates a clean decision frame without pressure tactics.
7. Reference check that surfaces the real signal
Role: You are a hiring manager conducting a reference call.
Context: 30-min call with a candidate's former manager. Candidate is up for a senior IC role.
Constraints:
- Open with: "I have 30 minutes and I want to use them well. What's the one thing I should know that isn't in their resume?" (forces the reference past the prepared talking points).
- 5 questions max: one on strengths (specific example required), one on growth area (specific example required), one on "would you rehire," one on team dynamics, one wildcard.
- No "rate them 1-10" questions — they produce noise.
- End with: "Is there anything I haven't asked that I should have?" Output: Call script + a notes template (strength / growth / rehire / wildcard).
Why it works: References default to positivity. The opening question ("one thing not in the resume") cuts through the prep. Forcing specific examples (not ratings) gets real signal. The closing question often surfaces the most important data point.
8. Onboarding plan for the first 90 days
Role: You are a hiring manager building an onboarding plan.
Context: New senior engineer starts in 2 weeks. Team of 5, Go/Postgres stack, weekly shipping cadence.
Constraints:
- Week 1: setup, meet everyone, ship one tiny thing (a docs fix, a small bug). Goal: feel productive.
- Week 2-4: first real feature, paired with a buddy. Goal: learn the codebase by doing.
- Day 30: review. What's working, what's not. Adjust the plan.
- Day 60: lead a small project end-to-end.
- Day 90: full ownership of a domain.
- Each milestone: success criteria (observable), not "ramp up" (vague). Output: 90-day plan, week by week, with success criteria.
Why it works: Onboarding fails when it's "read the wiki and figure it out." The "ship one tiny thing in week 1" builds confidence fast. Observable success criteria ("shipped X, reviewed Y") beat vague ones ("ramped up"). The day-30 review lets you course-correct before day 90.
9. Hiring manager intake that aligns before you start sourcing
Role: You are a recruiter running an intake meeting with a hiring manager.
Context: 30-min kickoff for a new role. I need to extract the real requirements, not the wishlist.
Constraints:
- 6 questions: (1) What's the #1 thing this person must do in month 1? (2) Who on the current team does this role complement? (3) What does "great" look like at 6 months? (4) What's non-negotiable vs trainable? (5) Why would someone take this job over a competitor's? (5) What's the budget and how firm is it?
- For each answer: push back once if it's vague ("'strong communicator' — what does that look like in week 2?").
- End with: the sourcing strategy in one sentence (which companies, which communities). Output: Intake notes + a one-paragraph "role brief" the hiring manager signs off on.
Why it works: Intakes fail when the wishlist is treated as requirements. The "month 1" question forces prioritization. Pushing back on vague answers ("'strong communicator' — what does that look like?") converts adjectives into criteria. The signed role brief prevents scope drift mid-search.
10. Candidate debrief that avoids groupthink
Role: You are a hiring manager running a debrief.
Context: 4 interviewers just met a candidate. 30-min debrief.
Constraints:
- Round 1: each interviewer states their recommendation (hire/no-hire/leaning) + one piece of evidence. No discussion. (forces independent thinking).
- Round 2: open discussion, but every claim must cite a specific moment from the interview. No "I got a good vibe."
- Round 3: decision. If split, default to the rubric — does the evidence meet the bar?
- Banned: "culture fit," "I could see myself grabbing a beer with them," "they'd be fun to work with." Output: Decision + reasoning + (if hire) the onboarding focus areas based on rubric gaps.
Why it works: Debriefs go sideways when the loudest interviewer anchors the group. The "state recommendation + evidence first, no discussion" round forces independent judgment. Requiring specific moments (not vibes) keeps it evidence-based. Banning "beer test" language removes the likeability bias that produces homogenous hires.
How I test these prompts
Three steps, every time:
- Run it 3× on the same input. If the output varies wildly, the prompt is under-specified. Tighten the constraints.
- Generalize to a second domain. Take a sourcing prompt built for engineers and run it for designers. If it breaks, the constraints are too narrow. If it holds, it's portable.
- Read it aloud. If it sounds like an AI wrote it — "delve into," "in today's competitive talent market," "it's important to note" — rewrite the constraints to ban that register.
The pattern across all 10: constraints do more work than instructions. Telling the model what NOT to do (no "rockstar," no "culture fit," no leading questions) produces sharper output than telling it what to do.
If these were useful, I keep a larger library — 50+ prompts covering recruiting, people ops, hiring strategy, and offer negotiation. It's here ($9). If you're also building a team and shipping product, the AI Startup Operations Prompt System covers the full org (hiring, onboarding, ops, planning).
Good hiring.
Top comments (0)