How to Conduct a Technical Interview¶

This article is a distillation of what I’ve learned from being interviewed and conducting technical interviews numerous times.

Interview process¶

Broadly speaking, there are 3 parts to conducting a technical interview.

Forming the interview team and setting the intent
- Identify a team of 6 engineers who will conduct the interviews. This will ensure the interviews are consistent across all candidates and they are measured against the same bar.
- For each open requisition decide if you are looking for someone with a specific skill (Say, PCIe or DDR experience), or will any candidate who shows the necessary aptitude suffice?
- Decide which technical areas each interviewer is going to focus on. This will ensure there’s no overlap in questions and the team, as a whole, can cast a wider net and comprehensively evaluate the candidates.
The interview

Candidates with < 10 years of experience: 2 rounds
- Screening - One 1-hour interview
- Main round - 3 to 5 interviews, each interview being 45-60 minutes.
Candidates with 10+ years of experience: 3 rounds
- Screening - One 1-hour interview
- Second Round - 3 x 1-hour interviews
- Presentation Round - Presentation + 2 x 1-hour interviews
  
  Senior engineers play an important role in dictating the team culture, code quality, and carrying the project to the finish line. They need to demonstrate clear thinking, the ability to work independently, make decisions and mentor junior engineers.
  
  So, in this last round the candidate presents one piece of their work in detail to the panel of interviewers, with a Q&A at the end. Two 1-hour technical interviews follow the presentation.
  
  Expecting a presentation might seem like an overkill but, considering the importance of this role and the financial investment for the company, I think this is a reasonable approach.
Round table
- Set an expectation of what the interviewer's feedback should include. Detailed feedback is important for the hiring manager to make the final call. This also prevents one-liner feedback, such as, “Good candidate. Hire!”.
- Have a round table to discuss if the team should proceed with a hire and if there are any concerns.

Goal of the interview¶

My evaluation of the candidate is based on the following 3 pillars. I portion the interview time to adequately learn about each of these attributes.

Aptitude - Is the candidate technically proficient to carry out the tasks we have earmarked for them?
Capacity - Does the candidate show the ability to grow in the role and mentor future employees. Do they have the ability to independently conduct investigations and come to conclusions. Do they have the ability to explain their thoughts clearly and be responsive to feedback (positive and negative) from their peers?
Willingness - How much does the candidate care about the quality of their work? Does the candidate have a high standard for themselves and are they driven and self-motivated to do their work?

Phases of the Interview¶

I find 60 minutes to be the right length of time for an interview, 45 minutes is insufficient. The way I structure my hour long interview is as follows —

0 - Introductions `2-5 mins`¶

Introduce myself and tell them about my background. If I’m the first interviewer, I tell them why we’re hiring for this position, what we are trying to achieve with the project, and what stage it is currently in.
Part of the intent is to sell them the team and the project with the hope that they walk away with a positive impression of the company and consider us over their other choices.

1 - Past Work `15-20 mins`¶

For candidates with experience, I dig deep into their last 3 years of work. I explicitly ask the candidate to give me a good picture of what exactly their contributions were and not just describe their project. This isn’t a monologue, I ask a lot of questions stopping the candidate whenever necessary.
For new college graduates, I try to understand why they plan to pursue this profession. What put them on this path and what their motivations are. I dig into their work during any internships or class projects.
Throughout, I’m observing how the candidate is explaining their work, is their explanation shaky or confident? Are they curious enough to dig beyond their immediate assigned tasks in order to get a bigger picture? On a general level, how much does the candidate know about the subject they are working on?
When they say this is how they solved a problem, I ask them to write specific snippets of code showing its implementation. So we’ve already filled up half the white board with code through this phase of the interview.
I also get a good idea of how receptive the candidate is to my questions? What is their attitude like? How is their communication, am I able to understand them properly?
I ask them the biggest technical challenge they faced and how they solved it.

Bottom Line

