I'm with the camp that thinks that having to code on a whiteboard for an interview is just INANE. Worse than that, I find it to be borderline abusive. The whole concept just makes me quite mad. I graduated from MIT, and in my first programming class there (SICP), which I took first semester freshman year, I scored in the top 10 students out of 200 in the class. I've written software to control a space telescope and adapted brain imaging software to visualize astronomical data. I wrote a tutorial on how to do coordinate frame transformations, after first deriving the math myself (which isn't rocket science, but I hadn't done any linear algebra in 20 years at the time, so it took some thought).
Clearly I know how to code! But put me at a whiteboard and ask me to code Hello World, and I'm likely to start sweating profusely and then get very dizzy, and then just ask to leave. I managed to make it through a first round of interviews at Google, but I had to take tranquilizers before the interview to make sure that the aforementioned scenario would not happen, but I don't think that people should have to be subjected to this. And I certainly wouldn't subject myself to this for almost any other company. I'd just say, "Screw you--I can find a job elsewhere." (I didn't end up doing the second round of Google interviews because I was offered a job elsewhere, and Google said that it would take a least an additional month to make a hiring decision.)
Where I work now, the interviewing process is much more civilized. We send the specs for a small program along with some unit tests, and give the applicant however long they'd like to complete it. It should take a page or two of code and a couple of hours to complete at most. One might worry that people would cheat, but that hasn't been my experience. Most applicants never submit a solution at all. I suspect this is because they couldn't get their solution to pass the unit tests. (What we ask them to do, is not difficult. Anyone who passed a college course in software engineering with a grade better than a C should have absolutely no problem completing the assignment.)
So, then some fraction of applicants actually complete the assignment. These submissions show that the vast majority of so-called software engineers -- or at least those who are looking for jobs -- can't code their way out of a paper bag. I.e., most of the submissions are grossly inefficient and hugely over-engineered or under-engineered. Finally, a few of the submissions are passable (rarely do we get a truly excellent solution, which is kind of sad), so we have them come in, and as part of the interview, we'll have them go over their code a bit and explain why they made certain design decisions, etc.
If you ask me, this process gives us a much better idea of how someone would perform in the real world of being a software engineer and any amount of coding on a whiteboard ever could.
It is not only a far more pleasant experience for the interviewee,
but it also represents the candidates real world programming skills more accurately.
Clearly I know how to code! But put me at a whiteboard and ask me to code Hello World, and I'm likely to start sweating profusely and then get very dizzy, and then just ask to leave. I managed to make it through a first round of interviews at Google, but I had to take tranquilizers before the interview to make sure that the aforementioned scenario would not happen, but I don't think that people should have to be subjected to this. And I certainly wouldn't subject myself to this for almost any other company. I'd just say, "Screw you--I can find a job elsewhere." (I didn't end up doing the second round of Google interviews because I was offered a job elsewhere, and Google said that it would take a least an additional month to make a hiring decision.)
Where I work now, the interviewing process is much more civilized. We send the specs for a small program along with some unit tests, and give the applicant however long they'd like to complete it. It should take a page or two of code and a couple of hours to complete at most. One might worry that people would cheat, but that hasn't been my experience. Most applicants never submit a solution at all. I suspect this is because they couldn't get their solution to pass the unit tests. (What we ask them to do, is not difficult. Anyone who passed a college course in software engineering with a grade better than a C should have absolutely no problem completing the assignment.)
So, then some fraction of applicants actually complete the assignment. These submissions show that the vast majority of so-called software engineers -- or at least those who are looking for jobs -- can't code their way out of a paper bag. I.e., most of the submissions are grossly inefficient and hugely over-engineered or under-engineered. Finally, a few of the submissions are passable (rarely do we get a truly excellent solution, which is kind of sad), so we have them come in, and as part of the interview, we'll have them go over their code a bit and explain why they made certain design decisions, etc.
If you ask me, this process gives us a much better idea of how someone would perform in the real world of being a software engineer and any amount of coding on a whiteboard ever could.