They're suffering from a specification problem.
The Hiring Reality Report tells you which one you've got. One brief, one written judgment, forwardable to the hiring manager. We don't analyse the candidate. We analyse the role.
What a diagnosis looks like
The headline is the part a recruiter forwards. The full report carries the reasoning, the ninety day forecast, and the scope edits.
Security Architect. Open ninety days.
The title says architect. The deliverables are governance.
Senior architects read the gap between the title and the scope inside the first paragraph and don't apply. The shortlist fills with candidates who haven't spotted the gap yet, which is why round two is where the role keeps breaking.
Cloud Engineer. AWS hard-required.
You're hiring an AWS engineer for an almost entirely Azure estate.
The strongest applicants on paper will spend their first quarter unable to touch the platform they were hired to run. The candidates who'd actually be productive on day one screen themselves out at the job title.
Cloud Operations. Architecture asks.
The seat is scoped as operations. The work is platform design.
Operations engineers see the title and apply. Platform architects see the salary band, read it as a junior seat, and skip the brief. The hire either underdelivers against the deliverables or overdelivers and leaves inside a year.
Reader fit
Useful if
Not for you if
What you actually get
A worked example. The four output fields are the product.
Cloud Security Engineer
London. Hybrid. £85k to £100k.
AWS, Azure, Terraform, Kubernetes, incident response, security tooling (CSPM, SIEM, EDR), three years minimum in a security function.
Seventy two days. Two offers declined.
You receive
The role is open because the brief is hunting the wrong pool.
You're hiring a security person for a cloud engineering problem. The deliverables are platform ownership. The brief filters for a security background that won't have touched a Terraform module in anger.
Strong cloud engineers never enter the process. Security candidates who pass the screen will stall in the technical round on infrastructure as code.
Reframe the seat as cloud platform ownership with security accountability. Move the three year security minimum to two years of production cloud engineering. The pool you want reads platform titles, not security ones.
The full sample carries the reasoning behind each field and the ninety day forecast if the brief doesn't change. Read it at recruiters/sample.
The shift
POST doesn't tell you whether a candidate is right for the role.
It tells you whether the role is right for the market.
When recruiters use it
Recruiters don't think in pathologies. They think in moments where the search is about to break, or already has.
When a new brief arrives
Run it before you start the search. If the brief is hunting the wrong pool, you find out on day one instead of day sixty.
When a role has been open sixty days or more
Replace 'the market is tough' with a specific written diagnosis the client can act on. Stops the search from being quietly written off.
When candidate quality is lower than expected
If the strongest applicants on paper would struggle on day one, the brief is filtering for the wrong background. The report names which background.
When the hiring manager insists the market is the problem
Most won't move on a recruiter's word. They'll move on a written third-party judgment that explains why the seat is staying open.
Before committing to a search you're unsure about
Some briefs aren't fillable as written. Knowing that before you pitch the fee changes the conversation you have with the client.
How it works
You send us the brief. We return a written diagnosis covering what's wrong with the role as specified, why that's keeping the seat open, what the next ninety days look like if nothing changes, and the specific scope edits that would change who applies. Built on POST's practitioner-authored assessment framework. If the brief doesn't carry enough evidence to support a diagnosis, the report says so and names what's missing rather than guessing.
Read the full sample at recruiters/sample.
What helps HRR see the shape of the role
Most recruiter briefs already carry enough for a confident diagnosis. Where they don't, HRR will tell you exactly what's missing rather than fill the gap with a guess. There are no mandatory fields. The five things below are what tend to make a diagnosis sharper.
Responsibilities and deliverables
What the hire is actually expected to ship in the first six months.
Technologies or capabilities
Tools, platforms, or domains the work touches. Brand names are fine, outcomes are better.
Team and reporting context
Who they sit with, who they report to, whether anyone reports to them.
Success measures
What good looks like at six and twelve months. Even one line changes the diagnosis.
Ownership or scope
Whether the seat owns a platform, supports one, or sits across several.
The issue is never length. It's evidence. Short briefs with clear ownership and outcomes diagnose cleanly. Long briefs that list tools without context often don't.
Hiring Reality Report
One price. The report is the product. Send a brief in, get a written diagnosis back with a rewritten brief you can forward to the hiring manager.
Full report on screen and by email
Read it in the browser, send the PDF to the client. Same content either way.
Rewritten brief included
A version of the role filtered for the work the seat actually does, ready to send to the hiring manager.
Refunded if we can't diagnose
If the brief is too thin for a reliable diagnosis, HRR tells you what's missing and the report is credited back.
Reports stay accessible
Every link you've been sent keeps working, so the hiring manager can come back to it weeks later.
Send the role you'd commission first. The brief becomes your HRR and the link arrives by email when it's ready.
Request a Hiring Reality Report