In January 2022, I wrote an article about “How to have a better interview.” It was targeted at job candidates and written after I went through a long stream of interviews. I tried to capture advice I was given by recruiters, job search experts, friends, and interviewers themselves. Now, I want to approach it from the other side of the table: the interviewer.
Ask yourself if you are the best person to conduct this interview
I know this is hard because we all fancy ourselves as experts in all things, but it’s an important question to ask. Just because you can doesn’t mean you should. Interviewing is a hard skill to master, and if you half-ass it, it WILL show and the candidates WILL notice.
Do you have the skills to sit on the other side of the table from someone and evaluate their skills with as little bias as possible? Do you know the questions you can and can’t ask? Do you have time to adequately prepare for the interview? Are you able to actively listen while someone is talking? Do you have the patience to listen to an unqualified candidate try to bullshit their way through all your questions? Do you have the patience to listen to a cocky, arrogant candidate who believes he is the best developer to ever grace your presence?
Some people are good at interviewing and some people are OK. Unfortunately, and for various reasons, many people should never be in front of a candidate. If that’s you, and you recognize it, awesome! I’m happy about your self-awareness!
Learn how to interview
Almost all people who conduct technical interviews, including myself, have never had any formal training. Some may have gotten guidance from Human Resources, but most just ask the same questions they were asked when interviewed at the same company. Some may Google for interview questions, and some just wing it every time.
There are a lot of resources out there on how to conduct an interview, but first, I’d check internally, probably with whatever your company calls Human Resources. I’m not saying they’ll have a special class for you to take, although some companies do, at the very least they should provide you with a list of questions NOT to ask, and maybe some advice, especially if you’re new to interviewing. The last thing anyone wants is for you to ask an illegal question and get the company in all sorts of trouble.
Illegal questions? Huh? My friend Jenna gave me a great link, and while it is more from the candidate’s perspective, it’s still helpful.
What if HR isn’t any help? You can always talk to recruiters for advice. Of course, there is the vast resource that is the Internet. There are a lot of great resources for how to interview on YouTube, as well as thousands of books on Amazon.
Candidates prepare for interviews in a variety of ways, up to, and including practice. Many colleges, universities, and boot camps have their graduates go through mock interviewing sessions. I don’t think any of us would ever say that’s a bad thing, yet we jump at the chance to interview candidates with zero practice.
Interviewers should be no different. The first time you ask a particular question shouldn’t be in an interview with a candidate. Take some time to practice your delivery. Practice responding to candidates that dodge your questions. Practice asking the same question in multiple ways because some candidates may not understand it the first time you ask. Practice how you’ll answer questions the candidate may ask you!
I’m not saying you have to practice 8 hours a day for weeks on end, but do it once or twice and I guarantee you’ll be a better interviewer.
Spend time preparing
This is different than practicing.
I have been called in to help at interviews at the last second with, “Here’s the resume. Go!” It’s not fun, but I’ve made the best of it. Preferably, I’d like to get the resume an hour or two in advance so I can look it over, formulate specific questions I want to ask, and hit any links they’ve included (GitHub, LinkedIn) so I can have a better overall picture of the candidate.
If you’re interviewing with a partner or a panel, take some time to sync on the questions you’ll ask. Some people look at different things and have completely different styles, so for the candidate to have the best experience, try to come up with signals so others know when they can chime in, or when to end the interview.
Oh, does it look like their name may be hard to pronounce? Before the interview, check with the recruiter to see if they can tell you, BUT the best option is to make a note to ask as soon as you introduce yourself.
Be consistent between candidates
If you’re interviewing multiple candidates for the same position, make sure you ask each candidate the same questions. Why? If you don’t, you’ll be comparing apples to oranges.
It’s hard to decide that Candidate A was better if you asked her a completely different set of questions than Candidate B. You don’t need to be a drone and repeat questions word-for-word, but the gist of the question should be the same, and each candidate should be given the same information in your questions.
Good questions, bad questions, and trivia
While I’m on the subject of questions, this is a big one! Let’s start with the thing I dislike most and that’s trivia questions!
What do I mean by trivia questions?
- Can you tell me what SOLID stands for?
- Can you tell what the S in SOLID stands for?
- Can you tell me what TDD stands for?
- Can you tell me what a variable is?
As part of the preparation, please come with a solid list of questions, and I don’t mean just questions about SOLID. I know, everyone has their list of questions about SOLID they love asking, whether it’s about Liskov or Dependency Inversion, but please, come up with something more original, especially if you’re interviewing someone with a lot of experience.
Sure, I understand asking a candidate a certain number of basic questions, but frame them differently! Do something to make them more interesting and engaging, not just for the candidate, but for you as well! I would much prefer to hear an interviewer ask, “Have you ever done TDD?” or “Can you tell me about your experience with Test Driven Development?” That’s much better than asking them to regurgitate what the letters of an acronym mean.
Also, unless the candidate is interviewing for an extremely unique position, don’t ask obscure questions like, “What is the third parameter of the BeginRead method of the NamedPipeClientStream class in .NET 4.8?” Wait, now that I think about it, don’t ever ask those kinds of questions.
In the end, I don’t care what you ask, just be prepared AND be able to answer the questions you’re asking! I’ve been in interviews where a partner interviewer joked going into the interview that they could never really answer, “What is the Liskov Substitution Principle.” If you can’t answer it, why in the hell are you using it to judge the candidate’s ability to work with you?
Oh, and if a candidate has no idea what the answer to a question is, I like to give them a short answer so they at least learned something.
I prefer a much more conversational approach when I interview candidates. I like to ask about projects the candidate has worked on, what challenges they faced, what excites them about technology, and how they like to learn. You can pull a lot out in a short amount of time with questions like that because every question you ask should have a purpose. I know what I’m listening for when I ask those questions. If I hear keywords or phrases, that helps feed my next line of questioning.
Please make sure the questions you ask aren’t outdated! If you’ve been asking the same questions for the last ten years, ensure you still know what you’re talking about! A good example is the old, “In C#, can you tell me the difference between an interface and an abstract class?” Not sure what I’m talking about? You should probably look it up.
And if I haven’t made it clear, different roles, people, and experience levels require additional questions and approaches. There is no one-size-fits-all when it comes to questions. I only ask for consistency between interviews for the same role, not asking trivia questions and ensuring that you can answer your questions!
Whiteboards and live coding
Since many interviews are on Teams or Zoom, it’s much more difficult to let someone work a problem out on a whiteboard, but if you’re still interviewing in a room with a whiteboard, please consider your goals.
While I don’t mind standing in front of a whiteboard and working out a problem, many people struggle. They struggle with being put on the spot. They struggle with being in front of a group of people they don’t know, trying to use a whiteboard marker that’s long past its prime, wearing clothes they probably only wear on interviews, trying to decide how many balls they need to weigh on the scale since they can only use the scale twice to find the lightest ball, AND are most likely regretting even accepting the interview with your company while you continue to throw more scenarios at them.
As for live coding, it takes a LOT of preparation and a skilled facilitator/pairing partner to make it work. Unless the candidate is doing the coding on their laptop with their preferred tools configured to their liking, they will NOT be productive, so don’t expect miracles.
On a related note, I’m not a fan of homework from interviews, but that’s another article.
Let the candidate talk
As a candidate, I have been in many interviews where the interviewer spent far more time talking than I did. Sure, you need to introduce yourself, but make it quick! Sure, you need to talk about the company, and the team, but make it quick! Sure, you need to set questions up, but for the love of all that’s good in this world, make it quick!
This also is NOT a competition between you and the candidate! If the candidate talks about something cool they did, it’s fine to say, “Wow! That’s interesting!” but you don’t need to talk for another 10 minutes about how you did something MORE interesting.
If you find yourself trying to prove to the candidate that you’re smarter than they are, please revisit the first section of this article and ask yourself if you’re the best person to be interviewing.
Know when the interview is over
Besides the obvious sign that you’ve used up the allotted block of time, there are other signs when an interview is over. It might be that the candidate has done a terrible job of answering your questions or answered them so well you don’t need the full hour (or whatever) to know if they are what you’re looking for.
When I know an interview is at that point, I ask the question all candidates hate: do you have any questions for me?
I like to work this particular signal out with other interviewers, but there’s a good chance we’re all thinking the same thing, so asking the candidate if they have any questions is the sign that we’re wrapping things up.
Of course, MOST candidates won’t have any questions, or at best, they’ll have a simple question like, “can you tell me what I’ll be working on?” How you answer that is up to you, but if you dropped that question 20 minutes into a 30-minute interview, there’s a good chance you don’t want them working on any project!
How will candidates learn if we never provide feedback? Sure, some of that feedback can come during the interview, but if you turn a candidate down and they have no idea why, how will they ever improve?
I’ve been lucky to get some great feedback from a couple of interviews over the past few years. It’s not the norm for sure, but it should be.
I know I said ten ways, and this is 11, but I received some feedback I wanted to incorporate!
You should always end an interview by letting the candidate know the next steps! Most times, it’s as easy as telling them the recruiter will get back to them in a day or two.
You shouldn’t consider interviewing a chore because it’ll show in how you do it.
You should want every candidate to succeed. You should want them to feel comfortable and relaxed.
Learn how to interview. Prepare. Focus on the candidate. Ask good questions. Let the candidate talk. Give feedback.