The other day I had read an interesting post by 37 Signals entitled Why We Don’t Hire Programmers Based On Puzzles, API Quizzes, Math Riddles or Other Parlor Tricks (say that 10 times fast). Then I was pointed to another article by C for Coding entitled Interview Programming Problems Done Right. That got me thinking about the interview techniques that I’ve used at my current and prior jobs. It’s a different style than either of those two posts, so I figured it was worth talking about.
What’s The Point?
If you think about it, what really is the point of an interview? Is it to determine how much they know about development? I would argue that’s impossible to determine that in an interview (all you can find out is if they can talk the talk). Is it to figure out how good of a problem solver they are? Under the pressures of an interview, even a great problem solver can stumble. So if it’s not technical ability, what’s the point of an interview?
To me, the whole point of an interview can be summed up in one word: personality. I want to see if a person is going to be a good fit for the team. Will they work well with others? Can they communicate well? Are they excited about technology, or are they just doing it because there’s money in it? Are they motivated to learn? These (and more) are the questions I want to answer in the interview. We’ll get a sense of their technical ability as well, but that’s not the focus.
The Place For Puzzles
I do like to use puzzles and difficult questions during the interview. They are a small part of the overall interview, but they are used at least once in every interview. The point that 37 Signals made is very valid in that solving puzzles shows very little about ability. But we don’t use puzzles to determine ability. We use puzzles to put the candidate outside of their comfort zone. I want to see someone not know the answer and/or get frustrated. Why? Because how they act when they are in that state will tell me more about their personality that I need to know than any other method I’ve found yet.
Think about it. When presented with a problem you don’t immediately know how to solve, what do you do? Do you get angry? Do you get frustrated and start to stutter? Do you get flustered and stop being able to think? Or do you slowly try to talk out the problem? Do you try asking for help? Do you admit that you don’t know how to do it (hint: this is not a bad thing at all)? Then, when walked through the solution (if you didn’t get it yourself), how do you react?
Frankly, I don’t care if the candidate gets the correct answer to the puzzle or not. How they get to the answer is what I’m looking at. I’ve had very good candidates (which were given offers) get the puzzle wrong. And I have had poor candidates get the puzzles right. But how they acted and their body language told me everything that I needed to know about that person.
The Problem With Code Samples
The post by 37 Signals indicated that they use code that the candidate wrote previously as a key factor in determining the candidate’s success. Personally, I feel that this is very difficult to do in practice. First off, it’s not easy to determine if the code was actually written by the candidate themselves (was it written in a team setting? was it plagiarized? etc). Second, often times the code samples are so small that it’s hard to get a big picture of their abilities (really, think about demonstrating your abilities in a few files. not easy).
There’s a far bigger problem with code samples though. You don’t know the circumstances under which the code was written. Was there pressure from a boss or deadline that changed the code? Was there a rogue senior developer / manager that forced the code to be what it is? Was the code written for a one-off project or is it part of a large system? Sure, you can talk about these things in the interview to try to get a better picture, but that sounds more like attempting to justify bad code than understand why it was written like that…
The Problem With White-Boarding Code and Algorithms
I know the C for Coding post talked a lot about writing actual code during the interview. Personally, I don’t find that overly constructive during the interview. If you think about writing code on a white-board (which I think most of us have done at one point or another), it really isn’t realistic at all. When’s the last time you wrote code without a reference of any kind (including your IDE). It doesn’t happen often. So why should we expect an interviewee to do it in front of us (under the added pressure of the interview)? I’m reminded of something that an old flight instructor of mine told me:> Nobody will ever expect you to know everything off the top of your head. But you will be expected to know where to find it...
When it comes to sitting the candidate at a computer to write real code, that’s a little bit of a different story. I’ve done it for a few interviews, and honestly I don’t feel that it’s a good use of time. I’d rather learn more of the candidate’s personality and see how they get along with the team. Their code will be reviewed when they are hired (as everyone’s is), so why focus on that in the interview?
The Importance Of The Team
To me, there is nothing more important than a team that can work well together. To that end, hiring the best developer in the world can actually hurt a team if they can’t work together. I know common knowledge is that a skilled developer is orders of magnitude better than an average one. However, the other important factor to consider is that a single poisonous person can do far more harm to the teams work than their skill offset brings to the table.
I can teach someone to be a better developer. I can teach them new paradigms and skills. What I can’t teach is how to work well with a team. I can’t teach how not to be poisonous. So why would I want to focus the interview on what I can control?
Disclaimer
This is not meant to be a post on the right way to interview. It’s not meant to even be a “you should rethink how you do things” post. All I wanted to do here is show some of the rationale behind how I interview share my thoughts and experiences on the matter.