[ptmx]

Perhaps I'm just neurotic, but I do find it uncomfortable to write code with someone scrutinizing my work. When figuring out how to implement an efficient algorithm, I find that it's often helpful to perform exploratory steps before actually writing the algorithm. For instance, when I attempt a projecteuler puzzle that I don't immediately know the solution to, I'll usually try to compute the desired result for a few simple inputs, or I'll quickly write down the first (naive) approach that comes to mind and then trace through it to see where it fails, etc.

I know that those are all things that I can still do during a whiteboard interview, but having the interviewer look at my intermediate work, assume that I'm making mistakes and try to correct me tends to disrupt the process. I'm confident that the algorithms that I'll ultimately produce will be good, and I'm confident that I'll produce them at a good speed, but it will still look worse to the interviewer if I write down a bunch of noise before outputting a polished algorithm.

On the other hand, on paper, I can quickly churn through some of those early steps and then show the interviewer a solid, finished product without them having to see the crude intermediate steps. Again, it's possible that my anxiety about this isn't really justified, but I can't help but get the feeling that working in this way will leave the interviewer with a worse impression of my abilities than if I have the option to "hide" the rough work and just show them the output.

[bethling]

As an interviewer, I'd much rather see your intermediate steps - the messy parts, etc. I feel like I can get a better idea about how you work and think. Interview questions (for me) aren't about "can you solve this" they're more about trying to see how you work. I ask questions about decisions you made, and I like it if you can talk about what you're thinking.

Interview problems are contrived. I don't care if you stumble a little bit. Heck, I'm always happy when I see someone start off the wrong way, notice that something's wrong, take a step back and go a better path.

If you go off with a paper and pen and just give me an answer, I miss out on a lot of that. And even though the anxiety might not show how you normally interact (and I totally understand that) - I can't possibly get any sense as to how you work in a collaborative environment.

I've never had anyone ask to do problems on paper instead of a whiteboard, and I wouldn't refuse it to them - but I just get a feeling that I'd be less likely to be inclined to hiring them - not because of the paper, but because there's no way to see the things that I most like to see.

[calibraxis]

I don't like the fact that my observations affect what I'm observing, as an interviewer. If someone wishes to yak with me at each step, fine. Alternately, if they wish to silently cast about a bit in non-rational gestalt, maybe ask me odd questions or play with the data to get familiar with it, then converge on a bulletproof solution... also fine. I do not need to stick my probes in their mind to observe each step. There exist other methods to demonstrate how they collaborate.

[jebblue]

That sounds more like a visit with Froyd than a programmer interview.

[grot]

Freud?

[dfan]

I love it when someone starts attacking my whiteboard problem by writing down something other than code, such as sample input/output pairs to test their algorithm against.