Being an effective interviewer carries significant responsibility. It plays a crucial role in helping your team meet its objectives and can be a valuable addition to your brag document. Done well, interviews can be both enjoyable and educational for both you and the candidate, offering opportunities to connect with the human aspect of the industry. While there is an abundance of excellent resources - including entire books - on how to approach engineering interviews from the candidate's POV, there is much less out there for those on the interviewer side of the table.
I figured I might collect a nice intro guide for engineers first joining (or returning) as interviewers to engineering loops, to make help de-mystify and defuse tension around that responsibility. I've written versions of this post in the last few companies I was at, having interviewed a few hundred candidates, and I actually found myself digging for a few of my own notes on this topic as I rejoined the interviewing loop at my current company, Fanatics.
Pre-Requirements
A key thing you can do to prepare for engineering interviews are to familiarize yourself with your talent and hiring team, and the hiring process at the company you work for. If you currently work as an engineer, you've probably experienced it for yourself, but you may want to refresh yourself on specifics like:
- What steps make up the hiring loop, for candidate and for the interviewers involved? How does this vary per role and level?
For example, the engineering manager of a mobile team will likely have a different set of interviews than a junior backend engineer.
- What should you as an interviewer be looking for in each interview step?
What's the format of each interview, how long should it last, who does what? What does good look like - does your org have a rubric that helps you grade the interviewee and minimize human biases?
- What teams are hiring, for what needs? Is the job description (JD) accurate?
This will help you cater some of your recommendation to what the team actually needs. Is this a backfill, or is the team scaling up to do some heavy lifting? What do you expect their first 90 days and 6 months might be like?
Knowing the answers or having at least considered all these things set you up for success - these are things you'd need to know to conduct a successful interview, something an interviewee might ask you, or might help you recommend whose the better fit between two impressive candidates!
An Example Hiring Loop
The majority of my interviewing experience has been in orgs whose interviewing loops are heavily inspired by the Amazon; if you're in such an org or want to compare your process to it, I highly recommend the Working Backwards book, specifically the chapters around the Bar Raiser process.
For example, the hiring loop for a mid-level IC might be:
Initial Call
Usually hiring loops would start with an initial screening. This would be a light touch conversation between the recruiter and/or hiring manager (HM) and the candidate. Unless you're the HM or stepping in for them, you probably won't be involved at this stage. Hopefully this is where both parties get to level set on initial expectations for the role and figure out out if they might want to continue with the process!
First Screen
If things go well with the initial call, candidates go onto the first screen, which is usually some sort of technical screening. In some loops this might actually be a take home exercise, where candidates get some problem prompt, and have to submit some code and a write-up about how they did it, how to operate what they've written, etc. In others, you might be interviewing the candidate live on a call, delivering that prompt and working towards a solution. In any case, this is typically the first opportunity you get to analyze the interviewee's technical ability. Here's how I describe how I conduct and what I look for in a live coding interview:
What You Should Look For
For me, the exact problem and solution don't really matter all that much. In fact I usually tell candidates that they don't necessarily have to have a working solution at the end of our time, and they can potentially even "hallucinate" the APIs of things they don't remember. Yes, it's great if they have something that works in the end, that they know the standard library, and that it's well designed, but I find that enforcing high bars for those areas out can often be distort detection for more important attributes you want to get a bead on.
I use this (and the subsequent interview loops) as a chance to get a feel for their thought process and their experience. How do they start off with understanding a problem? Does the questions they're asking indicate they have a problem solving process - separate from being a skilled interviewer? Do they recognize the fundamental algorithms they'd need to implement to optimally solve the given problem, and potential algorithmic wrinkles? Can they speak to different solutions optimizing for different things, but also pragmatically choose an implementation path? If they run into issues, can they debug effectively - using print statements, or loggers, or isolate parts into tiny test harnesses, or model it in their head? How does their communication style change as they think through the complexities - silence while gears are churning is fine, but can they summarize effectively? Can they predict how their implementation might perform runtime and memory-wise if the inputs are scaled?
These are some of the things I try to get a signal on in this first showing, within the process of them putting code together to achieve some outcome.
Some tips:
- If it's remote, do quick A/V/wifi checks at the start, and explain what they might want to do in case of disconnections or bad A/V.
- Be clear and concise and do your best to make the candidate feel supported and comfortable. Be clear on the format of the interview, how long it will take, what the focus of it will be and when it will end.
- To that point ^, I generally try to be explicit about what I'm looking for, and what I'm not. For example like I mentioned above, I will tell the candidate it's perfectly ok to walk out of this without a working solution, but I do want them to speak to how they're thinking about solving the problem I give them, and how they're analyzing potential solutions and making tradeoffs.
- I'll also mention my own role expectations in this. I'll be a resource for them they can ask questions of, I'll help keep time (if they want it!), and I'll answer questions for them about the company and the role they're interviewing for.
- I expect higher levels to operate more autonomously. I'll still give explicit expectations re: above, but during the interview I may course-correct less.
- You should try to shadow interviews with folks that have done these before until you feel comfortable with conducting one yourself. You ease into it, eventually leading the interview yourself with someone as your backup, until you feel you can do it yourself.
- Something I learned from Stacy Devino: with tactical, in-depth tactical interviews, it can be tough to switch gears right at the end to have them ask you questions. Make it opt-in if they want to ask questions, and give them options to ask their questions at the end or the beginning of the interview.
Onsite
I still refer to the next batch of interviews as the Onsite, but in a post-covid world there's a good chance all of these will be remote. They might consist of a series of interviews like:
- System Design
- Project Management
- Cultural
over the course of a day or few days, depending on scheduling.
For the technical ability interviews, I generally use the same tack as the coding exercise above, focusing more on thought process and ability versus the exact outputs of the interview.
Debrief
After each interview, there should be a period of feedback collection from the hiring manager and recruiting team.
If others are evaluating the candidate in the same interview, especially in a shadowing capacity, I like to chat after the interview to talk about the format of the interview and answer any questions they might have there, and what next steps might be. I intentionally try not to discuss the candidate performance to prevent biasing our reviews before we get to the group debrief.
After each interview, I take the notes I took during the interview and summarize it to map back to the primary competency or area that interview is supposed to cover, giving a nuanced take on how the candidate performed when encountering problems, experience that they have that might be a boon, experience they're missing that might be a risk, and notes on how they might work in the team, and my general recommendation on whether I think we should hire them based on the interviews you ran.
A quick note: There's a good chance with shared interview pools you'll be in a situation where you're helping out hiring for a different team, in which case you might write off any behavioral concerns. It's important to be intentional about thinking about how the candidate might fit into the team they're interviewing for. An old manager of mine used to recommend asking yourself if you'd work with them on your team, but that can lead to bias and hiring who looks or thinks like you - focus on aligning to what skills and attributes a person might need to be successful in the target job.