When I first started interviewing candidates for engineering roles, I was very nervous. The process can be quite daunting as both an interviewer and interviewee. The goal for the interviewer is to assess the candidate for their technical capabilities and make a judgement on whether you think they should move to the next round (there’s always a next round). Making a judgement on someone after an hour, sometimes a bit longer, is hard and error prone.
There are a lot of ways to assess someone for an interview for an engineering role. Depending on the role itself there may be certain requirements such as a senior role needing more focus on system design and manager roles more focussed on the team dynamics rather than their ability to write code.
In all types of interviews there is a lot you can learn from doing interviews, whether you’re a candidate or interviewer but for this article I’m going to talk about some of the things I’ve learned while doing many technical interviews over the past few years.
Disclaimer: I am not pretending to be an expert on interviewing nor have the perfect process, but these practices are what I wish I knew before I started interviewing more regularly.
Having a clear, repeatable structure helps you and other interviewers ask the right questions
When I started interviewing there was some process about what questions to ask, how the interview was structured and how it changed depending on seniority, but it was often not relevant and I always found it odd to roll off 20-questions one after the other, especially when the questions probably weren’t relevant for the candidate.
I also found stating the structure of the interview at the start allows the candidate to understand what’s coming and what time we should finish so we know to progress if one section is taking too long.
While you do want to have some canned questions you ask in case you can’t think of any, I try to think more in terms of the topics or capabilities I want to assess rather than direct questions.
For example, rather than asking a specific question about React or VueJS, I would ask what technologies have you used to solve writing reusable components on the frontend? This broader question allows the candidate to answer in a way that’s relevant to them.
If we want to asses whether they have experience with observability, we can ask about how they would know if something fails or is working correctly in production?
Setting these expectations up front helps you (the interviewer), any other interviewers and the candidate ask any questions before progressing and know what to expect during the interview.
You don’t need to know everything to interview someone
I used to dread interviewing someone who clearly had more experience than I did. They would probably say something I didn’t understand or ask a clarifying question I couldn’t answer thus prompting the question - why am I the interviewer?
While it doesn’t happen as much anymore, it’s not because I learned everything, it’s because I stopped trying to know the answer to every question. It’s ok to say you haven’t used that technology before or are unsure how something works, even as an interviewer.
Instead, ask a follow-up question if the candidate knows about it and you will learn something new.
Better yet, this will demonstrate the candidate’s ability to teach something to a co-worker, which is a very valuable skill to have as an engineer.
Your experiences are more likely to be different to every engineer you interview, so it’s better to acknowledge this rather than try to combat it or be worried about being stumped on a question.
Win-win.
When to help the interviewee along by giving hints
Sometimes you’ll interview someone who has just started their career and hasn’t had much experience yet. They might need some extra pointers to get to where you’re trying to get them to go. This isn’t a sign of weakness in an interview, but an opportunity for you to show how they can learn more from the company they’re interviewing for.
They may also just have different ideas to you and the other interviewers, which is also perfectly fine, albeit encouraged.
System Design is often not as simple as choosing a tool that can do the job and being done with it. More often there are a set of trade-offs that have to be considered, so offering the candidate a chance to understand the intent behind the question could be one way of aligning on what you’re getting at without specifically telling them what you’re looking for.
Some people will just need more time to think through their answers, as these whiteboard interviews can often be a source of anxiety for many engineers who don’t do it on a regular basis. Remember the desired outcome is not to trip up the candidate into saying the wrong thing, but rather providing them a chance to show you what they know and how they arrived at that conclusion.
Asking the right questions helps form the basis for your judgement about hiring/not hiring
It’s hard to know what questions to ask if everyone’s experiences are different, they haven’t used the same technologies as you, so we can instead ask questions that start a discussion about a broader topic, so the candidate can tell you what they know about that topic rather than trying to ask pointed questions.
Typically, I won’t have a prepared list of questions to ask in the interview, but will instead know what topics to discussed based on previous experience or knowing what we’re trying to assess from the candidate. It’s less about specific technologies and more about their problem solving ability, critical thinking and ability to make trade-offs and explain them clearly.
Sometimes engineers will have to make decisions that aren’t ideal, but are based on a set of tradeoffs (maybe they don’t agree with those either), but are part of business goals or customer requests. Understanding that this is where the tradeoffs come from and have a variety of reasons for being considered is more valuable to me than any specific technology we could learn more about.
Asking a question you don’t know the answer to but think the candidate will is a good way to build trust with the candidate that you’re not trying to trip them up on a question and are genuinely wanting to learn from them - remember they are interviewing you and your company too!
Practice is the only way to get better
Fortunately (or not) the only way to get better at interviewing is to do more of it. Avoiding awkward silences, especially when an audio delay happens over a video call, comes with practice and doesn’t come naturally to everyone, myself included!
Eventually, I got better at either stalling by talking about something else until I could think of the next think to ask about or knowing what question I want to ask next in advance.
Being curious about the candidate’s experience helps broaden your own perspectives and helps them relax by talking about things they understand well.
You want the candidate to do well, you’re not trying to trip them up on a trick question
Above almost everything else, you should want the candidate to do well. It’s your responsibility as the interviewer to set them up for success, focusing on their strengths and letting them show you what they know rather than asking a specific set list of questions about topics they might not be familiar with.
This will result in a better interview experience for everyone involved, and even if they don’t progress to the next round or eventually get the job, they could still come back again or leave with a good interview experience to learn from.
Evaluating a candidate for an engineering role is a bit different to other roles and has its own intricacies due to the technical nature of what you’re trying to asses, but more often than not I have found technical skills can be learned but attitude and how you treat other people is much harder to change. So, even though we’re assessing technical ability, it’s not an excuse to ignore basic decency of giving respect to everyone on the call. Thankfully, there have not been too many occasions where this is has impacted an interview.
Interviewing is a tricky subject and most of my interviews recently have been done over hangouts, which has its own challenges. Having a good experience in an interview should be a given, even if it doesn’t work out in the end.
It’s just as much an interview of the company you’re representing as it is of the candidate. It’s the first chance someone has to experience your company and leaving a bad impression will generally last forever. I’ve learned a lot over the interviews I’ve done so far, and hopefully I’ll learn more in the interviews to come!
Oldest comments (0)