Cheeky title aside, this post is about a topic that weighs heavily on me, both as a person who does occasionally look for a new job, and as a senior developer who routinely interviews prospective coworkers.

I’ve been a part of many interview loops across several organizations (as a candidate and interviewer), and I can say one thing for certain: We can do better.

This isn’t to downplay how devilishly tricky it is come up with an interview process that uniformly, across the board, will always flush out the best talent. It’s a bitch. And if companies like Google, Facebook, and Netflix still don’t feel like they’ve got it completely right, that should highlight just how difficult it is.

Gaining a developer who is technically gifted, gets along great with the team, and communicates effectively is like striking gold. In fact, I think getting a hundred percent hit on all of those qualities is basically impossible. To borrow from an overused visual aid (this author is stealing from Datastax’s DB consistency graph), it’s almost as though we have a triangle with three points, each representing one of the following qualities: Technical Skills, Culture Fit, Communication and Soft Skills. Every one of us lands somewhere in this triangle, but by virtue of its shape, we can never quite reach the maximum potential of all three.

You may not agree with that, but, hang with me, because I think this is part of the reason why hiring is so difficult. We enter into the hiring process saying we want “the best” candidate without defining what that means, or, without seriously considering what that means in context of the vacancies we’re trying to fill.

For example, if you already have a team of super-genius coders with strong personalities who disagree constantly with each other, do you really want to add another person just like this to the mix? Or do you need an engineer with excellent soft skills to bridge the gaps and get the project moving forward again?

I want to share an anecdote, with identities and situations changed for my protection.

Once upon a time, a growing product team needed more engineering talent. The team had an engineer who had went through an exhaustive architectural review process with his senior leadership, and it was time to write some code. What the situation truly called for was a couple of mid-level developers with good technical skills, solid experience, and great teamwork. People who could work together on implementing the architecture together, with direction from the senior engineers.

What the hiring process provided, however, was another two senior-level engineers, described by those in the interview loop as “Rockstars.” Engineer A spent most of his time arguing with others about the approved architecture rather than writing code. Engineer B was more interested in getting into a rest-and-vest situation, constantly looking outside of his product team for work which he could claim was stealing his time from actual development.

This isn’t to say that A and B were bad engineers. They simply weren’t right for the roles they were put in. A may have been well-suited to work on a greenfield project where he would have more say in the design. B may have been better in an architecture or consulting role at an enterprise dev shop. The end result was a lot of wasted time and money for two hires who should have been helping propel the product over the finish line, but actually dragged it down and caused further delays.

So what went wrong? This is the question we should be asking ourselves when these situations occur, and occur they do. Asking this of myself repeatedly has led to some insights, which I hope would prove useful to other engineering teams.

Given that needs will vary based on role, my observations are that the following practices tend do more harm than good:

• Spray and Pray Hiring
• Inconsistent Standards Among Interviewers
• Skipping Interviewer Training
• Lack of Focus or Goal for Vacancies
• Groupthink
• Creating a Clone Army

Spray and Pray

To borrow a term from my time in the Army, Spray and Pray was a euphemism for laying down suppressive fire. Or, shooting toward the enemy, not caring if you hit anything, just to keep them from moving. In the best case, it let your team advance. In the worst, it kept things at a standstill.

The hiring equivalent to indiscriminately dumping rounds downrange is job advertisements that don’t actually map up to a specific role, coupled with a cookie-cutter interview loop. We are looking for a generic engineer, and we will submit you through all of the generic engineer interview processes. Can you identify the complexity of this algorithm? Can you solve this coding test? You’re in.

This hiring methodology takes none of the specific skills of the candidate into consideration. It’s a tempting approach, especially from an HR perspective, as it makes the process well-documented, defensible, and reproducible.

An antidote to this is to introduce interviews as part of your loop which are designed to flush out the qualities you need for the role. If a candidate got through the technical screening just fine and you need a great communicator, why not focus on that for an hour instead of seeing how well they can solve (yet another) HackerRank challenge. Ask the behavioral questions, give them hypotheticals, ask them to explain a difficult topic.

