I recently had a job interview in which they gave me an hour to write some real code. It wasn't a huge amount, probably less than 100 lines. After about 45 minutes, I compiled, ran it, and got it to work. I may have spent 5-10 minutes working out compile errors and a couple minor bugs, but overall it was very smooth. (Incidentally, I did get an offer from them.)
However, what puzzled me was that after I handed over the completed code, the interviewer told me that the only thing I did wrong was "not compiling as I go along". I asked him what the difference is, and he said "what would you have done if you finished the code and it didn't compile in time".
In my understanding that's an invalid argument, because "getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time, which should be the same whether you do it after you finish writing the code, or if you interleave it with your coding time. If anything, interrupting your coding to search for missing semicolons would probably be detrimental to your efficiency. Except in extreme circumstances when I'm experimenting with obscurities around edge-cases on things like virtual functions in derived classes, etc. it seems reasonable to expect that code written by a an experienced developer will compile, minus the occasional typing error, and even if it doesn't, it's not as if I would have to rewrite a portion of the code in order to fix the compile error.
In another similar incident, I was given an incomplete codebase in an interview, and asked to finish it and make necessary modifications to get it running. I started by reading through the existing code, and then after a few minutes (even before I had finished looking at the code), the interviewer told me that's enough. When I asked him what he would have done (i.e. "what did I do wrong"), he told me that he would have started by immediately getting the code to compile.
Why is that even relevant? In my opinion and in my experience, whether or not a piece of code compiles is essentially random, involving things like whether or not semicolons are missing, and has little to do with the correctness of the underlying program. (To me, focusing on compiling is like running an article through a spell-check without proofreading to check the grammar.)
If you give me a piece of incomplete code, the first thing I do will be to read it. I won't even try to compile it until I know what the code is doing and I know the algorithm is correct.
Anyway, these have been just a couple recent incidents, but in general I've heard many developers talk about compiling their code as they go along, and yet nobody has been able to tell me the benefit of doing so. I understand the benefits of testing your code as you go along, but why compiling?
So my question is this: Is there something I missed? Is there actually a benefit to compiling as you go along? Or is this some sort of myth propagated by the software community that you must compile your code frequently?