I’ve had a pretty firm stance on interview feedback since I was in my early teens.
Silence in hiring doesn’t sit right.
Not because I need to log feedback somewhere.
Because candidates want to understand what happened, and if I’m the one who brought them into the process, I should be able to tell them.
So I make the calls. Even when it’s a “no.” Especially when it’s a “no.”
Recently, that mindset got tested.
The Pattern I Couldn’t Ignore
We were running candidates through a technical evaluation for our automation gigs.
I had 2 pass the test and 7 candidates fail.
The frustrating part? I liked a lot of these candidates. Strong conversations, good instincts, people I felt confident putting in front of the team.
So I pulled my engineering manager aside and asked a simple question:
What are we actually seeing here?
He walked me through it in plain terms:
- Some candidates weren’t using data-driven practices (hardcoding test cases)
- Others had logic flaws in their test flow (scripts that could falsely pass or fail)
Clear feedback. Actionable. Helpful. So I did what I normally do.
I took it back to the candidates.
The Moment It Flipped
The first call I made was to one of the candidates I genuinely thought was strong and really liked.
I explained the feedback around hardcoding.
He paused and asked:
“Are you by your computer?”
I said yes.
He sent over his code and said, “Pull it up, I’ll walk you through it.”
I told him straight up: I’m still learning how to read code.
His response: “Don’t worry, I got you.”
And then he walked me through everything.
What he had actually done was submit two things:
- His working notes (like showing your work on a math test)
- His final, clean solution
At a glance, it looked inconsistent. Some parts data-driven, some not.
But when he explained it, it was structured. Intentional. Thought through.
It just wasn’t being interpreted that way.
That’s When It Clicked
This wasn’t just a candidate missing the mark.
This was a gap in how we were evaluating.
So I went back to my engineering manager. This time, with better questions.
Not “why did he fail?” but:
- How are we reviewing these submissions, step by step?
- What are we prioritizing when we look at them?
- What context are we missing?
What I learned:
My manager had reviewed the code, but the not the video on this one. Had he reviewed the video he would’ve seen the explaination and walk through of what I would consider the “clean code”. He had a specific way of reviewing but based on the feedback, we fixed it.
What We Changed
Nothing dramatic. Just intentional.
- We refined how submissions are reviewed internally
- We aligned on what “good” actually looks like in practice
- We introduced a clearer structure for candidates (including a README to guide reviewers)
Small changes. Big difference.
Because now:
- Candidates can better present their work
- Reviewers can evaluate more consistently
- And we’re actually assessing what we think we’re assessing
The Outcome
That specific candidate didn’t move forward.
But his feedback changed our process.
And that change?
It helped turn a “no” into a “yes” for someone else down the line.
The Part People Miss About Feedback
Everyone says they value feedback.
But most of the time, it’s treated as a formality:
- Logged
- Filed away
- Maybe acknowledged
Rarely used.
This was a reminder that feedback isn’t just something you give.
It’s something you build with: if you’re willing to listen from both sides.
From the hiring team.
And from the candidate.
What a Real Partnership Looks Like
That moment, where a candidate walked me through his thinking, shifted how I operate.
Because the best hiring processes aren’t one-directional.
They’re a loop.
And sometimes, the clearest signal doesn’t come from the interview itself…
It comes from what happens after you think you already have your answer.