When I was recently looking for my next adventure, I sampled a variety of interviewing styles in my search for an exciting team. I eventually found a great team at ToyTalk (the fact that I decided to leave ToyTalk is not because of the people - see my earlier post for details).
During this month long search, I found myself in day long meetings at ex-Googler founded startups having them feed me "Google-Style" interview questions. Now the "Google-Style" interview has been around before it earned this connotation, often called "TopCoder-Style" interviews. There's been a lot of discussion on the internet on whether this is a good judge of candidate strength. Here's two examples plucked from Google's top hits: Do Google Style Interview Questions Illuminate the Talent in Front of You and In Defense of the TopCoder-Style Software Developer Interviews.
It was during these long and sometimes awkward sessions of unearthing deeply buried tidbits from my undergrad days that I found myself thinking more about what made me uneasy about this style than the questions themselves. I see the benefit of putting out a hard question related to computer science and then test a candidate's thought process, temperament, and general ability to get unstuck. What some interviewers forget, however, is that an interview is an evaluation in both directions. My interviewers were giving me questions they had used many times before, and in many cases, they were not active participants. They were spectators throwing me a line only when I began to flail. Giving me a rote test is not very inspiring, and shows you don't care enough to tailor the interview for my best. I believe what was once called "TopCoder-Style" interviews has become overshadowed and subsequently tainted by the "Google-Style" interview because the Google employee got so used to passing judgement on candidates desperately climbing the hill. They forgot what it was like to be selling as much as they were buying.
While at Pixar, those of us technical directors hiring for a creative and technical competence designed a style of interviewing that I think is a better at not only getting to know if the candidate will become a good team member, but to inspire that candidate to want to work with you. Before the day of the interview, we asked a candidate to send us a snippet of code from a project they worked on, ideally a project that produced something visually interesting. It could have been a single function or a fully running piece of python, c++, glsl, whatever. We wanted to give the candidate a chance to swing at a soft ball, something in their wheel house. On the day of, we asked the candidate to teach us about their code and their project. It was then on us as interviewers to ask thoughtful questions as if we were students coming to a TA. This not only tested the candidate's understanding, but showed the candidate our strength in being able to understand a topic quickly, think critically, and socially engage in a way that made the candidate feel special. Those candidates that enjoyed the experience, embraced the empowerment, and generally geeked out on a topic they cared deeply about always proved to be a rockstar team member.
The power of this approach was not necessarily the code snippet, although that was helpful to get a sense of general code cleanliness. The power came from making the interviewee the teacher and the interviewer the student. So instead of using a canned question, next time, at least try beginning with "Teach me something."
