Some time ago, before I founded Honor Tech, I held a management position that included interviewing and hiring software developers.
During that period, I interviewed a candidate who seemed almost too good to pass up.
This was before nearly every interview was conducted through Zoom or Microsoft Teams. The interviews took place in person, so there was little question that the candidate was producing his own answers without outside assistance or hidden tools.
He answered the technical questions exceptionally well, communicated clearly, and performed strongly across multiple interviews. We also gave him a coding assignment, and his work confirmed what we had seen in person. He appeared to be a highly capable developer with a great deal of potential.
As part of the hiring process, I called several of his former supervisors. I did not limit myself to the personal references he had selected, since candidates naturally choose people who are likely to speak positively about them.
Most of the conversations were encouraging, but one former supervisor hesitated.
The supervisor said something along the lines of, “He had some personal problems for a while, but he got past them.”
There was not much additional detail.
It was not a direct warning, and it was certainly not enough to prove that the candidate would be unsuccessful. People experience difficult periods, recover, and move forward. A vague statement about someone’s personal life should never become an excuse to pry into private matters or make assumptions that have nothing to do with the job.
Still, I remembered the hesitation.
At the time, however, the candidate’s interviews and technical performance were so impressive that we decided to hire him.
At First, It Looked Like the Right Decision
For a while, he did excellent work.
He was technically capable, but he was also good with customers. That combination is more valuable than many people realize.
A developer can write excellent code and still cause problems if customers do not trust them, cannot understand them, or feel uncomfortable asking questions. This developer had no such difficulty.
During system go-lives and support visits, customers responded very well to him. In fact, some customers liked him so much that they would invite him to join their internal division potlucks and insist that he eat with them.
That may sound like a small detail, but it meant something.
The customers did not merely tolerate him as the technical employee assigned to their project. They saw him as approachable, helpful, and welcome.
From both a technical and customer-service perspective, he initially appeared to be an excellent hire.
Then the Work Began to Change
The decline did not happen all at once.
At first, his work simply became less consistent. Tasks that would previously have been completed correctly began coming back with problems. Details were missed. Quality slipped.
Over time, the problem became more serious. Eventually, very little work was being completed at all.
What made the situation especially difficult was that he continued to show up every day. From the outside, it could appear that everything was normal. He was physically present, but the expected work was not moving forward.
Then came the explanations and excuses.
Eventually, the difference between attendance and actual performance became impossible to overlook, and he had to be let go.
It was unfortunate because the ability had clearly been there. We had seen it during the interviews, in the coding assignment, and during his early work. He was not someone who lacked technical talent or the ability to communicate with customers.
The problem was consistency.
The Lesson Was Not to Automatically Reject Someone
The lesson I took from this experience is not that one negative reference should automatically disqualify a candidate.
References can be incomplete, unfair, or influenced by a poor relationship with a former supervisor. People can also experience temporary difficulties and genuinely recover from them.
A hiring decision should never be based on vague speculation about someone’s personal life.
The lesson is that hesitation during a reference call should not be dismissed simply because the candidate performed well in an interview.
It is usually easy for a former supervisor to say, “Yes, they were great. I would hire them again.”
It is considerably harder, at least for most people, to pause and say, “There was one issue you should know about.”
That hesitation may be the most important part of the call.
Strong Interviews Can Create Blind Spots
A great interview can create a powerful positive impression.
Once we become excited about a candidate, it is easy to reinterpret every concern as unimportant. We may tell ourselves that the former supervisor was probably overly demanding, that the issue happened years ago, or that the candidate’s technical talent outweighs any possible risk.
Sometimes those conclusions are correct.
Other times, they are simply the result of wanting the candidate to be as good as they appeared during the interview.
This is a form of confirmation bias. Once we believe we have found the right person, we begin giving more weight to information that supports the hiring decision and less weight to information that challenges it.
That does not mean we should treat every vague comment as proof of a serious problem. It means we should slow down and ask better questions.
Keep the Questions Focused on Work
When a former supervisor raises a concern, the goal should not be to investigate the candidate’s private life.
The goal should be to understand whether there was a job-related pattern.
A hiring manager can ask:
These questions keep the conversation focused on workplace behavior rather than personal circumstances.
A reference call should also be considered alongside the rest of the hiring process.
Interviews reveal how a person communicates.
Technical assignments demonstrate whether they can perform a particular type of work.
References may provide information about how consistently they performed over a much longer period.
Each method answers a different question.
Technical Ability Is Only Part of the Job
Software development interviews often place enormous weight on technical knowledge. That makes sense, but technical skill alone does not determine whether someone will succeed.
A developer must also be dependable. They must communicate when something is blocked, respond to feedback, maintain a reasonable level of quality, and consistently move work toward completion.
A brilliant developer who performs well only intermittently can create more risk than a less impressive developer who reliably delivers solid work.
The candidate in this story really was talented. His interview performance was not fake, and his early success was not imaginary. The customers who liked him were responding to genuine strengths.
But talent demonstrated during an interview is not the same thing as dependable performance over time.
That distinction has stayed with me throughout my career and continues to influence how I think about building technical teams at Honor Tech.
A great interview can tell you what someone is capable of doing.
A candid reference may help you understand whether they are likely to keep doing it.
Do not automatically reject the candidate. Do not make assumptions about their personal life. Do not treat one former supervisor’s opinion as unquestionable truth.
But do not ignore the hesitation, either.