Apart from the interview questions, there are a lot of factors to consider while interviewing software engineers. In this write-up, I try to summarize the concepts that I have learned in the past 12 years of hiring software engineers across domains, teams, and levels.
The goal of this write-up is to put forward the thought process that can be used to structure the interview and read the indicators to decide if a candidate is a good fit for your organization and role.
Hiring is one of the toughest problems of our industry. Identifying a very good or a very bad fit is sometimes straightforward, but evaluating someone who does not stand out can be tricky. A great engineer may just be having a bad day or a little nervous during the interview, and you would want to evaluate them at their best.
Before the Interview
Before going to interview a candidate, I recommend spending some time asking yourself the question - “Who do you want to hire?”. Based on this, you can structure the interview to evaluate and get hints about their capabilities. I try to list out the qualities I would want in the prospective hire - like the attitude, level of technical skills, cultural fit, etc. and prepare my questions so that I can evaluate them on the above.
During the interview
I keep notes during the interview and compare them with the skillset list I prepare before the interview. If I am not able to get a good read on something by midpoint in the interview, I try to channel the discussions around the data I feel is missing. For instance, if I want to evaluate their coding style or attitude, I will start a discussion around that or ask them to focus on a specific part of the problem that would help me make that decision.
Evaluating technical skills - coding
If I am on the panel for the coding round, I start with a barrier question. I want the candidate to be able to give their best performance in the interview and I have noticed this helps a few candidates get comfortable and boost their confidence. All-day-long interviews can get very stressful and tiring.
Evaluating technical skills - design
For a design interview, I sometimes take points from something I built in the past and then discuss with them the reasoning of the design decisions they make along the way. If you take this approach and decide to go with a problem you have worked on, it is a good idea to generalize it and not use terms and acronyms that are not standard. If you do, make sure to explain them to the candidate.
Generally, as the hiring levels go high, the abstractness of the problem and the expectation of understanding underlying concepts would increase. If I am hiring for an entry-level position, questions will be less abstract and more laid out. As the level goes up the questions become more abstract. It allows me to dig into certain areas and gauge whether the candidate can make intelligent suggestions, proposals, and deductions from the conversation.
Soft skills and Culture fit
This is the hardest to gauge as this can be faked during the interview. This is why having multiple people on the panel can help you collect different data points regarding the behavior. Some hints that you can get from the interview are - do they interrupt a lot? are they respectful? do they talk over you? how do they take feedback on code/design - are they defensive?
Finally, the most important one - you should try to come out of the interview with an answer to the question - Will you like to work with them?
Final word
I will like to state it again that this is one of the most difficult problems of the industry and getting it right all the time is very difficult. But, you can use certain concepts to arrive at a decision that is good most of the time. This is also not a perfect guide. It is evolving with each interview I take and candidate I hire. Hopefully, this helps you bring on board your next great hire!