The Business Stakeholders Guide to Hiring Software Engineers: Part 1

This three-part series is a guide for business stakeholders who don’t know how to conduct a technical interview for software development candidates. You don't need technical knowledge to benefit from being an observer in an interview.

This series reveals the talent acquisition hacks you need to hire the best software developers. They come in the form of a number of critical do's, don'ts, and guidelines that you should follow, which require no technical knowledge at all.

The three parts of the series are:

• Part 1: Never Allow Techs to Interview Candidates Alone
• Part 2: Avoid Coding Exercises
• Part 3: How to Assess Proficiency, Competence, and Skills

Here’s the challenge.

You have software developers reporting to you, but you don’t have a coding background, so when the time comes for you to hire, you don’t know how to vet a software developer candidate. As a consequence, you’re forced to rely on currently employed software developers to conduct technical interviews for you. If this describes your situation then you’re in the right place.

This part of the series explains the first rule that you should follow.

Never Allow Techs to Interview a Candidate Alone

Typically, when a candidate shows up for the technical interview, non-technical managers hand the task off to currently employed developers, that are would-be peers, to conduct the interview expecting a thumbs up or down later. I will tell you plainly that … you should never – EVER – do this.

My advice: Always be present with the developer assigned to do the vetting, make yourself a fly on the wall observing the interview, and take notes. You should not consign 100% of the responsibility of evaluating candidates to developers for the technical interview.

Here’s why.

Developers Can Be Biased

Developers are human after all, and on average they exhibit the average flaws of the average human being. This includes several biases.

For example, many developers tend to see other developers as competitors instead of teammates. In the world of developers, knowledge is the currency of the land where respect is gained through their level of knowledge, often triggering an ego response. Respecting knowledge in and of itself is not a bad thing, but when a candidate’s superior knowledge is perceived as a threat, then it poses a conflict of interest tempting the interviewer to go back and ruin that person’s chances by coming up with some explanation to give the candidate a thumbs down.

The business stakeholder will never know what truly happened in that interview and the candidate will never know how he was represented after the interview. The situation inherently hands a significant amount of power to people who may not have the best interests of the organization at heart.

Another example of bias has to do with race and ethnicity. On one occasion I recommended a candidate who I had worked with extensively in the past to an employer and was confident that he was competent enough for the role. After the interview I got his feedback where he explained that the interviewer was negative, had a bad attitude, was irate with him, and generally had an aggressive tone of voice. I was shocked but we could do nothing about it because there was nobody there to witness it. Unsurprisingly, he did not get the job.

While thinking about it we came to suspect that it had to do with race and ethnicity. Both the interviewer and the candidate are immigrants to the United States but were from countries who are historically adversarial politically, ethnically, religiously, and culturally. My colleague expressed that he’s experienced these dynamics multiple times in the past, but ultimately, we’ll never know for sure.

Admittedly, our suspicion that it had something to do with their backgrounds is purely speculation, but the uncertainty illustrates the problem. I know the candidate personally and failing that interview on technical merits did not pass the smell test for me. So, we’re left to our own devices as to the reasoning behind the rejection and I don’t know if any reason would be legitimate if privy to all the facts.

The basic point here is that the influence of unhealthy biases is one reason why a developer candidate should not be alone in a room with other developers in an interview. A higher-up or a business stakeholder should be present to observe and listen to keep the interviewer(s) honest.

Agendas

Another reason you should never allow a candidate to be interviewed alone by other developers is because of agendas that current developers bring to the table. I have suffered this many times as a candidate and I’ve come to recognize the signs all too well.

One of the telltale signs that the interviewer has an agenda is when they start negging the role. Meaning, they tell you all these negative things about the role to discourage you from accepting it should an offer be presented.

For example, I had one interviewer tell me, “You know the office is over a mile away from the train station and you’ll have to walk or take an extra bus to get here every day. Do you really want to do that in the winter?”

Another time an interviewer said, “You know we have vigorous architectural reviews. One guy got his butt handed to him and I think he wanted to cry.”

Another indicator is when they try to hide things or avoid giving you answers to questions that they deem risky. In one interview I had with a FAANG company, the first red flag was that he didn’t want to show himself on the camera in a remote interview. My gut immediately made me feel uncomfortable and my fears were soon realized.

In addition to some of the other red flags mentioned in this article, when asked if I had any questions, I posed a standard question that I always have when I interview as a candidate. I like to ask what the organizational structure is from the role I’m applying for up the chain in terms of title and responsibility. I ask this partly because I want to know who’s calling the shots.

For example, if I find that the software development department reports up to a VP of Marketing, I will most likely not work for that company. I also ask so to discover if the company separates the roles of Development Manager and Software Architect with follow up questions on who makes architectural decisions because people who don’t understand software development often impose constraints that set us up for failure and that concerns me. I also want to know, is there a Team Lead or are all developers in a flat equal position? Etc.

