Interviewing Candidates: My Thoughts After My First Few Interviews
As I write this I’m headed into Vauxhall for my fourth week at Limejump. This time last week I had no interviewing experience at all but since then I’ve quizzed three candidates and spent a lot of time considering what a good interview process looks like and the kinds of questions it’s important to ask. Sitting in the chair of the interviewer as opposed the interviewee has shocked me - I think everything I’ve been taught about interviews is wrong.
I’ve always considered interviews as somewhat analogous to an exam or a test. If you put a lot of effort in to study and come up with the right answers on the day you’ll be successful. Stemming from that academic world view, I also believed that interviewers are subject matter experts that spend a lot of time preparing the ’exam’. So far in my experience, nothing could be further from the truth. Interviewing is a less of a science and more of an informal process - one where most interviewers are ill-equipped to evaluate candidates. I wasn’t given any training, and I doubt most interviewers are, and as a result I suspect most interviewers simply recreate the experiences they have had sitting in the seat opposite. In doing so, I imagine most interviewers fail to grasp what it is they’re actually looking for in a candidate and leave room for bias to creep into the process.
Falling back to the same style of interview that we’ve experienced doesn’t just fail because of inane repetition - it also fails because the questions were never that good to begin with. In my experience most of the questions I was fielded were more about memorization than problem-solving. Questions that committed that sin typically fell into two buckets: programmer trivia, for instance “What is the difference between ==
and ===
in JavaScript?” and softer questions such as “Tell me about a time you’ve failed.” or “What is your biggest weakness?”. Whilst the two categories attempt to evaluate different aspects of a candidate, in reality neither assess much more than your ability to predict the kinds of questions that might be asked at an interview and memorize an appropriate answer.
I also found that the process is typically biased towards evaluating breadth rather than depth. As a candidate you’re exposed to a number of different interviewers, each of which typically retreads the same basic ground. You’re asked about your experience, given some trivia questions from above, and then you’re given a single ’tough’ question to whiteboard. You then rinse and repeat, for as many interviews as the company can muster interviewers. In my experience, the process scratches the surface of your knowledge banks just enough to be frustrating but really fails to draw deep insight about a candidate. Whilst it might demonstrate the limits of a candidate’s knowledge on a given subject on a given day it’s unlikely to be a great predictor of ability overall.
Although technical ability is important, a typical day at work for me involves a lot of thinking and planning and not terribly much in the way of writing actual code. I believe the most important thing to look for in a candidate is their ability to work well with others and deal with uncertainty - writing the code is important, after all building code is what developers are there for, but doing it in a coordinated way with others whilst juggling ambiguous requirements is what makes a great engineer. Evaluating that is tough, but it’s not an unsolvable problem. Solutions like pair programming and take-home assignments are great alternatives to whiteboarding for some types of candidate.
Whilst interviewing is typically outside the remit of most software engineers at this point in their career I’ve really enjoyed exploring the word of technical hiring, and I’m trying to get better at it, if you are interested in learning a little more as well as I’d recommend the ‘Hiring Not Hazing’ episode of the Rework podcast which has been the best resource I’ve found so far on the subject.