Inconsistent Standards Among Interviewers

This overlaps a bit with skipping training, because some of these issues could be weeded out with training. Some.

Inconsistencies abound during interview loops. It’s to be expected, really, that we all value different qualities in a candidate. The important thing is to be clear about what you are looking out for, and your grading standards. So at the end of the loop, when everyone involved is on that final assessment call, we can be clear about how each interviewer made their decision.

An example of this would be how we administer coding tests. I’ve worked with engineers who cared only about the final outcome of the coding test. Did their solution work, or not? I, however, disagree with this approach, and feel the exercise is more about seeing how a person thinks rather than how quickly they can hack together a solution to FizzBuzz. Maybe they only solved it quickly because they’d done the problem before. Maybe they only struggled because they were nervous and missed a step, but their approach was basically solid. We need to pay attention to these things.

Skipping Interviewer Training

How many of us have started a new position and within a month found ourselves already conducting interviews? I’m guessing most of us. It’s nuts, right? Sure, I suppose there are interviewing fundamentals that transfer across companies; the legal stuff, mostly. But how are you supposed to fairly and accurately evaluate a candidate according to the company standard, when you don’t even know what that standard is?

A friend of mine from college told me about how after starting his first job as a senior-level engineer, he was put in this situation. His manager sent him a link to the HR interview training documents. Most of which were outdated, and none had anything specific to say about how a technical interview loop should be conducted. When he asked his manager for guidance, he was told to use his best judgement. Full stop. As you can imagine, their hiring process was a mess, where no one could seem to agree on anything, and management continually found themselves staffed with new engineers who didn’t fit in well with the team.

Groupthink

It takes a strong personality to stand up to another strong personality. Also, the motivation to do so. It’s this second part that fails over time.

At a previous job, I noticed a trend emerging at the end of each interview loop. One or two of the most outspoken managers would provide their assessment of a candidate, often speaking for much longer than their allotted time. At the end of their pontification, the rest of the votes would almost unanimously fall in line with their decision. Even if I knew for a fact other interviewers had felt differently coming in to the meeting, they’d change their vote to match the loudest voice in the room.

Why? It was something I was even guilty of a time or two. Why did I change my vote? Why did others change theirs?

After one of the candidates I really liked didn’t make the cut (and I was the lone voice speaking up for them) I decided to do a little digging. I talked to a friend of mine who I knew was also going to vote for the candidate before the meeting. “Why did you change your mind?” I asked him.

“There’s no point in arguing with that guy,” he said.

And so it goes. As in so many aspects of life, the strong personalities who refuse to give ground will find a way to brow-beat dissenting opinions into submission. Not by the strength of their arguments, but by sheer persistence.

Creating a Clone Army

Another common trap is the tendency some people have to want replicas of themselves to join the team. In a way, I get it. We all want to work with other people who share our opinions and laugh at the same jokes, but, in reality there really is strength in diverse viewpoints and skillsets.

A team of engineers with diverse skillsets and favorite focus areas will only strengthen your product by increasing the overall breadth and depth of the team’s combined experience. If you’ve got a five-person team who all specialize in Rest API design, versus a five-person team consisting of people who respectively specialize in Rest API design, multi-threading, data-modeling, microservice frameworks, and architecture – which team is going to get a better product out faster?

I once sat as co-pilot on an interview where our team’s director grilled a candidate for an hour about threads and locks. It wasn’t a helpful interview strategy, but the director stuck with it simply because that was his wheelhouse and he wanted to be an expert. But what use would it have been to hire a developer after only testing them on one area of knowledge? Our primary product wasn’t even a multi-threaded application. His default tactic resulted in hires that had the same area of expertise as him. It wasn’t helpful.

In Summary

Like many complex issues, there’s no silver bullet here. If experience is any guide, however, hiring gets a lot more effective when we take the time to honestly evaluate what we’re doing an why, while keeping a sharp on who it is we need to fill that empty desk. I hope that some of these observations will prove useful to someone out there.