How to be a good software tech interviewer
If you find yourself in a team that needs to largely increase in size (happened to me twice at Uber) whether at a big company or a rising startup, you will end up interviewing a lot. Being good at interviewing will be critical to the success of your company.
The way a final interview loop happens is that you will be part of a group of engineers that will be each interviewing a candidate separately for one hour. After this, you will meet your colleagues in a debrief meeting where you will decide collectively whether to extend an offer or not to the candidate.
The worse you can do for the candidate, yourself and your team is to have no opinion in the debrief meeting. You would have literally wasted everyone’s time and been unfair to the candidate.
What this means is that the second you enter in the interview room you are actively collecting positive signals that the candidate will be a great team member or negative signals that the candidate will not be a good fit for the team.
First, ask them about what they are currently working on. If they are in college, ask them about their final project, etc… This will allow you to gauge their experience, command and complexity of their current work. Ask them follow up questions, ask about their learnings, give them space to tell you about their experiences. Unfortunately, a lot of people do not ask about this and miss a great opportunity to learn a lot about the candidate.
Second, if you are doing a coding round, never ask an aha question, one of these that needs a trick or a workaround that once you get, you would be able to solve the question. This usually do not tell you much. You also want to minimize algorithmic question. They are hard to do in one hour and do not mimic how engineer think about algorithms in their day to day work. What you want is to get them coding as quickly as possible. You also want them coding on their IDE rather than a white board. Conducting an interview on a white board will be a missed chance to collect valuable signals on their debugging and troubleshooting skills.
Remember, any chance to collect signals increases the odds of a successful interview.
If you are doing an architecture interview, allow the candidate and give them space to show their experience and knowledge of different patterns. Ask a lot of follow up questions and try to gauge and connect their architecture to their work and production experience.
In the end, leave a little time for the candidate to ask you questions about the team and company. In addition, if they did really well in their interview, use also this time to sell your team.
Before we go to the debrief, two things to note. First always be respectful, only focused on the interviewee and never ever cut an interview short. Interviewees are under a lot of stress and being emphatic to them is of utter importance. They are also current or potential customers and will not forget a bad experience (rightfully so). Second, be open minded especially with candidates with a non typical background.
In the debrief, come back with one of the four options:
Strong Yes. You would fight for this candidate and hiring them is a competitive advantage for your team.
Yes. They are solid and will be great team members. We should definitely extend an offer to them.
No. Unfortunately, anything that is not a solid yes should be a no. Hence your weak yes needs to a be a no. Due to this, you should end up in the long run with a little more noes than yeses.
Strong No. This is the opposite of a Strong Yes. Basically, in your debrief, you should go out of your way to explain why this candidate is a bad hire for your team.
Good luck in your hiring!
Software Engineering from the Frontlines Course on Maven
If you liked this article, I will be teaching a “Software Engineering from the Frontlines” course on Maven where I will teach hard-learned lessons I acquired developing large-scale products at companies such as Uber, Airbnb, and Microsoft.
