My five-point ranking system to evaluate tech candidates
I’ve been remarkably blessed in the technology industry. I’ve held many roles, and worked with and hired many great people in various capacities.
Our process to evaluate and hire tech candidates centers on a rating scale of negative and positive impressions. Here’s how it works.
A 1-5-point system to evaluate tech candidates
We rank interviews with a 1-5 numbering system. It’s less a judgement of the person , and more about considering how much we value them as a potential employee. Multiple people in my team interview each candidate.
Here’s what each score means:
- “I will quit if we hire this person.” This is the harshest rejection one can offer. It should be rare, because someone with this level of red flag should already be filtered out of the hiring process. This response also indicates that the filtering process has failed and must be reevaluated.
- “I can make an argument to prevent this person from being hired.” This negative response also can triggers a veto.
- “I don’t know, maybe they’ll work out, who can say?” The interviewer has no real information to commit to a “yes” or “no.” It’s neither strong support nor rejection
- “Yes, and I can argue for why we should hire this person.” The interviewer saw enough in the interview to lead them to think that this person would be a positive asset for the team.
- “I give blanket approval.” The interviewer was greatly impressed with the interviewee and thinks this person is an excellent fit for the team.
We also have a silly rating of 6, which is the literal inverse of a score of one: “I will quit to make room for this person on our team.” In reality, of course, this is highly unlikely and impractical.
In general, this numbering system establishes a watermark for failure — anyone who receives a “two” or a “one” is eliminated from contention. A score of “one” also indicates that the consideration process itself isn’t working very well.
As a final step, we calculate the average of the candidate’s total score. We’ve hired people at 3.7 or higher with great success, and we’ve, yet to see a failure with anyone at a 4 or better. Success rates go down exponentially the closer you get to a 3. For example, an average score of a 3.1 indicates that one interviewer thought they were a great asset to have, but everyone else thought they were fairly ordinary. That’s probably a thumbs down on the hire.
I try to have as many people as possible interview each potential hire. Afterward, we compare notes and scores and discuss or justify any negative ratings. If someone gives a hire a “two” and someone else gives them a “four” maybe the “four” convinces the “two” to raise it to a “three,” or the “two” explains to the “four” what the problem is and the four gets changed to a three.
If the negative scores remain after discussion, we apply a veto and reject the hire. There’s no anger; someone felt ” this person would be toxic,” and even the fear of toxicity would be enough to create the negativity.
After all that, if the score is high enough — again, probably at least a 3.5 or a 3.7, but obviously you want the highest average — then we recommend to hire the candidate.
One rule above all: Don’t hire a jerk
There’s one more factor when I evaluate tech candidates, or any other role, for my team: I will not hire a jerk. This rule is non-negotiable.
It doesn’t matter how skilled a programmer is. I can find technical skills or resources. The information is out there, maybe even published by the same jerk.
Besides, it’s not just me who decides that. Everyone gets a veto, and it’s absolute. If three out of four thought the hire was solid, but the fourth thought the hire was toxic, that fourth person “wins” and we nix the candidate.
No matter how fantastic a candidate’s technical skills are, how low their rate might go, or how well-known they are, the costs are simply too great to take on a toxic personality. Hiring a jerk is never worth it, ever.
Joseph B. Ottinger teaches developers and architects about technologies to develop applications, from systems design and architecture to project management. He has held senior roles in software engineering, development and management, with knowledge that spans various languages and architectures.