PP9: The Hiring Pack

You are a hiring manager writing a job description for a real role.

Here are the three sentences of need from the team:
1. [Need 1]
2. [Need 2]
3. [Need 3]

The role context:
- Team: [team name]
- Reports to: [role]
- Working pattern: [hybrid / remote / on-site]
- Salary band: [GBP range / USD range]

Produce a job description with:
- A one-paragraph 'why this role exists'
- Five must-have skills, each concrete and testable
- Three nice-to-have skills
- A 'first 90 days' section with three outcomes
- A short inclusive language statement
- The pay shown as GBP first, then USD in brackets

Then list:
- The three sentences in the job description most likely to filter out underrepresented candidates, and rewrite each
- The one question you need answered to sharpen this further

Keep the language plain and specific. No hype. No flattery. Do not use em-dashes.

Why it works: A job description is the first filter, and most of the filtering is accidental. Writing it from real need, then naming the lines most likely to exclude people, removes bias you would otherwise pay for later in a narrow shortlist.

You are an inclusive hiring specialist reviewing a draft job description before it is posted.

Here is the draft job description:
[Draft JD text]

Requirements that are genuinely non-negotiable for this role:
[Non-negotiables, or write 'none stated']

Review the text line by line for inclusion red flags. Look specifically for:
- Gender-coded language
- Unnecessary corporate jargon
- Unrealistic or unstated physical requirements
- Education requirements not actually needed for the work
- Experience inflation, meaning more years asked for than the role needs

For each issue, quote the exact phrase and give a more inclusive rewrite. Then split the requirements into must-have and nice-to-have, keeping any genuine non-negotiable. Suggest one structural change that would make the role easier to apply for.

End with the single most important question to resolve before posting.

No hype. No flattery. Do not use em-dashes.

Why it works: Coded language and inflated requirements shrink your applicant pool before you see it. Catching them at the draft stage is far cheaper than re-running a failed search.

You are a recruiter extracting structured data from one candidate CV so a shortlist can be compared fairly. Assume the candidate has been told that AI is used to organise application data; this prompt sorts information, it does not decide.

Here is the CV:
[CV text]

The role title is: [Role title]
The three key skills for this role are:
1. [Key skill 1]
2. [Key skill 2]
3. [Key skill 3]

Read the CV once for overall fit, then extract the following into a clean table, keeping facts separate from judgment:
- Total years of relevant experience
- Evidence of [Key skill 1]
- Evidence of [Key skill 2]
- Evidence of [Key skill 3]
- Highest level of education, or equivalent experience
- One gap or area that needs clarification later

Do not infer protected characteristics such as age, sex, ethnicity, or health, and do not score or rank the candidate. End with one line on whether there is enough here to make a shortlist decision.

No hype. No flattery. Do not use em-dashes.

Why it works: Structured extraction makes candidates comparable on the same facts, and the disclosure and no-scoring rules keep it the right side of fair-hiring practice. The tool organises; you still decide.

You are an interview designer building a behavioural question ladder so that different interviewers test the same thing in the same way.

The core competency to test is: [Core competency]
The role context is: [Role context]
A specific gap or risk to probe, if any: [Gap from the CV stage, or write 'none']

Create a three-level question ladder for this competency:
1. Surface level: a broad question to understand their general approach.
2. Application level: a scenario question to see how they apply it in real work.
3. Stress level: a question about a time they failed or faced real pushback on this competency.

For each question, write one line on what a strong answer sounds like and one line on what a weak answer sounds like. Keep the questions tied to real work, not abstract theory.

No hype. No flattery. Do not use em-dashes.

Why it works: Consistency is what makes interview feedback worth comparing. A shared ladder means a strong answer from one candidate means the same thing as a strong answer from another.

You are a hiring manager synthesising interview feedback into one recommendation.

Notes from the three interviewers:
- Interviewer 1: [Interviewer 1 notes]
- Interviewer 2: [Interviewer 2 notes]
- Interviewer 3: [Interviewer 3 notes]

The core role requirements are:
[Role requirements]

Compare the notes against the requirements and produce:
- Areas of strong consensus, with the evidence behind each
- Areas of disagreement or conflicting signals
- A clear recommendation: Hire, No Hire, or Need More Data
- If the recommendation is Need More Data, the exact question that would resolve it

Separate fact from opinion throughout. If a view is not backed by evidence from the interview, say so.

No hype. No flattery. Do not use em-dashes.

Why it works: Hiring decisions go wrong when opinion outweighs evidence. Forcing consensus, disagreement, and evidence gaps into the open makes the recommendation one you can defend.

You are a hiring manager preparing for a reference check call.

Candidate: [Candidate name]
Role: [Role]
Area of concern from the interview: [Area of concern]

First, write a two-sentence opening script that gets the referee's consent and sets the context for the call.

Then generate five specific questions:
- Two that verify general performance in similar roles
- Two that probe the area of concern directly
- One about the environment in which the candidate does their best work

Keep every question open enough to invite detail rather than a yes or no answer.

No hype. No flattery. Do not use em-dashes.

Why it works: References are only useful when they are specific. Anchoring the call to the interview concern, with consent up front, gets you usable detail instead of polite generalities.

You are a talent acquisition partner analysing a competitive offer situation before the closing call.

Candidate priorities: [Candidate priorities]
Our offer: [Our offer details]
Known competitor offer: [Known competitor offer details]

Separate confirmed facts from assumptions, then analyse:
- Where our offer wins, judged against the candidate's stated priorities
- Where the competitor offer wins
- The single most likely deciding factor
- Three specific talking points for the closing call that highlight our real value, with no inflated claims

Show any pay figure as GBP first, then USD in brackets.

No hype. No flattery. Do not use em-dashes.

Why it works: Counter-offers are won on what the candidate actually values, not on matching every line. Separating fact from assumption stops you negotiating against a guess.

You are a hiring manager writing an onboarding plan for the person you have just hired.

Here is the final job description:
[Final JD text]

Any team priorities or success measures for the first quarter:
[Priorities, or write 'none stated']

Draft a 90-day onboarding plan in three phases (first 30 days, days 31 to 60, days 61 to 90). For each phase, define:
- One primary learning objective
- Two concrete deliverables or milestones
- The key people they need to meet, and why

Keep every item realistic for the role and grounded in the job description.

No hype. No flattery. Do not use em-dashes.

Why it works: The first 90 days decide whether a hire sticks. A plan drawn from the job description gives the new joiner, and their manager, the same definition of early success.