We’ve all been interviewed before, and we can all acknowledge that the process is immensely stressful. However, while many guides exist to help interviewees through the process, very little attention is paid to the recruiter conducting the interview, arguably the most important component of a successful meeting. After all, the recruiter is the one required to ask the right questions and appropriately expand on any answers they receive.
So, whether it’s your first time conducting an interview as a recruiter or it is your hundredth. This advice will help steer you in the right direction to ensure things go smoothly for everyone involved.
- You don’t need to be “better” than who you’re interviewing. Many interviewers suffer from the imposter syndrome, meaning they fret over whether they have the right to interview the person. They may also wonder if the candidate knows more than them or if the candidate will see them as a fraud. Interviews aren’t about superiority, it’s merely a conversation about past experience.
- Understand the job level: When preparing to conduct an interview, you should always review the organization’s documents that explain the hiring bar and go over the necessary skills and values needed for the position. When it comes to engineering jobs, there should be a ladder that outlines the characteristics that are important for each level.
- Review the technologies: Software Engineers want to know what kind of tech they’ll be working with, so preparing in this regard is one of the best things you can do. You should be able to explain what technologies the candidate needs experience with and also do so in an appealing manner.
Every organization differs when it comes to the interview process, but most will start with a 45 minute phone call with the recruiter. This is when you can determine if there is a fit for the candidate and sell the company on them. This is followed by a phone call with the hiring manager and then a series of interviews with the candidate.
Each interview will assess a different area, like their coding abilities. After the interviews, you should host a team decried where you can share notes to improve the interview process and the company can decide whether to make an offer.
- You only have a short amount of time with the candidate, so you should be focused on the following to make the most of that time.
- Gather data points that help you reach a “hire” or “do not hire” decision. Every interview should conclude giving you a clear idea of whether you may consider hiring that person, and why or why not. Follow-up questions will help you get to the bottom of things to know for sure.
- Sell the organization. The candidate should get a clear idea of what the organization does and why they will want to be a part of it.
- Always make candidates feel good. Interviews are stressful, so never try intimidation tactics as they’ll only make it harder for the candidate’s true self to come through. Focus on being nice, welcoming, and informative. Candidates should leave feeling like they had a fair and professional experience.
If you want your interviews to go well every time, follow these best practices.
- If a candidate goes off on a tangent or begins to ramble, cut them off. It’s okay to take back the conversation and redirect them.
- Let the candidate do most of the talking, just make sure to keep the conversation on topic.
- Don’t waste time with questions that any candidate could easily answer in an acceptable manner, they get you nowhere unless you’re intentionally using them to try and calm a candidate’s nerves.
- Transcribe as much of the interview as possible and then review the conversation afterward. This will help you reconsider what was most useful to you.
At the end of the interview, you should review all of your notes and use them to help form your individual decision to consider hiring them or definitely not hiring them. Rate them on a scale. From strong hire to hire or no hire to strong no hire. Don’t be on the fence. Consider the facts and look at all of their technical, problem solving, and communication skills together to come up with the right vote.
- How many years have you worked as a Software Engineer or Developer? (Industry-specific vs. University)
- What programming languages have you been using the majority of your career?
- Tell me about your current role. Working on, scope, tech stack, etc.?
- What % of your time is spent coding?
- Are you involved in architecture and/or design decisions?
Bonus: I wrote another post about Phone Screening applicants here.
Logical: Any software engineer should be able to read your code and understand what you are trying to accomplish.
Maintainable: If another software engineer wanted to build upon your existing written work, they should be able to easily. Is it overall clean? Is it overall efficient?
Are you able to break down and solve a tech problem? Are you able to solve something with minimal hints? If you don’t know how to solve it, do you know which questions to ask? Can you communicate your thoughts on how to approach something and why you chose to do something? What are some trade-offs you considered?
Complex problems are stemmed from important fundamentals. Be knowledgeable about topics like binary search trees, hash maps, linked lists, queue, blanks, stack etc.
When given a high level, ambiguous question, can you break it down and design something? Do you ask questions to gather requirements? Can you diagram system components and talk extensively about them? How do you make sure it’s scalable?