> The code is reviewed by the interviewer
> but probably never run.
This is what surprised me during an interview with Facebook. I tend to write a little code, run it to test it out, write a little more, test again, and so forth, you know, rapid iteration or whatever the fancy industry term is these days. The interviewer gave me these silly little shell scripting problems (silly in that they ought to have been easy and clearly had nothing to do with real life work) but instructed me _not_ to run the code. How the heck am I supposed to know if I've solved the problem? How will I know if I even have the right approach? I don't consider myself an expert software engineer and so probably not a fit for the position, but that style of interview definitely hamstrung me.
For what it's worth, being able to run programs "in your head" is a very common skill required of Computer Science undergraduate programs, where you're required to write programs of medium length on paper during exams. You should be able to write out, follow along with, and reason about the correctness of a program that can fit on a single piece of paper without having to run it. Programming hyper-iteratively is not really a good thing, especially not in environments where rebuilds or test runs can potentially take hours.
Another reason not to have candidates run the code is that they tend to get really hung up with debugging trivial errors. I've conducted a fair number of interviews either way, and the white board interviews were usually more pleasant experiences for all parties than the interviews where the interviewee was expected to execute the correct solution in front of me. The latter almost requires giving them some kind of web or library API access, which then just makes the distractions worse. I don't want someone worrying about what the exact name of a sort function is; that's not what I'm trying to evaluate in an interview.
> The code is reviewed by the interviewer > but probably never run.
This is what surprised me during an interview with Facebook. I tend to write a little code, run it to test it out, write a little more, test again, and so forth, you know, rapid iteration or whatever the fancy industry term is these days. The interviewer gave me these silly little shell scripting problems (silly in that they ought to have been easy and clearly had nothing to do with real life work) but instructed me _not_ to run the code. How the heck am I supposed to know if I've solved the problem? How will I know if I even have the right approach? I don't consider myself an expert software engineer and so probably not a fit for the position, but that style of interview definitely hamstrung me.