From an interviewer's perspective, the whiteboard gives me a chance to intervene to correct, explain, or provide hints, to the interviewee sooner/at the right time, which is not possible in pen-paper solutions, as I cannot see what the interviewee is doing till she shows me her work, unless I sit at the same side of the table as herself, which is odd for general discussion/talking.
My advice to interviewees:- Practice on a whiteboard. It is not that difficult.
There is no practice that simulates anxiety. Anxiety is mostly incompatible with the mental effort one usually applies in coding.
As you have put it, the white board is convenient for the interviewer, but that is missing the point of the interview which is to assess the candidate.
If you do not find if that difficult, than consider yourself privileged because most people feel differently. Some people cannot speak to a small audience while some love to give presentations.
An interview is already an anxiety-packed situaton where the candidate is under the spotlight. Putting them on the whiteboard solving problems only puts more pressure on and will often lead to sub-performance. Since the interviewer does not follow through when the candidate leaves, they may think that the candidate did his best.
I for one think that there should be an effort to emulate real working conditions and not performatic settings.
Ah, but there is. Once you go through few interviews you get less anxious about the next one. Which means, that if this is a serious problem for you, and you expect some important interview in the future, then you have to go and interview with some other companies before to gain practice, and may be even get some job offer you'll like more than the one you are hoping for.
The whole point of the parent argument is that there are conscious steps you can take to make whiteboard writing not stressful for you. Just practice for ten hours solving problems on it and it will be as natural as writing on paper.
>> Once you go through few interviews you get less anxious about the next one.
That's not really practice, it's actual experience.
It's also not guaranteed to improve your skills, it might make it worse if you have a bad experience. When that happens it's easy to make generalisations about the next ones. That's actually somewhat descriptive of where anxiety really comes from, antecipating the unknown.
But there's a great deal of difference between shooting targets and real combat, punchbags and live oponents, ball throwing machine and live adversary just as much as doing whiteboard problems by yourself and during an interview.
Then interview more :) I had the fortunate experience of being forced to go through 50+ job interviews during college, and nowadays it's not the least bit stressful. I think I get more anxious driving than interviewing.
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.
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.
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.
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.
I'm dumbfounded by the mentality of "I don't do XYZ" when you're going to an interview. Guess what? They'll find that arrogant.
If you really do suck at using a whiteboard, here's a really far-out incredibly expensive and time consuming idea: Go to Office World and buy a small one for $10.
Personally, I would not be bothered by this. If the candidate really won't use a whiteboard, yeah, that's strange, but it's not going to sway my opinion one way or the other. Ultimately, interviews stress people out, and I take that into account when I'm analyzing someone's performance. I care about the programming ability of the person I'm interviewing, not their interviewing ability. The worse interviewing ability, actually, the less chance there is that they're going to leave. So actually, asking to not use the whiteboard might count in their favor :)
My advice to interviewees:- Practice on a whiteboard. It is not that difficult.