|
|
posted: February 18, 2017
tl;dr: To find out what the candidate knows, ask them about something they know...
I’m sure that at this point in my career I’ve interviewed over one thousand job candidates, most of them for technical positions. So I think I’ve seen what works and what doesn’t.
I’m not a fan of asking for seemingly obscure tidbits of information, such as “how many barbers are there in Chicago?” By now most people know that this class of question can be solved by performing a series of estimates: how many people are in Chicago, what percentage go to a barber, how long does the average barbershop haircut take? So all you’re really asking is if the candidate has been asked this type of question before.
I am definitely not a fan of whiteboard coding exercises taken from a college textbook, for example “FizzBuzz” or “Compute all the prime numbers less than 1000”. Why? I’ve seen far too many candidates (roughly 50% in my estimate) absolutely freeze up. Interviewers often forget just how high the pressure is on the candidate in an interview. After all, the interview is a potentially life changing event that can alter the career trajectory of the candidate. Coding in general is a solitary endeavor performed by people who tend to be introverts, and few programmers perform best when the spotlight is on them and they are being instantaneously judged. Pressure is not conducive to performance. I’ve seen candidates interview very well over the course of the day, but then the interview team gets together in the wrap-up and a person who asked a whiteboard question says “well, the candidate wasn’t able to merge two already sorted lists” or “the candidate wasn’t able to write a ‘for’ loop properly”. Then what decision does the team make?
An equivalent pressure-packed situation would be for a software manager to march each of the competent developers on his/her team into a room and say “If you can’t solve FizzBuzz on this whiteboard in 15 minutes, I’m going to fire you.” Go ahead and try this: I guarantee you’ll get some surprising results. And if you’re unwilling to try this, why are you willing to do what is basically the same thing with interview candidates?
Asking these types of questions is a complete cop-out for the interviewer. It makes the interviewer’s job super easy: the interviewer has an already prepared list of 20 or so questions, and he/she just chooses one at random and puts all of the burden on the candidate.
My favorite (admittedly, multipart) technical question puts more burden on the interviewer, because it forces a dialogue between the candidate and the interviewer in which the candidate is on much more solid ground. Here it is:
Tell me about a recent major development program that you did: what was the design goal, what was your role on the project team, what technology choices did you and your team make, what was the architecture, what did you code personally, what challenges did you run into, how close did you come to achieving the original goal, and what would you do differently knowing what you know now?
With this question the candidate gets to choose and speak about something that he/she should know well. This question can be asked early in the interview session, and it can often spawn a discussion that lasts for the rest of the interview session, if the interviewer is doing his/her job well. The interviewer should be listening intently and asking for more detail as the candidate answers the various parts of that question: why did you choose that database technology, what development tools did you use, how did you test your code and the entire system?
In my experience, asking that question and then asking for additional detail during the dialogue with the candidate will allow the best candidates to shine. Candidates should be able to speak about something they have a lot of recent experience with. The best candidates will explain their project in a lot of detail and with a lot of knowledge about how the component they wrote personally fits into the overall system. The best candidates will even teach some things to the interviewer. The best answer I ever got to that question did indeed turn out to be the best engineer I ever hired, which is the acid test of an interview question.