Photo by Bram Naus (https://unsplash.com/@bramnaus) on Unsplash.
Photo by Bram Naus (https://unsplash.com/@bramnaus) on Unsplash.

This year my focus is on collecting my thoughts on being a manager. A large part of that is hiring your team, so we’re in a series on the hiring process. Posts so far include creating job postings, reviewing the resumes you receive, and the first part of getting ready for interviews. In this post, I share more thoughts about getting ready for the interview.

This sequel is another list oriented article, so I will just repeat the introduction from Part 1:

The purpose of an interview is to determine if the candidate is a good fit for the job. Many of the traps we fall into during the interview process come from forgetting that.

Remember, interviews go two ways. You are selling the candidate on the organization just as much as they are selling themselves to you.

Know the decision making process

Before you get into the interview, know how you will get your feedback to the rest of the team or collect the feedback from the rest of the team. Generally, I ask our in-house Talent Acquisition (aka internal recruiter) to manage this part of the process along with the scheduling. The reason is simple: if I am communicating with the other interviewers who come after me, I run the risk of communicating something that adds unintended bias into their own interview. I’m the lead of our group and if I share my opinions, even people who are quite used to working with me will tend to be swayed by my own view. Even when the relationship between interviewers is a peer relationship, bias will creep in, so don’t share notes. It’s perfectly ok to ask a subsequent interviewer to dig into topics you did not get too or when you realize afterwards a response may have been more nuanced than you originally thought.

The most important reason to know the decision making process beforehand is so that you will make a decision quickly. Do not lose a candidate to another organization because you waited two weeks and that organization got the offer to them first. Getting beat to the draw by other organizations is going to happen even when you turn around decisions next day, so do not dawdle.

Know who they’ve talked to already

It’s small, but it’s helpful. If you’re first, you know you need to do more to help the candidate to understand the role (there is always a nuance not quite captured in the role description). If you are not the first, the candidate seems more likely to have a question or two for you at the beginning of the interview.

Know your introduction

The first five minutes sets the tone for the interview. Here’s how I do it:

  1. (for video interviews) Dialing in - make sure your setup is good and make sure the candidate’s setup is ok. Be gracious if they need a minute to get setup, it happens. Require their camera to be on. I will be posting more on this in the future. Some more tips on video interviews can be found in October’s post.
  2. Say hi, briefly introduce yourself. E.g., “I’m Jim Leonardo and I’m the chief bottlewasher” and prompt them for their name. Given some of the fraud scenarios that seem to be popping up with more regularity, don’t blatantly ask “are you so-and-so?”, ask them for their name. There’s also the oh-so minor detail of making sure you’ve got the right person so you’ve got the right profile in front of you.
  3. Do a more extensive introduction of yourself. Have this little talk ready to go. I reiterate my name and role, give them a quick overview of the company from my perspective, describe what I do, give a once sentence synopsis of my history, and why we’re talking. My goals right now are to:
    1. Put the candidate at ease.
    2. Make sure they know who they are talking to so they answer at the right level. I’m head of IT, a candidate for a software development related role may assume I don’t have a development background if I don’t tell them.
  4. Ask them if they have any upfront questions. This usually goes like this: “I know you talked to Tony Stark already, do you have any questions before we dive in? This is a conversation, so you can ask as we go too and I’ll leave time at the end as well.” About a third of candidates will have questions at this point. They’re usually pretty simple, usually clarifying a point about the role.
  5. Now ask them to give a brief synopsis of their professional background. I am a stickler for making sure I get it across to them that I am asking about their professional background and not their life history. “Would you please give me a brief overview of your professional background? Focus on the more recent and more relevant bits. Resumes usually don’t get quite the essence of what you’ve done across.”

From there, we get into the substantive questions …

Have your questions ready

The first part of having your questions ready is making sure you know what kind of interview you want to have. You aren’t going to get both an in-depth technical interview covering specifics of coding and a high-level software architecture interview and a deep dive into their leadership background done in 45 minutes while giving them any chance to get to understand your organization. If you do somehow need to do all three (and more), I suggest having others cover those parts.

Without getting into specifics for a given type of interview, here’s a few things I look for when creating questions:

Good questions are relevant to the job. They especially should not be brain teasers that often are more of a trivia question than a test of problem solving. “Given a fox, two chickens, and a canoe, how do you get all of them across a river without a fox eating one of the chickens” is a terrible question! “Why are manhole covers round” is also terrible. The answers are trivia - both are well known brain teasers and someone on may have read the solution without ever solving it for themselves. They also are unlikely to be relevant to the job.

The best questions require more than a three word answer. It will encourage an in-depth answer. “Why are cursors often considered an anti-pattern in database querying?” is a good question for someone who will be a database admin or database developer because it is asking for rationale, not just a yes or no answer. It’s also good because you are asking for something that (I hope) is general knowledge for the role. It’s also a good question because If the person disagrees that it is an anti-pattern, you’re not forcing them to defend that position, you are asking why it is a common view within the profession. Still be careful - this particular question is somewhat safe because there’s a solid rationale. Which brings us to …

If you ask an opinion question, understand the range of potential good answers and know that sometimes the best answer is the surprising one. Opinion questions can offer good insight into how someone thinks, but be very sure of your own opinions and understand why they matter. Interviews are not the place for the tabs vs spaces debate. Sorry, I’m not stepping into that particular morass right now. I’m certainly not going after the opening curly-brace question either.

Outside of the opinion questions, a good question will also be about something the candidate can be expected to know and that you know the answer to. Asking a candidate to solve a distributed network problem you don’t know how to solve is a bad move - you can’t evaluate the response. The other side of this if fact check yourself too! One of my most interesting conversations when I was the candidate was with someone who was starting to get smug that I couldn’t solve his performance optimization problem. After I explained in detail why I thought it couldn’t have an answer, I asked him what his solution was. His solution was flat out wrong. At least he had the grace to accept that once I went into detail why it was wrong. His solution wasn’t bad for solving the real business problem, but his question was phrased to require “constant time” in “Big O” analysis terms and his answer was most definitely not constant time. He had not checked his problem with someone else and so had bad question.

Unless you are interviewing an internal candidate who is switching teams, etc, keep your company knowledge out of the interview. Questioning someone on how to use your custom solution is only going to leave you disappointed. And yes, I do have to say that, because it is a thing.

In almost all cases, also keep the hard questions you’ve had to solve as a company out of the interview unless you’re looking for a specialist in that particular area to help make those problems not-so-hard in the future. That performance optimization problem? Yeah - it was a thorny problem that took a fair bit of time to solve. Expecting a candidate to solve it in the moment is just plain unrealistic. The distributed network problem I also mentioned? Also from the interview for a real job I applied for about 15 years ago. At least in the performance problem, he had an answer. No one at the company with the distributed network problem knew how to solve it. I did solve it once they hired me, it just wasn’t solvable in 20 minutes (remember that bit about “looking for a specialist” - I’m not quite that, but this did fall into a type of problem I worked on at that point in my career).

The biggest thing to not do for the vast majority of roles is asking questions where you expect the candidate to challenge or contradict you. This is firmly Rule 62 territory - if you’re not a psychologist, don’t act like one. In an interview, the candidate is threading a needle of putting their best foot forward while also presenting themselves as a good worker who will be easy to get along with, etc. Similarly, asking questions that have “obvious” flaws and expecting the candidate to spot the flaw without you telling them the question may be flawed is also a bit of psychology. You just cannot tell if the candidate is going to assume the problem is with them instead of with your question. They will freeze, they will blow the rest of the interview, and you will miss a potentially good candidate because they did not realize that you were playing dirty. It is not automatically wrong, but you better know what you are doing. Springing that trap on an entry level candidate is not testing their critical thinking, it is testing their skill at being interviewed.

Conclusion

Being prepared to conduct an interview takes effort. You are trying to figure out how a person will work for you day to day by creating a totally artificial environment and pretending that it will give a great result. Some people do well at interviews because they have plenty of practice at it but then cannot do a lick of work. Other people will bomb interviews more often than not, but will be awesome members of your team. Most will be somewhere in between. Like anything else, learn from both your successes and your mistakes and continually improve.

Next time: a few things specific to video interviews that I practice.

And oops … forgot to actually hit publish on this one in September. 🤦