The most recent trend in interviewing developer candidates is the normal phone screen, but with a live window in which you can type and the interviewer can see what you’ve typed. Something as simple as Skype with a chat window open, or a more complex website like collabedit which gives nice syntax highlighting and auto-indentation, etc. (but not VIM key bindings, grr). I’ve noticed with this new method the questions are more difficult, closer to standard whiteboard questions than standard phone screen questions where you do not share a code editor. I’ve also noticed with this new method that I’m suddenly doing much worse on interviews than when they were phone only and/or in person on a whiteboard but I think I’ve finally figured out why.
Human behavior is complex and determined by lots of factors. All kinds of things can bias your decision making and your performance on tasks like this. I think the specific bug that’s being triggered is something called priming.
Priming is when something (usually unnoticed) in your environment changes your perception and thus your behavior. When psychologists were testing to see if irrelevant details affected our behavior, it turned out they do. The most famous example is that people who are holding hot cups (coffee) have a more favorable opinion of an interview candidate (hey, maybe should ask my phone screeners to grab a cup of coffee before we begin ;)) as compared to those who had no beverage. The exact opposite happens when people are holding cold beverages, they have a more negative view of a candidate.
I think the fact that I’m sitting in front of a computer with a text editor open is affecting the way I think about problems. I type very quickly, and normally when I have my editor up I already know how to solve the problem I’m attempting to solve because I’ve already white boarded it with a colleague. Basically my instinct in this environment is to code, not think (if that makes sense), and this is hurting me. When I’m at a whiteboard, I know that hand writing out the code is going to be slow and so I want to make sure that what I’m going to be writing out is already the near optimal solution before I start writing. This isn’t the case with the text editor open, my unconscious instinct is to start coding something that works quickly, and optimize later.
Hopefully now that I recognize what’s happening, I’ll be able to override my unconscious instincts and behave more like I’m in front of a white board, because I don’t think my request to not code live will go over so well 😉