I've sat on both sides of the technical hiring table — as a candidate and as the one making the call. The hardest part of recruiting was never the decision. It was the writing: the job description that attracts the right people, the screen that actually filters, the interview that doesn't waste anyone's time, and the debrief that doesn't turn into a vibe check.
Over the last year I've built a set of prompts that handle the tedious writing work of recruiting. Each one has a strict structure — Role → Context → Constraints → Output — and each one produces something I can actually use, not a wall of generic text. Below are the 10 I reach for most.
I sell a few prompt packs on Gumroad (Developer Product-Launch Pack, Developer Productivity Library, SaaS Marketing Copy Pack, AI Startup Operations System, AI Business Transformation Playbook) — but every prompt below works on its own. No purchase required.
1. The job description that filters OUT the wrong people
Most JDs try to attract everyone. The good ones repel the wrong candidates.
ROLE: You are a senior technical recruiter who has hired 500+ engineers.
CONTEXT: I need a job description for [ROLE]. Our team is [SIZE], stack is [STACK], and we specifically do NOT want [UNWANTED TRAIT — e.g., "agency-only background" / "people who need heavy process"].
CONSTRAINTS:
- 350 words max.
- Open with one sentence about the actual problem the hire will solve (not "we are a fast-growing company").
- Include a "You will NOT enjoy this role if..." section with 3 honest disqualifiers.
- List must-haves (max 5) and nice-to-haves (max 3) as separate bullet groups.
- Ban these words: "rockstar", "ninja", "fast-paced", "wear many hats", "passionate".
- End with a one-line application instruction that requires a specific action (not "send resume").
OUTPUT: Markdown job description, ready to paste into a job board.
Why it works: The "You will NOT enjoy this role if" section is the highest-signal part — it does the filtering before a human ever reads an application. Banning the buzzwords forces concrete language.
2. Candidate screen — surface the dealbreakers in 15 minutes
The phone screen exists to find out fast whether to invest another 4 hours. This prompt builds the screen.
ROLE: You are a hiring manager who has run 1,000+ technical screens.
CONTEXT: I am screening a candidate for [ROLE]. Their resume highlights are [PASTE 3 BULLETS]. The must-haves for the role are [LIST].
CONSTRAINTS:
- Produce exactly 6 questions.
- 2 must probe the must-have skills (ask for a specific past example, not a hypothetical).
- 1 must be a dealbreaker check (the thing that, if answered wrong, ends the process — e.g., "Tell me about a time you disagreed with a technical lead's decision and what happened").
- 1 must test self-awareness ("What kind of work environment do you do your worst work in?").
- 1 must be a red-flag inverse ("What's a technology on your resume you'd be uncomfortable using in production today, and why?").
- 1 must be the candidate's question to me — give me a strong question to ask that reveals how they think about the role.
- For each question, include a 1-line note on what a GOOD answer sounds like and what a RED FLAG answer sounds like.
OUTPUT: Numbered list. Question → good-signal → red-flag, repeated 6 times.
Why it works: The "self-awareness" and "red-flag inverse" questions are the ones that actually separate senior from junior thinkers. Forcing good/red-flag notes means anyone on the team can run the screen consistently.
3. Interview prep packet for the panel
ROLE: You are a hiring coordinator who prepares interview panels.
CONTEXT: Candidate is interviewing for [ROLE]. Resume: [PASTE]. The panel has [N] interviewers across [FUNCTIONS — e.g., coding, system design, behavioral, cross-functional]. Total interview time: [DURATION].
CONSTRAINTS:
- Assign each interviewer a distinct area (no two people cover the same ground).
- For each interviewer: give their focus area, 2 suggested questions, 1 thing to listen for, and 1 thing to avoid (common bias in that area).
- Flag 2 resume claims that need verification (the most impressive-sounding ones — those are where exaggeration hides).
- End with a "panel calibration note" — 2 sentences on what a "hire" vs "no-hire" consensus looks like for THIS role specifically.
OUTPUT: One section per interviewer, then the calibration note. Max 400 words.
Why it works: Panels without prep packets ask overlapping questions and leave gaps. The "verify the most impressive claim" rule catches the inflated resume — the best-sounding bullet is statistically the most likely to be stretched.
4. Structured debrief that doesn't become a vibe check
ROLE: You are a hiring manager running a structured debrief.
CONTEXT: The panel just interviewed [CANDIDATE] for [ROLE]. I will paste each interviewer's raw notes below.
CONSTRAINTS:
- Do NOT summarize feelings ("seemed sharp"). Extract only observable signals.
- Group findings into 3 buckets: STRENGTHS (with the specific evidence cited), CONCERNS (with the specific evidence cited), and UNANSWERED (what no one tested).
- For each CONCERN, state whether it is disqualifying or coachable.
- End with a forced decision frame — NOT a recommendation. Present the decision as: "If we hire, the bet is [X]. If we pass, the risk is [Y]." Let the human decide.
- Ban these phrases: "culture fit", "great energy", "would grab a beer with", "hungry".
OUTPUT: 3 labeled buckets, then the decision frame. No verdict.
INTERVIEWER NOTES:
[PASTE]
Why it works: Debriefs go wrong when they become personality impressions. Forcing evidence-anchored buckets and a bet-vs-risk frame (instead of a recommendation) keeps the decision honest and defensible.
5. Rejection email that doesn't burn the bridge
ROLE: You are a recruiter who values candidate experience.
CONTEXT: [CANDIDATE] was rejected after [STAGE]. They were [STRONG / BORDERLINE]. One specific positive thing from the process: [SPECIFIC SIGNAL].
CONSTRAINTS:
- 120 words max.
- First sentence states the decision (no "thank you so much for your time" preamble — candidates hate it).
- Include ONE specific, true piece of positive feedback (never invent one — if I gave you one, use it; if not, omit the line entirely).
- If [BORDERLINE], invite them to stay connected for future roles and tell them what to strengthen.
- If [STRONG], tell them the specific role level we'd consider them for next.
- Never use: "unfortunately", "we decided to move forward with other candidates", "keep your resume on file".
OUTPUT: Email body, ready to send.
Why it works: Generic rejections damage employer brand and cost you future applicants. A specific, honest rejection — especially for borderline candidates — is how you build a talent pipeline. The banned phrases are the tell that a human didn't read the application.
6. Offer letter that survives legal + candidate read
ROLE: You are a recruiter + a cautious employment lawyer, combined.
CONTEXT: Offering [ROLE] to [CANDIDATE]. Compensation: [SALARY/EQUITY/LOCATION]. Start date: [DATE]. Reporting to: [MANAGER].
CONSTRAINTS:
- Use plain English. No clause should require a lawyer to understand.
- Structure: role + level, compensation (break out base/equity/bonus/sign-on as separate lines if they exist), start date, reporting line, then a one-paragraph "what your first 30 days look like" written in normal voice.
- Include the at-will (or equivalent) statement as its own clearly labeled sentence, not buried.
- Do NOT include: "competitive benefits package" (say the actual top 3 or omit), "exciting opportunity" (say what they'll work on), or any non-compete language unless I explicitly provide it.
- End with a single clear acceptance instruction.
OUTPUT: Offer letter, ready to send. Max 400 words.
Why it works: Offer letters fail when they're either too vague to be useful or so legalistic they scare the candidate. Plain English + the "first 30 days" paragraph is what makes a candidate say yes — it proves someone thought about them as a person, not a headcount.
7. The "is this level right" calibration doc
ROLE: You are a compensation + leveling specialist.
CONTEXT: I'm calibrating a level for [ROLE] at a [STAGE — seed/Series A/etc.] company. I have [N] incumbents at adjacent levels. Their scope, as I'll describe: [DESCRIBE].
CONSTRAINTS:
- Output a 1-page calibration doc.
- Define the level by SCOPE OF IMPACT, not years of experience (years are a weak proxy).
- Give 4 concrete signal questions per level (Junior / Mid / Senior / Staff) — each answerable from observable work, not self-report.
- Include a "leveling trap" callout: the 2 most common mistakes people make when leveling this role at this stage (e.g., "confusing visibility with impact" or "leveling by the candidate's confidence, not the work").
- Do not cite external salary bands (I'll handle comp separately).
OUTPUT: Markdown doc, max 350 words.
Why it works: Leveling by years of experience is the #1 source of mis-leveled hires. Defining levels by observable signals — and naming the common traps — turns a fuzzy judgment into a repeatable decision.
8. Interview question that actually tests the must-have
ROLE: You are a senior engineer who has conducted hundreds of interviews.
CONTEXT: I need an interview question to test [SPECIFIC SKILL — e.g., "API design for rate limiting" / "debugging a production memory leak" / "stakeholder communication under ambiguity"]. The candidate level is [LEVEL].
CONSTRAINTS:
- The question must be answerable in [TIME — e.g., 30 minutes].
- It must have a clear "good answer" structure but NOT a single right answer (so I can tell apart memorized answers from thinking).
- Provide: the question prompt (as I'd hand it to the candidate), 3 follow-up probes that escalate difficulty, the 3 signals that indicate a strong candidate, and the 2 signals that indicate a weak one.
- Do NOT provide a "model answer" — I want signals to watch for, not a script to grade against.
- Avoid questions findable on LeetCode, Glassdoor, or common interview-prep sites.
OUTPUT: Prompt → 3 probes → 3 strong signals → 2 weak signals.
Why it works: Interview questions fail when they're either too easy (everyone passes) or too scripted (candidates memorize the answer). Forcing follow-up probes and observable signals — instead of a model answer — is what separates a real assessment from a trivia test.
9. Internal promotion case — argue it for me
ROLE: You are an engineering manager writing a promotion case.
CONTEXT: I am advocating for [EMPLOYEE] to be promoted from [CURRENT] to [TARGET]. Evidence I have: [PASTE 3-5 SPECIFIC ACCOMPLISHMENTS WITH IMPACT]. The promotion committee cares about [CRITERIA — scope, autonomy, impact, mentorship].
CONSTRAINTS:
- Structure as: Summary (2 sentences) → Scope of impact (with the evidence I gave, each tied to a criterion) → Growth signal (what changed in how they work, not just what they shipped) → Risk of not promoting (retention + what they're already doing above level).
- Every claim must trace to specific evidence I provided. Do NOT invent metrics.
- If any criterion has NO evidence from me, explicitly write "EVIDENCE GAP: [criterion] — needs a specific example" rather than padding.
- Ban: "exceeds expectations", "gone above and beyond", "consistently delivers", "key contributor".
OUTPUT: Promotion case, max 300 words, ready to submit to committee.
Why it works: Promotion cases get rejected when they're full of adjectives and short on evidence. Forcing every claim to trace to provided evidence — and explicitly flagging gaps instead of padding them — is what gets cases approved.
10. Hiring plan that a finance partner can read
ROLE: You are a head of talent writing a hiring plan for finance sign-off.
CONTEXT: I need to hire [N] people across [ROLES] over [TIMEFRAME]. Budget envelope: [AMOUNT or "TBD — give me the range"]. Business reason: [WHY — e.g., "shipping the v2 product" / "replacing contractor spend" / "entering a new market"].
CONSTRAINTS:
- One-page plan. Sections: Why now (business trigger), The roles (table: role / level / why-this-level / target start), Sourcing strategy (2 channels per role, with why), Sequencing (which hire unlocks the next), Total cost (salary + recruiter + ramp time, as a range), and Risks (top 2 — e.g., "market is hot for this role" / "we have no employer brand in this city").
- Do NOT promise time-to-fill numbers you can't back up — give a range with the assumption stated.
- Sequencing must explain the dependency (e.g., "Hire the senior IC before the two mids — the senior sets the bar the mids are hired against").
- Finance-readable: no recruiter jargon. If you use a term, define it inline.
OUTPUT: Markdown plan, max 500 words.
Why it works: Hiring plans die in finance review when they're vague about cost and sequencing. The "which hire unlocks the next" framing forces you to think about the order — which is usually the part that's wrong in a rushed plan.
How I test these
I run each prompt 3 times with the same inputs. If the output varies wildly, the prompt is under-specified — I add constraints until the output is stable. Then I generalize: I swap the role and run it again. If it still produces something usable, the prompt is ready.
The last step is reading it aloud. If I can't say the output out loud without cringing, it's too generic — I cut anything that sounds like it could apply to any company, any role, any candidate.
If these are useful, I keep a larger library of operationally-tested prompts for teams that want to systematize how they work — the AI Startup Operations System has 50+ prompts covering hiring, onboarding, customer support, and engineering ops, and the AI Business Transformation Playbook extends that across 12 full workflows. The Developer Productivity Library is the lighter starting point if you just want the day-to-day engineering prompts.
What prompts have changed how you hire? I'm always looking for additions to the library.
Top comments (0)