One of the problems with all interviews is that the formality and importance of the meeting forces people into rote, scripted behaviour. This makes it very difficult to determine whether someone is a good fit.
If someone tells you they are seeking “an opportunity to apply their dynamic skills and team-orientation to furthering the company’s mission in an upwardly mobile career position,” are they a snot-nosed corporate drone? Or are they saying what they think interviewers want to hear because they have invested far more time improving their development skills than time improving their interviewing skills?
Your job as an interviewer is to talk to the person
, to get them talking about who they really are, not trying to guess what you might want to hear. “Icebreakers” are interview questions designed to put you both at ease and break out of the scripted, stilted talk that results in bad hires and missing good hires.
(That being said, I do not
suggest that they be used to determine whether someone is a good candidate or not: with all of these questions, there really is no “right” answer, and if you try to read too much into the answers, you run the risk of evaluating the interviewee on the basis of whether they are your clone.1, 2
So don’t go overboard: an interview should not be dominated by questions like these, any more than it should be dominated by computational complexity questions, algorithm discussions, design explorations, review of past achievements, or any other single factor.
I suggest you use one or two of these in an interview as a way of loosening things up. There’s anecdotal evidence that even very good candidates may react poorly to the pressure of a job interview, generating “false negatives.” Anything that lowers the pressure raises the chance of identifying great people for your team.Bootstrapping
- What was the first computer you used? What was the first computer you programmed?
- What was your first programming language? What did you like about programming at the time?
- How did you get into this industry? Why? Do you still think that reason is/those reasons are important to you?
- What’s the most incredible program you’ve ever seen? Why?
- What’s the best software you’ve ever written? Why? Can I see it/try it?
- If you had a million dollars (cliché, but still) and you already did everything else you wanted to do, and now you could write any program you wanted, what would it be?
- Who’s the best programmer you’ve ever worked with? What made them great? What did you learn from them?
- What’s the best team you’ve ever seen? Why were they the best: Quality? Speed? Awesome Software? What’s the most important reason for their greatness?
- What’s the best company in the world? Why?
Sharpening the Saw
- What’s your favourite programming language (it doesn’t have to be work-related)? Why?
- Of all the languages you’ve used seriously, what is your least favourite? Why?
- I see from your résumé that you have experience with both Scala and SNOBOL (Pick any two, obviously). If you could pick any one feature from Scala and add it to SNOBOL, what would it be? if you could pick any one feature from SNOBOL and add it to Scala, what would it be?
- What’s the most recent serious thing you’ve learned? Why is it important?
- What’s the best way for you to learn something new? Formal education? Books? Hands on experimentation? Mentoring? A combination?
- Who’s the best teacher/mentor you’ve ever had? What made them great?
One final tip about icebreakers: Try sharing your own answers to the questions. You might not want to answer them first: some candidates will feel pressured to echo your responses, but there’s a lot of value in turning a question into a conversation. Don’t turn the conversation into a monologue: this isn’t your
interview, and these are icebreakers, not some sort of secret mechanism for identifying talent.
Did you ever take that test yourself? Deckard?
As soon as you feel the conversation relaxing, move on to something important, be it asking the candidate to solve a problem or working through their experience in a more structured manner. Return to an icebreaker if thing stiffen up too much. Learn a little. Share a little. Laugh.
Remember, you are looking for someone who can make or break your team. You might want to talk with them
- In my own case, I have spent a lot of time thinking about tools and languages. So I am always tempted to like programmers who have also spent a lot of time thinking about tools and languages. However, someone who is not particularly reflective about tools and languages might be a great contributor in certain roles that don’t have a heavy “sharpen the saw” emphasis. Or, they may be delighted to learn some new tricks if placed in a supportive environment.
So the lesson for me is that if someone says the kind of thing I like to hear, great. If they don’t, I need to try another icebreaker, not evaluate them based on their response.
- Here’s a dissenting view