I ask them pointed questions about every line mentioned in their resume (related to past 3 years of work). It also helps me evaluate if they have inflated their resume and experience, or if they truly performed that work.

2 - Pure Code `15-20 mins`¶

In this phase I am gauging their proficiency with the primary programming languages for the job. I present them with a piece of code and ask them to make it more efficient, I ask them the internals of the language, etc.
The complexity of the questions depends on their level of experience.
I’m not trying to defeat the candidate or prove that I’m smarter. The goal is to see if they meet the minimum bar of coding proficiency needed for the work we’ve planned for them.

3 - Problem Solving `15-25 mins`¶

I present them with a scenario and ask them to solve it. The expectation is for them to flesh out the microarchitecture and implement it in code.
While this phase also requires the candidate to write a lot of code, it is different from Phase 2, it is similar to getting a specification at work, thinking through it and solving the problem.
I observe how they approach the problem. I’m expecting the candidates to ask good, clear questions to learn more about the design.
Usually if the candidate is well prepared for the interview, they will do very well in Part 2 (coding portion) of the interview. But usually, I’m able to relatively grade candidates very clearly with this phase (i.e., how is this candidate compared to the other interviewees?)
Depending on the years of experience, the complexity of this phase changes and the amount of time I spent here also changes.

4 - Conclusion `3-5 mins`¶

I reserve some time at the end for any questions the candidate might have.
They should walk away with a pleasant experience and a good feeling, no matter how they think they did in the interview. They shouldn’t feel attacked or put down.

Providing Feedback¶

This part of the interviewing process is often overlooked. At the end of the interview you are asked to provide written feedback about the candidate. Be thorough and provide as much detail as possible.

Two-sentence feedback is insufficient for the hiring manager to make an informed decision. I usually document how this candidate performed in each of the phases, usually giving them a rating out of 10 for each phase. I even elaborate on the questions I asked and what their answer was.

Conducting the interview¶

Empathy and Respect¶

Always start from a place of respect and empathy, and treat others how you like to be treated. I remind myself that I was an interviewee once too.

Do not approach the interview with the intent to defeat the candidate. This style may be relevant while interviewing Managers and Directors, but is unnecessary for individual contributor roles. Conducting the interview with this mindset only causes anxiety and stress to the interviewee and doesn’t bring out the best in them. It does not allow you to evaluate the person for their accomplishments and the technical expertise they can bring to the table.

Are you prepared?¶

It is important to me, as an interviewer, to be adequately prepared for the interview. Prior to the interview, I spend about 20-30 minutes perusing the resume, highlighting and making notes, and deciding what I want to know about the candidate.

Discuss with your colleagues and develop a strategy for who is covering which topic, so all of you aren’t asking the same questions. This will help your team, as a whole, to cast a wider net and evaluate the candidate on multiple fronts.

I’ve experienced situations where the interviewer looked at my resume for the first time during the interview. They weren't adequately prepared, leaving the hour wasted or asking questions that weren't relevant to my experience. This left me with a bad taste and put the company and the interviewer in a negative light.

Conclusion¶

With the above structure, I’m able to determine —

How this person will be to work with.
Get a good picture of their communications skills and their ability to ask questions.
Does this person have the Capacity, Willingness and Aptitude to perform the tasks we have planned for them.
How much hand holding and mentorship will this person require? Do we have the bandwidth to provide this level of mentorship?

Total Time Per Candidate

From start to finish, it takes me about 1 hour and 30 minutes to prepare, conduct and provide feedback for one interview. I think this is reasonable considering you might be working with this person for several years.

HR teams in companies are always proactively trying to improve their processes. If you feel something is insufficient in your company’s interviewing policy, a casual conversation with the hiring team might be beneficial to everyone.¹

Thanks to Vikram, Priya and Nidhi for their feedback. Thanks to Leon for inspiring me with the idea for Aptitute, Capacity and Willingness. ↩