Interviewing

It is no secret that hiring good talent in general is hard, and good software engineers is especially hard. Here are some of my thoughts on the subject of interviewing?

Candidate Screening

The real challenge with candidate screening is that the quantity of candidates coming through is generally not that great This means that the team has to spend a lot of time interviewing candidates who do not meet the bar.

To solve this I leverage a combination of recruiters and a coding challenge. I use a great job description, the company website, and most importantly the recruiter to sell the company and the position. However before the candidate gets time with my team, we pose the candidate a coding challenge. We provide the candidate clear instructions and no more than 3 submissions in which they must get the answer correct. If they do, we get on the phone.

Areas I probe in the interview

What I do not like asking:

• Hard Data Structures/Algorithms: One school of thought favors giving candidates algorithmic questions that involve data structures and algorithms. This approach does have its advantages – you get to see the candidates grasp of the fundamentals. Also, one gets to see how well the candidate can solve problems in code, and write intricate code. My gripe with this approach is that in most cases these problems have little bearing on the real work that we do on a day to day basis. Further this line of questions discriminates against older candidates who have lost touch with these topics.
• Puzzles – I avoid these for the same reason as above. While it could indicate a candidates ability to think, I think that asking software design questions force candidates to do the same thing, and also draw on their professional experience, which a puzzle does not do.

What I do like asking:

• Simple Programming Problems: It continues to blow my mind how so many people get stuck on simple programming problems. So I tend to ask some relatively simple questions.
• Software Design Questions: The idea here is to provide the candidate with a real world software design question and ask them to work through that. I ask them to list out requirements, do the technical design, discuss trade offs etc. These I think are great indicators of a persons ability to do the job – first and foremost because this is the job! Further, you are able to assess how well you can have a discussion with the candidate – something critical to the job.
• Behavioral questions/questions about past experience. My goal here is to understand how the person thinks, works and collaborates. It is also about seeing what makes this person tick and what they have accomplished. Questions on accomplishment also helps one determine what this person values.

Candidate Presentation

This is a system we use at the VW ERL. The start of the interview is an opportunity for a candidate to present themselves to the whole interview panel. This avoids each person from then asking the “tell me about yourself” question.