When I asked the interviewer this question, he flat out refused to tell me who the manager was and asked me why I needed to know that. I actually did not ask who the manager was or any person in the hierarchy for that matter. I asked what the roles of the hierarchy were, but he acted defensively as though I was trying to find out who is boss was. Needless to say, I did not get that job.

Another sign is when they show annoyance or some sort of displeasure when you nail a hard question. They hope that the hard question is going to throw you for a loop causing you to crash and burn but when you confidently answer with nuance, examples, and experience, they show disappointment. They should be happy they got a good candidate but that’s not the case.

So, what is it that is going on here?

The answer is that they have an agenda.

It could be that a political rival of the interviewer is trying to hire you, but they were selected to vet you that day and find themselves in a position to stop it. It could be that they want someone they know to get the job. It could be that they are looking to get someone who is of their race, ethnicity, or nationality into the role because they’re “getting each other’s back” as they say. Who knows? We can only speculate. But whenever I saw these signs as a candidate, I immediately kissed that job goodbye. I never got past that sort of interview, much less get hired, after I saw any of those behaviors.

I bet that if a business stakeholder is present during the interview, it would be conducted in a very different way. If you care about merit and hiring the best candidates, you need to consider the possibility that developers could be sabotaging those efforts for reasons that support their agenda.

Manipulative Candidates

Developers may be good at what they do, and they may be good at talking about what they do, but they are not necessarily good at dealing with people. One of the weaknesses that I’ve seen with developers is that some of them are prone to being manipulated by candidates.

One manipulative tactic I’ve seen candidates employ is to ask questions to try to get the interviewer to reveal hints about a question they asked. When candidates try to extract information from me with this type of question I always say, “Perhaps I know, perhaps I don’t know. You should be telling me those answers” and I make sure I keep it on them. I’ve witnessed other developers fall prey to that tactic exposing information that the candidate should know.

Another manipulation happens when the candidate asks the interviewer flattering questions to try to get the interviewer to talk about himself, appeal to the interviewer’s emotions, and burn time while making him feel good. Because some people just love to talk about themselves, they curry favor through flattery instead of through the demonstration of their competence.

I saw this happen once with another developer when the candidate said after answering a question, “That was a good question. It seems like you’re really good at that sort of thing. I’d love to know … how would you handle that scenario?” My colleague began to smile and pontificate on how he would handle this with his ideas, his vision, and I thought to myself, “Oh my God he fell for it.” Me being the pair developer in the room stepped in when I had an opportunity and said, “Well I have questions for you and we don’t have a lot of time so I prefer to focus on understanding your value.” The candidate’s demeanor quickly changed after my assertive posture showing that he was clearly disappointed that I didn’t let him get away with that. We both gave him a thumbs up, but he was the one to decline the offer. Hmm, I wonder why? I think we dodged a bullet there.

Business stakeholders tend to understand “people dynamics” better than developers and would be in a position to mentor developers on how to interview better with an awareness of these manipulative tactics. If you’re not in the room, you could end up with a really bad hire because you’re not witnessing developers getting played by manipulative candidates.

Useless Questions

A common theme I hope you catch on to is that developers may be good at what they do but they may not be good at dealing with people. Another manifestation of this is when interviewers ask questions about topics that they feel are important but are not important for the role. It is a personal curiosity that adds no value to the situation.

I saw this happen when I had a developer who reported to me and participated in our candidate interviews. This developer was a math genius. Every time we interviewed someone, he would ask questions about math to assess the candidate’s mathematical prowess. After the second time he did that, I asked him why he asked those questions. The role required literally no advanced or even intermediate mathematical skills. Whatever formulas we had to implement in the code were provided by the financial analysts.

I asked him when’s the last time he utilized his superior math skills to invent a formula for the business and he admitted that he had never done so. He had plenty of opinions about what the analysts produced but he never had to produce any of it himself. After that, he understood that this sort of questioning was useless in vetting the candidate and that it was better to spend time asking about things that actually matter for the role.

Had I not been there, he would have had negative feedback and possibly given a thumbs down for a candidate that didn’t share his outlook and abilities on math even though it wasn’t necessary for the role.

As a business stakeholder, if you’re present, you should look out for such questions that don’t seem like they matter for the role and ask why the interviewer was fishing for that. There might be a good reason but there might not.

Be Present for Other Things

The remaining parts of this series detail guidelines for hiring software developers. For all of them, it also requires presence if you want to ensure that the interview is conducted in the best way. You should carry this principle forward and use those guidelines to evaluate both interviewer and candidate.

I did not reach this guideline lightly. It came after many years of experience on both sides of the interview table. Many times, I walked away as a candidate feeling it was a total injustice but also knowing that there’s nothing I could do. I would just come off as sour grapes complaining about a rejection. I also felt that working with those people is probably going to be miserable and found comfort in the idea that I was spared the agony.

As a team lead, architect, or manager I have found these experiences to be invaluable and hope that by sharing them it will help you and your organization as well.

Check out Part 2 of this series where I explain why you should avoid coding exercises in the vetting process. Spoiler Alert … they seem like a good idea, but they are not.