How to write rejection feedback that is actually useful

The reason most feedback is bad

Not laziness. The scoring was not specific enough to produce feedback.

If a decision came out of an unstructured conversation and a debrief where people compared impressions, there is no specific thing to tell the candidate — because there is no specific thing that was measured. What is left is either a form letter or an improvisation, and the improvisation is where the legal discomfort comes from.

Which means the feedback problem is usually a scoring problem wearing a communication costume. Fix the scoring and the feedback becomes almost mechanical. This is one of the underrated returns on structured interviews and a rubric written in advance: the artefact that lets you decide is the same artefact that lets you explain.

A useful diagnostic: if you cannot write two specific sentences about why a candidate was not advanced, you do not know why. That is worth noticing before you send anything.

The structure

Four parts, in this order.

1. The outcome, immediately. First line. No preamble, no "thank you for your interest in joining our journey". The candidate is scanning for one piece of information; making them hunt for it is unkind.

2. What was assessed. Name the dimensions. This does two things: it shows the decision had a basis, and it lets the candidate calibrate rather than guess.

3. Where they stood. Per dimension, honestly. Include what was strong — not as a cushion, but because it is information they can use in their next application.

4. The single most valuable change. One thing. Not five. The highest-leverage gap, stated concretely enough to act on.

Then stop. Do not add an invitation to reapply unless you mean it, a promise to keep them on file unless there is a real talent pool, or a paragraph about how strong the applicant pool was.

Safe and unsafe, concretely

The line is simple: performance against a defined criterion is safe; inference about the person is not.

Do not write	Write instead
Not senior enough	Below the bar on system-design depth: the design handled the happy path but not partial failure
Not a culture fit	We assess written communication in a design document; yours assumed reader context that was not established
Seemed nervous	Scored 2 of 4 on incident response: the answer moved to a fix before establishing blast radius
We went with someone more experienced	Two candidates scored higher on the same rubric, primarily on data-modelling depth
Not enough energy for the team	Not assessable against our criteria — remove it entirely
You'd be great for a different role	We do not currently have a role matching your strongest dimensions

The right-hand column is longer, more specific, and less legally exposed — because every statement refers to a job-related criterion applied to every candidate. The left column is short, vague, and invites the question "what did you actually mean by that?", which is precisely the question you do not want asked.

Bear in mind too that in GDPR-style regimes, interview notes and scores are generally the candidate's personal data and can be requested. Writing notes you would be comfortable sending is the discipline regardless — see GDPR and candidate data.

Growth framing, not softening

These get confused. Softening removes information to reduce discomfort. Growth framing keeps all the information and adds a direction.

Softened: "It was a really competitive process and unfortunately we've decided to move forward with other candidates, but we were impressed with your background."

Contains: nothing.

Growth-framed: "You weren't selected to advance. You scored strongly on React architecture and TypeScript — top quartile of applicants for this role. The gap was system-design depth: your design handled the happy path but not partial failure of a dependency. That is the single highest-value thing to practise, and it is the most common gap we see at this level."

Contains: the outcome, the criteria, where they stood, and what to do.

The second is harder to read and enormously more valuable. It also demonstrates that a real assessment happened, which is the thing candidates most doubt.

Two small mechanics that matter: name the strength specifically (a generic compliment reads as padding), and normalise the gap where it is genuinely common — "the most common gap we see at this level" is true information that removes a lot of unnecessary self-doubt.

Tier it, or it will not survive

Feedback quality collapses under volume unless you decide in advance how much each candidate gets.

• Did not progress past application — automated outcome, promptly, naming what was assessed.
• Completed an assessment — automated outcome plus their standing on each measured dimension.
• Interviewed — human-written feedback against the rubric, a short paragraph per dimension.
• Final stage — offer of a call.

Automating the floor is what makes the top sustainable. A team trying to hand-write feedback for 400 applicants will write it for the first thirty and ghost the rest.

How CalHire generates it

On CalHire the report card is not an extra step someone remembers to do — every applicant receives a growth-framed report card, enforced in the product, and the word "rejected" never appears.

It works because the feedback is a by-product of the scoring:

• The composite score is built from a skills test, a text interview and role-fit, with visible weighting, so a candidate's standing on each dimension already exists as data.
• The report card renders that: what was strong, the dimension to grow, and a suggested next step — with a tailored practice set where relevant.
• Because evaluation is anonymous, the feedback is necessarily about demonstrated skills rather than background, pedigree or impressions. That makes it both more useful to the candidate and far safer to put in writing.
• Nothing is auto-rejected — below-threshold candidates are flagged for human review — so every outcome has a person behind it.

See the features page for the zero-ghosting mechanics and for candidates for what a report card looks like.

The short version: you cannot write good feedback about a decision you cannot explain. Get the rubric right and the feedback stops being a writing problem — it becomes a rendering problem.