August 27, 2026·6 min read
Nine candidates out of ten get the same email. "We have decided to move forward with other candidates. We wish you the best." It arrives eleven days after a four-hour process, it says nothing, and everybody involved knows it says nothing.
The strange part is that the information exists. Somewhere in your ATS is a debrief where four people wrote down precisely what happened and reached a decision in twenty minutes. The candidate is the only person in the process who never learns what it said.
Then you wonder why the same people ignore your recruiter twelve months later, when they are exactly the hire you need.
Not laziness. Three real fears, and one of them is legitimate.
"Legal said no." Legal usually said something narrower than what got repeated down the chain. The concern is comparative statements ("we found someone stronger") and anything touching a protected characteristic. Specific, behavioural, job-related observations are the safest thing you can send, not the riskiest. Check with your own counsel rather than with the story going round the recruiting team, because in most places the version everybody repeats is stricter than the advice that was actually given.
"They will argue." Some will. A candidate who did badly and does not want to know is a candidate who writes back to relitigate the session. This is a real cost and it is smaller than it feels: it happens rarely, it takes one polite reply, and the alternative cost is invisible only because rejected candidates say nothing to you and quite a lot to each other.
"We do not know what to say." This is the honest one, and it is not a communication problem. If your debrief produced "not a strong enough coder" then there is nothing to send, because nothing was learned. The feedback problem is downstream of the assessment problem.
Feedback is safe, useful and quick when it describes what happened in the session rather than what you concluded about the person.
"You seemed junior" is a verdict about a human being. It is unsendable, unarguable, and it is also not true in any checkable way.
"The service was failing on a connection timeout. You spent most of the session in the application code, and the fix was in the pool configuration. When you did reach the config, you got there quickly." That is a description. It is specific, it is checkable, the candidate recognises it because they were there, and it tells them the thing worth knowing: their debugging was fine and their search order cost them the hour.
The second one is not longer to write than the first. It is only harder to write if nobody wrote down what happened.
One thing that was genuinely good, named specifically. Not a compliment sandwich. If a candidate reads a real, specific strength, they believe the rest of the email. If line one is "you have a great attitude", they skip to the end.
The one thing that decided it. One. Not five. There is always a primary reason, and the debrief knows it. Listing five reasons reads as building a case, and it obscures the single thing worth working on.
What a stronger answer looked like. This is the part that turns feedback into something a person can use. "The candidates who cleared this round reached for the logs in the first ten minutes rather than reading the code first." You are not giving away the assessment. You are telling them how the job works.
Whether to come back, and when. Say it plainly. "Please apply again after you have shipped something in production with Kubernetes, and mention this email." A no with a door in it is a completely different message from a no.
No comparisons. Not to other candidates, not to a bar, not to a percentile. Comparisons are the part legal really does mean, and they add nothing.
Feedback four days late is worth a fraction of feedback the next morning, for a reason that has nothing to do with courtesy. The candidate still remembers the session. They can map "you spent the hour in the application code" onto an actual memory, feel the recognition, and learn from it. Two weeks later it is an abstract claim about a stranger and the only available response is defensive.
Fast also protects you. The person writing it has the details in their head instead of reconstructing them from four lines of scorecard.
The reason feedback is hard to write after a whiteboard round is that a whiteboard round produces impressions. You remember a feeling about the candidate and very little else, and a feeling is exactly what you cannot send.
A session on a real machine produces a record. In EasyEnv the candidate works on an actual box, and the session is recorded, so a week later you can say what they ran, in what order, where they stopped, and what they did when the first approach did not work. You are not remembering the interview. You are reading it.
That changes the economics. The observations that make feedback useful are already sitting in the debrief because they are what you assessed on, and writing the email is transcription rather than reconstruction. Teams that struggle to send feedback are usually not unwilling. They are being asked to describe something nobody recorded.
The same record is what makes the feedback safe. Every sentence you send points at something that happened, which is the standard your counsel wants anyway.
A rejected candidate who received something useful will tell people about your process. Some of them apply again eighteen months later, better, and skip your top-of-funnel entirely. Some of them send you a colleague. Almost none of them post about you.
You cannot attribute any of this in a dashboard, which is why it keeps losing to the template. It is still the cheapest hiring channel you have, and it costs six lines written the morning after the interview.
If your interview does not currently produce enough to write those six lines, that is the finding. Start there, not with the email template. The interview debrief that actually reaches a decision is where the raw material comes from, and why your best candidates drop out of the funnel covers what else the process is costing you.
What did your last rejected candidate learn from you?
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Teams assess whether engineers can use AI well and never assess what they feed it. Here is what AI security literacy actually covers, why a code review will not catch a leak, and four interview exercises that surface it before it becomes an incident.
A working list of system design interview questions grouped by what they actually test, plus a weak-versus-strong answer transcript and a rubric for scoring the conversation instead of just the final diagram.
Read more
LeetCode's hiring product is a legitimate, well-built screen for algorithm-heavy roles. The trouble starts when it gets used to screen roles it was never built for. Here is how to tell which situation you are in, and what to look for in a real-environment alternative.
Read more
