raganwald
Tuesday, May 29, 2007
  Icebreakers
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?




Life isn’t always about finding the perfect 9-5 job. Even if you don’t plan to retire under a palm tree tomorrow, The 4-Hour work Week: Escape 9-5, Live Anywhere, and Join the New Rich will help you rediscover what’s really important in your life and take concrete steps to fulfilling yourself.


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

Programs

People

Languages

Sharpening the Saw

Final words

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?

—Rachel to Deckard, Blade Runner Script


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 first :-)



  1. 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.

  2. Here’s a dissenting view

Labels:

 

Comments on “Icebreakers:
And for the "deep thought" candidate:
When you go in for a job interview, I think a good thing to ask is if they ever press charges.
---Jack Handy
 
One problem with first language or first computer questions is that it might make older candidates more rather than less on edge since they have to pick between telling the truth and revealing their age or quickly telling a fib.
 
One problem with first language or first computer questions is that it might make older candidates more rather than less on edge since they have to pick between telling the truth and revealing their age or quickly telling a fib.

You're right, that might be an easier question for me to ask (my first language is arguably FORTRAN, my first computer an IBM 360). Its pretty hard for me to sneer at someone for being a fossil. But that also points out the importance of sharing a little information: how would someone know that I consider "starting with BASIC" as meaning you are hip to the Microcomputer Revolution if I don't tell you about writing programs on actual punch cards?

But your basic point is true for all of the questions: there's always a risk that a candidate will consider every one of these questions loaded. You really have to make them feel at ease and let them know that there is no right or wrong answer.

If you have any doubt about how a candidate would view the question, find another!
 
I like the questions, but I don't have any memories of not knowing how to use a computer; perhaps I’m generalizing too much based on my own experience, but I think you’ll get that a lot with us younger folk.

I’m not even sure I can remember what my first programming language was. I think it was BASIC, but I might have done some programming before that. It was long enough ago that I don’t actually remember; I just know what my parents have told me.
 
I rather like these questions, but there are a LOT of them. Wouldn't you rather spend time working with the interviewee on an actual sample project (for interview purposes), so you know what you're getting into?

These kinds of philosophical questions are great, but I think practical coding (FizzBuzz and beyond) is a more powerful indicator of the candidate's potential.
 
Jeff:

Thanks for your comments!

I rather like these questions, but there are a LOT of them. Wouldn't you rather spend time working with the interviewee on an actual sample project (for interview purposes), so you know what you're getting into?

I would never ask all or even most of these questions in one interview. The purpose is to get the candidate to relax, so you might only need one!

These kinds of philosophical questions are great, but I think practical coding (FizzBuzz and beyond) is a more powerful indicator of the candidate's potential.

I would never presume that one of these questions could tell you much about a candidate's potential. You could try to infer stuff, but as you suggest, it's best to ask the candidate to juggle.

My message here is simply, "put the candidate at ease, give them an opportunity to talk about something that interest them, and then move onto the important questions."
 
Actualy for an expirienced programmer (who knows how to write lisp interpreter lol) answers for such questions could tell a lot about a candidate.
 
such questions could tell a lot about a candidate

Yes, they can, but I'm not quite sure how to use the information.

For example, I just interviewed someone who told me (in response to an icebreaker) that he likes to assemble his own PCs. He said he looks for the best value components, almost never the leading edge, that way he gets a good machine that does what he wants within his budget.

It's easy to extrapolate all of that into inferences about what kinds of coding decisions he would make, but it is far more accurate to just ask about code and the kinds of decisions he prefers to make.
 
Ugh. Sorry, but most of these questions are terrible as "icbreakers." They're not funny, and in most cases they sound awfully similar to normal questions aimed at just testing your skills.

Take the question of "what feature would you add from language X to Y," for instance. If I heard that during an interview I would assume it was asked to see if I really knew those languages, or if I had just tried to pad my resumé, which would cause me to immediately go on the defensive, instead of loosening up. Or not to mention questions like "what's the best software you've ever written" -- if there ever was a question where you are under pressure to say something great, it's that one.

IMO, these questions are really quite bad, at least for the stated purpose. If you want an icebreaker, ask them what their favorite novel is, or something equally unrelated to the purpose of the interview.
 
They're not funny

Hunh?

what feature would you add from language X to Y," for instance. If I heard that during an interview I would assume it was asked to see if I really knew those languages, or if I had just tried to pad my resumé

Well, we should add a little context. If I thought you didn't know either language well, I wouldn't ask that question. What would be the point? I usually filter people like that out before they get a F2F. And you don't need to know both languages well to answer the question. Almost everyone who has used two languages has an opinion on that question.

IMO, these questions are really quite bad, at least for the stated purpose. If you want an icebreaker, ask them what their favorite novel is, or something equally unrelated to the purpose of the interview.

I think you might want to think very carefully before asking someone to name their favourite novel.

Honestly, what makes you think someone would be less defensive about their taste in literature than they would be about their software or languages? If you asked me about my favourite novel, couldn't I worry that you might not like my taste? Perhaps you would think me addled if I mentioned Phil Dick. If I were feeling defensive, I would worry that you would be judging me by something unrelated to the task at hand.

I think if a candidate is defensive and worried that they will be judged on their answers to your questions, they will read that into anything you ask. Anything.
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /