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?

  • 54
    Either that, or that my habits are being called bad habits by people who have different habits. Commented Jun 23, 2014 at 12:21
  • 9
    @DocBrown The comparison is valid if the end goal is having a correct product. A program that "runs" is no better than a program that runs incorrectly. You can't expect the compile to check your code for you any more than you can expect a spell-check to fix your grammar mistakes. Commented Jun 23, 2014 at 12:45
  • 7
    Whether compiling disturbs your workflow is very subjective and depends on language, build environment, size/complexity of project etc. IMO more likely to be an issue on large legacy projects.
    – pjc50
    Commented Jun 23, 2014 at 13:02
  • 65
    I fully agree with the OP. I can't understand how someone can be judgemental about one's work habits, e.g. when he/she uses to start the compiler. The only thing that counts, is the output of the efforts. Is it correct? Is it maintainable? Does it run in the expected timeframe? How long did it take to implement it? These are the interesting questions. All else is arbitrary BS. If the interviewee writes 2 hours perfect code that compiles on the first try, where's the problem? Just because the interviewer does it differently? My godness.
    – JensG
    Commented Jun 23, 2014 at 13:18
  • 9
    It should also be mentioned that for certain languages and IDEs (Java/[Eclipse|NetBeans|etc], C#/Visual Studio, ...), the IDE is already compiling everything in the background in real time, as you type, in effect giving you an immediate feedback loop as to whether you have made a mistake. One would hope the IDE developers had some research backing this compile-as-you go approach. Commented Jun 24, 2014 at 15:10

17 Answers 17


Is there actually a benefit to compiling as you go along?

There is. It gives you a shorter feedback loop - which in general, when designing (UI, writing software, visual design etc...) is a good thing.

A short feedback loop means you can quickly fix errors early on, before they become more expensive to fix.

To borrow your example, say you were coding in a C-like language and forgot a } somewhere in the middle of the program.

If you compile just after you finish writing the statement, you can be quite certain you have just introduced the compilation error and can fix it there and then, within seconds.

If you don't, however, you would have to spend a good amount of time reading the code, looking for the exact position that the } is and making sure, once you have located the error that the fix is indeed what was intended. This would take place a while after you left that bit of code. It wouldn't be as crystal clear as during the moment you wrote it.

Now, yes, the end result is the same, but you wasted a good amount of time on syntactical issues that the compiler is there to help you with - an amount of time that could be significantly shorter if you compiled as you went along.

  • 72
    Indeed, for syntactic errors like that, modern IDEs essentially compile and recompile all the time to make your feedback loop as short as it can reasonably go, and it's unreasonably helpful for catching minor mistakes.
    – Phoshi
    Commented Jun 23, 2014 at 11:32
  • 12
    @CaptainCodeman - I'd say that there are some compile errors that would require you to dig through quite a lot of code. This is more true for larger codebases and larger change sets.
    – Oded
    Commented Jun 23, 2014 at 11:35
  • 30
    Sometimes the compiler gives you a puzzle instead of a hint, such as gcc template errors.
    – pjc50
    Commented Jun 23, 2014 at 13:03
  • 14
    @pjc50: absolutely (which is easier to handle by not changing too many things at once before the next compilation, so you know exactly what you have changed at last).
    – Doc Brown
    Commented Jun 23, 2014 at 13:07
  • 21
    The idea isn't to just compile by random. It's to compile at each significant step, to compile when you expect it to still work properly. For example, I'll compile to test to make sure than objects are being created/deleted properly, or to ensure that events are being fired properly to a new class I created. If I create a class and hook it into my program in some way, I want to make sure I did it correctly before going about hooking more stuff to my app. Less important with small apps, vital for big ones.
    – BlueBuddy
    Commented Jun 23, 2014 at 18:26

Compiling is a form of test, especially in languages which make extensive use of types such as Haskell or ML. In other languages it's a syntactic scan that tells you little.

Having said that, "compile as you go" seems to me a very situational habit. You could equally well be marked down for being "twitchy" for compiling more frequently than the interviewer's personal prejudice. It sounds like nitpicking; nobody likes to admit that an interviewee has aced the test; it tips the scales of the salary negotiation.

Not all build systems are fast. I worked on a (C++) project where Make would spend 30 seconds just stat'ting everything to determine whether it needed to build or not, and most files would take a couple of minutes to build if you had made changes. We were reluctant to do this more frequently than every 10-15 minutes. Someone will no doubt supply an anecdote of when compiling involved taking your deck of punch cards and carrying them to a different building ...

Compile when you feel you've done a complete conceptual unit in your head and are ready to have it validated. Once a minute or once a week depending on the workflow.

  • 25
    when you do take your punch cards to the sysops to load, make sure you never ever ever drop them because putting them back in the right order is a real PitA! Ah, for the days when an essential debugging tool was an elastic band.
    – gbjbaanb
    Commented Jun 23, 2014 at 14:48
  • 3
    When I first started programming I measured my progress by how much code I could write without compiling—essentially by the quality of my mental compiler. At first it was a few characters, then a few lines. Now I don't care about it. I compile a lot for small changes I just want to see the effects of, I compile very little when doing the structural layout of the project.
    – Phil
    Commented Jun 24, 2014 at 5:48
  • Hmm. Just want to say that a well written C++ file should not take more than a few seconds for compilation. If it's longer, it's a smell for bad code. And if it's so big that make has problems, I would argue that the application is too monolithic. "My" make never had problems, and afair not even when compiling Linux.
    – phresnel
    Commented Jun 24, 2014 at 11:42
  • 2
    It was 1.5 million LOC when I left. Note that Linux is C not C++; templates seem to be slow in gcc, and if you've done something clever and useful that happens to be slow to compile, there's no easy way of profiling the compiler to work out what it was.
    – pjc50
    Commented Jun 24, 2014 at 12:41
  • 22
    @gbjbaanb I think it would be better to say "the days when source control was an elastic band." ;) Commented Jun 25, 2014 at 0:08

So my question is this: Is there something I missed?

Yes: your mind is not a compiler. While a compiler can make n context switches per second, your mind cannot. The number of context switches your mind can make in a day depends on a number of factors like experience/familiarity with code base, how mentally immersed you are in the code, how clean the code is, how complex is the problem you are tackling, how tired you are, if you are frequently interrupted or in a noisy environment and so on.

Compiling a code base (all at the same time), for the first time (think "project with 20 files") will force you to switch context from what you are thinking about (e.g. "this value is set to 5 here, then in the for loop blablabla, and the complex algorithm yields the correct value on return") to a compilation problem that is completely unrelated to what you are thinking about (different file/module/function/pre-conditions/syntax/variable names, preconditions etc).

The more code you compile at once, the more context switching your mind has to make. This is not a problem for a small code base, when all the code you wrote is whatever you wrote in one hour. It is a big problem though, when working in an existing code base, with multiple (and many times undocumented) interdependencies.

Is there actually a benefit to compiling as you go along?

You minimize the context switches your mind has to make, allowing you to focus more on the impact and side effects of the changes you make. It also makes you less tired (and less prone to mistakes) and increases the quality of your output (i.e. you can guarantee minimized side effects easier when you change and compile one file at a time, than when you compile and change ten).

If you compile in very short iterations (this assumes the compilation process is optimized to take a short time) it is possible to fix compilation errors without getting out of "the zone".

Or is this some sort of myth propagated by the software community that you must compile your code frequently?

It is propagated by the software comunity as well, but it has good reasons behind it.

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

It sounds to me like you have little (to no) experience, in maintenance of medium to large legacy code bases (hundreds or thousands of source files). This is where this attitude (i.e. "compile as you go") will help the most, and this is where you form this kind of habit.

I would imagine that the people who inteviewed you drew a similar conclusion ("you have little to no experience in large code bases").

  • 1
    "compile and change ten" - plenty of situations where this is the smallest meaningful unit to try; such as adding a new parameter to a function and all its call sites.
    – pjc50
    Commented Jun 23, 2014 at 12:55
  • 7
    Context switches. You're kidding, right? If we talk about automated background compilation to indicate syntactical errors in your code as you go, that's fine. But the fastest context switch will not be able to tell you, whether the algorithm logic is correctly implemented or if the algorithm is suitable at all. But that is what sets a working solution apart from neatly organized, error-free compiled and blasting fast, but utterly wrong code.
    – JensG
    Commented Jun 23, 2014 at 13:13
  • 5
    @JenS, no, I am not kidding. Having to jump all over the code to fix compilation errors ensures you no longer think about the problem you are currently solving (gets you out of the zone). If instead, you can compile as you write code you can keep working on checking the algorithm - not the syntax. The fastest way to handle context switches is to ensure you won't need them). My post does assume an ideal world though (with fast C++ compilation of large code bases and minimized inter-dependencies).
    – utnapistim
    Commented Jun 23, 2014 at 13:28
  • 1
    @JensG that seems to be a logical fallacy: this is not about choosing between compiled code and shitty code but about any possible benefits of compiling more than once.
    – Jorg
    Commented Jun 23, 2014 at 13:32
  • 1
    I doubt that the claim that breaking concentration dozens of times for a short amount of time to fix single syntactical errors is faster than breaking it once and fixing a dozen syntactical errors in one go (after you worried about your actual algorithm). That's certainly not how context switches work in computing (we're trying to optimize for throughput after all here). And I've been working on a project with about 500k LoC of C++ code that has evolved over more than a decade, so I hope we don't draw the inexperience card just yet?
    – Voo
    Commented Jun 25, 2014 at 23:31

I think there is more than a little professional snobbery here. The implication seems to be "if you've never had the need to compile regularly then you've never worked with anything that complicated - go get some more experience and come back when you've learned to work exactly the way we do."

But obviously there is another side to this. Some projects take an age to compile. I've worked with frameworks that take 30 minutes or more to compile after even minor edits. Heaven help you if you ever need to edit a header file. Full recompilations are typically done overnight, and if you're relying on the compiler to catch your mistakes there are still rare errors that won't be detected during a partial build. You just don't re-compile every 5 minutes under these conditions - unless you're feeling lazy.

The compiler cannot help you with logical or semantic errors and syntax errors really aren't so hard to avoid that spending half of your day compiling becomes worthwhile. Of course, you'll make the occasional typo, but I'm going to assume you can both touch-type and read. If you have the freedom to choose, use a coding style that makes good use of layout to visually highlight errors and you'll never drop a brace, bracket or semicolon ever again. It takes a little practice and a little more discipline than most are used to, but it is possible. I can write code for a couple of hours at a time, in a plain text editor, and compile it first time better than nine times out of ten. Sure, I could compile more often, but I can't remember the last time I had an error that would have been easier to correct as a result.

If you aren't a fan of constant recompilation, you're in good company. Here's Donald Knuth:

As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about.

All of that being said... if you're working in a context where compilation is a free action, why wouldn't you? At home, on personal projects, I hit ctrl-S about once every 30 seconds and the "compile" shortcut nearly as often, in an IDE that constantly runs the code through the compiler's front end to provide real-time error highlighting. Why pass up a free lunch?

  • I disagree that compiling is free, distractions are costly! But otherwise, good answer, thanks :) Commented Jun 23, 2014 at 23:00
  • Maybe I should have made the bold, italicised "if" an "iff" instead... I think depending on the project, compiler and environment it can be pretty darn close to a free action. If you have a second window or screen for compiler output then you can compile nearly as often as you stop to breath. If you were really hardcore (I'm not) you wouldn't even need to look away from your code - provided the compiler produced verbose enough errors to register on your peripheral vision. Again, this is iff compiling is reasonably fast, otherwise see above. Commented Jun 25, 2014 at 1:10
  • 2
    I hit ctrl-S about once every 30 seconds. I probably save twice as often lol. It's a really bad habit. Sometimes I'll save in the middle of a line of code, and then save again at the end of it. Whenever I stop to think for a second and not typing, I save.
    – Cruncher
    Commented Jun 25, 2014 at 18:00

There are merits to compiling as you go. But I very much agree that staying on task is an OK coding strategy.

The most significant benefit to incremental compiling is the mentality many get in if they wait for the end to compile and test: we're more concerned at the end in getting the code to run than anything else at that point. We say "Oh, just need to add this bracket so the compiler stops complaining" or "oh just need to capitalize this" without thinking if there is an underlying semantic error that this syntax error hides. I really do find syntactical errors often nest themselves in semantic errors (the converse not true).

As an example, say I changed a variable's meaning and as a result, changed its name. The name change generates a syntax error later on in the code but if I just please the complier by correcting the name, I've ignored why that error came into existence.

  • 5
    +1 for highlighting the connection between semantic and sytactic errors
    – Doc Brown
    Commented Jun 23, 2014 at 14:16

I understand the benefits of testing your code as you go along, but why compiling?

But how will you test your code as you go along when you don't compile accordingly?

The extreme case is test-driven development (TDD). It is obvious that TDD does not work with your strategy, since TDD means extremely short cycles of write-test, compile (should fail), write-code, compile again, run-test, fix-bugs, compile again, refactor, compile-again, run-test, and-so-on...

So not everyone does TDD, at least not always (me too, I admit). With your current strategy, you will never have a chance to even try TDD. But even when you are not doing TDD, it is IMHO extremly helpful to test your code more regular - which is not possible when you don't compile it regularly. And when your test fails, you have running to debug it (which can help you to understand why the nice looking algorithm you have written some minutes before does not behave so nice as you thought it should do). And the more code you write without compiling, the more code you write without testing, so the more likely it will happen that you run into a case where you cannot predict that the time to fix the problem is "O(1)", as you wrote.

  • 1
    I agree with you, but I think there is a difference between compiling a program because you want to run it, vs. compiling when there is nothing meaningful to test (or for fixing compile errors). Commented Jun 23, 2014 at 15:03
  • @CaptainCodeman: I think when writing 100 lines of code, there should almost always be plenty of small parts which could be individually tested for its own. 100 lines of code typically means something between 4 and 15 functions (or >20, if you code in Bob Martin's style).
    – Doc Brown
    Commented Jun 23, 2014 at 15:28
  • 5
    @CaptainCodeman: In TDD there's never "nothing meaningful" to test. The classic example is you want to write a new class (lets call it Foo) then the first thing you do is to create a unit test and write new Foo(); which will obviously fail to compile since you haven't written the class definition. In TDD that's a valid reason to run a compiler - it proves that your unit test is working (by failing).
    – slebetman
    Commented Jun 24, 2014 at 8:12
  • @slebetman: thanks for that helpful comment. I would like to add that IMHO this is not restricted to TDD. When writing 100 lines of code, there is always something meaningful to test in between, if you do TDD or not.
    – Doc Brown
    Commented Jun 24, 2014 at 9:02

I actually agree with you that compiler errors should be no big deal for an experienced developer. I don't think the cost of fixing them increases significantly enough over time to worry about. If it were possible to postpone fixing all the compiler errors until just before a push, I would do so, as it would present a much smaller and more consolidated interruption.

Unfortunately, finding compiler errors isn't the only thing compilers do. At the risk of stating the obvious, compiling is required to run your program, and running your program is required to find all the more complex, subtle, and interesting runtime bugs that even experienced developers create. And those types of bugs are more difficult and therefore more expensive to fix the longer you postpone debugging them, because they can build on or mask each other.

However, I wouldn't necessarily mark someone down in an interview exercise for postponing compiling until the very end. Interview exercises tend to be very straightforward, and experienced developers usually know their limits. The more confident you are about what you wrote, the longer you will go between compiles. That's just human nature.

In order to not mark you down for it, the confidence would have to be justified, though. If you had spent 45 minutes writing something without compiling, then required another 45 minutes to debug it, I would have weighed that heavily against you.


The one important thing about compiling often, missing from other answers as far as I can see is this: if you compile rarely and get a large amount of compiler errors, most of those are meaningless, because they are generated by the first error. It could be because you had wrong type, or typo, or plain syntax error which makes some declaration invalid.

You could always just fix the first one, recompile, fix the next remaining one, and so on, but with large code base this can be slow. But if you try to skim through the long list of compiler errors and spot errors which are independent, then you spend a lot of time reading irrelevant messages, or navigating code from secondary error spot to actual cause.

Another thing going for regular builds is, nothing stops you from starting to compile as soon as you have a complete block of code written, which should compile. You can then continue writing more code while compilation goes on, just as long as you don't save the new edits until compilation finishes. So there's practically no time wasted on waiting for build. If you wait until you have written everything you are going to write at that time, you then have to wait for compilation without nothing to do. This is basically the manual version of what modern IDEs can do in the background automatically.

  • Interestingly, this is a good reason to regularly compile even if compilation is slow. Good point.
    – sleske
    Commented Jun 25, 2014 at 9:19

For a sufficiently experienced programmer compiling code is never the bottleneck.

Once you know a language well enough (i.e. when you no longer have to think about the syntax and instead just code for functionality) you tend not to make simple syntactical errors. Those you do make are usually typos or copy-paste bugs, and they can be cleaned up in short order with just a few compilation passes.

I regularly write code all day without compiling, then I'll compile and just fix up what syntax errors and warnings the compiler reports before I commit my code (with a note that says "needs to be tested!"). I have no problem cleaning up 1,000+ lines of C or C++ code in just a few minutes.

Debugging and testing on the other hand is what takes a while. Logic errors arise for all sorts of reasons and I have yet to meet a compiler that will tell me about the subroutine I totally forgot to write, or will notice that my binary tree doesn't work because I pasted node->left when it should have been node->right.

While I think it's generally unwise to fight with an interviewer, I'd say if you felt your style was worth defending you should have pointed out that you left yourself enough time to debug the code you'd written. That's the thing no good programmer ever neglects.

p.s. - If I had been watching you review code by reading it, I would have hired you on the spot. That's what a pro does, every time.

  • 4
    "I have yet to meet a compiler that will tell me about the subroutine I totally forgot to write." I totally rely on the compiler to tell me when I've not completed far-reaching changes. Sometimes I even rename a variable to prevent successful compilation until I've checked every instance of its usage and given them all the new name. I don't understand how you can say you haven't come across a compiler that won't warn you if something is missing. Unless you are writing empty place-holder subroutines and then forgetting about them, in which case heaven help you.
    – Ian Goldby
    Commented Jun 24, 2014 at 11:57
  • @par Thanks for your answer; It's good to know that I'm not the only one that codes like this! Commented Jun 24, 2014 at 12:27
  • 3
    @CaptainCodeman I'm well aware that logic errors are more insidious than compiler errors. But it was his assertion about a compiler being unable to tell you about missing code that I wanted to dispute. Unless you are deliberately writing wrong (or incomplete) code that compiles…, but that rather defeats the argument that errors the compiler can't catch are the real problem IMO. Heck, I even use the compiler to move the caret to the line where I next need to write some code. But maybe I'm very lazy.
    – Ian Goldby
    Commented Jun 24, 2014 at 13:20
  • 1
    @IanGoldby: You missed the point entirely and I'd even go so far as to say you elected to twist my words. The compiler can't warn you about missing code in the same way I can't tell you what you'll eat for breakfast tomorrow. Introducing syntax errors intentionally so the compiler will remind you of something is a programming technique; it doesn't qualify as an error or give the compiler psychic superpowers.
    – par
    Commented Jun 24, 2014 at 17:57
  • 1
    @par I apologise for the offence I have obviously caused by my comment - it was not intended and I certainly did not intend to misrepresent what you said. I see now that when you write incomplete code that nevertheless compiles, you make it a practice to ensure that it can't be forgotten by adding #warning or TODO. That's a legitimate technique. The important thing, on which we both agree, is that code that compiles but doesn't work is far more dangerous than code that doesn't compile.
    – Ian Goldby
    Commented Jun 25, 2014 at 7:32

No, it's not unreasonable to hold off compiling until you've done a sufficient amount of code (and a 'sufficient amount' depends on the coder and the code being written).

For example, if you're an awesome coder who takes his time to get it right, and you're not writing massive amounts or convoluted code, then compiling regularly is a waste, and probably a distraction too. If you're not, then compiling every function can be a good thing. It depends on the person.

As a counter-example, imagine you're writing JavaScript code - there is no compiler. Instead (given the nature of most JavaScript code) you would run the program (or refresh the page) to see the results of your coding. Now, you cannot do that until you're written enough code to make sense. As a result, JavaScript developers tend to "compile" as often as they can, which isn't necessarily very often.

In short, there's no correct answer here - the interviewer isn't wrong, but neither are you. Do what makes you productive and forget what anyone tells you you're supposed to do. There are much more important factors about coding than your tendency to hit F7 regularly (or not) is of absolutely no consequence.

  • Your second paragraph is unclear; you may want to edit it, to be clear if the "awesome coder" should compile regularly or not. (Did you add a "t" and change "no" to "not"?)
    – DougM
    Commented Jun 23, 2014 at 15:52
  • @DougM - ta muchly.
    – gbjbaanb
    Commented Jun 23, 2014 at 15:55
  • Quite often scripting code is developed "live", that is it is executed in REPL environment. So "compilation" indeed happens all the time, most code that is written to the source file has also been executed once. Not all write script code this way, but I'd say anybody used to and fond of the relative "safety" of statically typed languages and compiler errors given by bad code, they should work in scripting languages this way.
    – hyde
    Commented Jun 23, 2014 at 18:55

With a good development environment I see little reason to compile unless you're actually planning to test code. The background syntax checking tools catch most everything that the interviewer seems to be talking about, although I will admit there are still a few cases (involving changes that propagate across files) that aren't always fully identified.

That being said, I will try to compile and run pretty much the smallest unit of code that can actually produce an outcome. Half an hour ago I was creating a means of printing some search results and I did half a dozen test prints (to .pdf, not paper) making changes to the result to make it look better--a rate of about 1 compile per 10 lines.


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.)

My experience is very different: less than 5% of compile errors I get are about syntax. I know the language well, when I get errors it's mostly type errors, telling me that the semantics are not correct.

This is why I am happy to benefit as quickly as possible from the feedback of my compiler. Have you ever experienced using an IDE which underlines compile errors in real-time? Having a shorter feedback loop can be very valuable.

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.

If you are expected to work on code written by someone else, you don't always have time to read everything. The good news is: well-written code has low coupling, and should enable you to reason independently about just the part of the code that you need.

In those cases you have to assume that the code you have not yet read is correct, and investigate lazily when there is a problem.

"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.

Context-switching is costly for your brain, therefore fixing small errors as soon as you write them can be more efficient.

EDIT: I can also make an analogy with source control, when a whole team is working on the same sources. Compiling as you go along is like making frequent commits, it helps to avoid having a lot of pain at the end when you have to merge and sort out everything.

You say that you disable things like red lines under your text. Do you also do that when typing an email or writing a technical document? Then you have to proof-read again all the pages instead of fixing mistakes as you go.

Another advantage is, when working on your code, if you keep it compiling or near-compiling at all times, you can benefit from a lot of semantic-based IDE features (safe renaming, refactoring, finding uses of a symbol...).

If you want to have a better understanding of how these features help, you could try enabling them and practicing, to experience yourself their benefits. You could also try to do some pair-programming with anyone that is used to them, and see how they benefit from them.

  • 1
    I usually turn off annoying compiler "features" like auto-formatting, drawing red lines under your text, etc. as I find I'm more productive without these dumbed down features. Commented Jun 27, 2014 at 8:45

I thought a bit longer about this, because I felt that there is something very, very wrong with the interviewer and couldn't exactly point out what it is. Here's the problem: For any code that I have written in the last twenty years, the amount of time needed to turn a workable algorithm into code that compiles has been minimal. Any gain in efficiency in that area has so little impact on total development time that it is totally negligible, and an interviewer who rejects a candidate for perceived inefficiencies in that area has no idea what makes a good developer.

Most time should be spent on gathering information what the code is supposed to do, gathering information and specs about outside services that need to be used, creating a global design that will lead to correct and maintainable code instead of hacked together code, and finding algorithms that will lead to working code instead of code that is patched together until it happens to work (code that has obviously no errors vs. code that has no obvious errors).

Then come a tiny amount of time writing code that compiles.

Then comes a larger amount of time spent to make sure that the code works, and to make sure that we know that the code works and will stay working. Which is done by writing unit tests, stepping through code, and to a large extent by having well-designed code in the first place.

This interviewer concentrated on something that is covered by ten words in my reply. Which represent 10 percent or less of the actual working time. And has almost zero influence on the ability of that developer to produce reliable and working code.

  • That makes a lot of sense. In my opinion, a good developer should be able to write code on paper all day, and then at the end of the day type it up. Commented Jun 27, 2014 at 21:56

The advantage of "compiling as you go along" is you get constant feedback, and won't have a chance to go far wrong before being pushed in the right direction. For a competent programmer like you, that's not a huge consideration, but for many others it is. Put another way, "compiling as you go along" is a way of "minimizing the maximum loss," even though there are some potential efficiency losses in your case.

Companies these days aren't just interested in a finished product. They want to know that it was "under control" all along. For them, "getting there is half the fun."

  • this doesn't seem to offer anything substantial over what was posted in prior 16 answers
    – gnat
    Commented Jun 27, 2014 at 21:52
  • 2
    Thanks but what kind of loss are we talking about? Surely, unless you've done something drastic like accidentally write in the wrong language you would never have to rewrite any code simply because of compile errors. Commented Jun 27, 2014 at 21:53
  • @CaptainCodeman: It makes companies feel better, and is a form of "insurance." That's something that costs money, but makes most people (including managers) "sleep better at night."
    – Tom Au
    Commented Jun 27, 2014 at 22:09
  • @gnat: The point I was trying to make was that most of the benefits were "corporate" level benefits, and it's something that the programmer should do because the boss told him to, not because the programmer thinks it's right or wrong.
    – Tom Au
    Commented Jun 27, 2014 at 22:16
  • well points in favor of "shorter feedback loop" have been already made and well explained in very first answer here; I honestly don't see how stuffing bare guessing about "companies these days" adds anything worthy over what was already stated
    – gnat
    Commented Jun 27, 2014 at 22:22

The other answers here mount a good defense for compiling frequently on the job, but since your question is centered around interviews, I'd like to tackle that angle of it.

In my interviews, I do the exact opposite: candidates can't use a compiler. They write short programs on the white board and then we discuss them. I have found that too many developers use the compiler (or interpreter) as a crutch, and that is a far bigger waste of time than compiling too infrequently. If I'm offering you a lot of money and you can't even write FizzBuzz correctly without a compiler, then you're never going to cut it on a long term basis, working on problems that are 100x more difficult than the toy exercises in the interview. And yet these simple exercises weed out more candidates than any other part of the interview.

The goal of an interview is to evaluate the mutual fit of the candidate and the business. A good interview question should state the objectives of the question and how the interviewee will be assessed. Springing a trick question on the interviewee and then penalizing them for not knowing the hidden answer doesn't help the interviewer or interviewee. Unfortunately, most programmers — even senior ones — aren't trained to interview other programmers, so they just rely on clichés and ask the same types of questions they were asked when they interviewed, without much though about whether these are effective techniques for evaluating candidates or not.

I'm not claiming that my approach is the "one true way", but it has served me very well. Like so many software methodologies that start with a capital letter, there are an equal number of "mandates" for interviewing. They're all bunk. You need to do what works for you and your business.


In larger projects, with several subroutines, you want to test these parts, before using them in the larger scheme, since it is way easier to debug if you know certain parts already work.

In order to test these smaller pieces, you need to compile.

It might be that the interviewer confuses this situation with a small program that is not designed in this manner.


Regarding the second interview, a benefit of compiling is that you can observe, within just a few seconds, what the programs does (or doesn't). From there it is easier to read the code and to focus your efforts on the relevant parts. Perhaps this is what the interviewer was expecting.

Reading an unknown code base like this from beginning to end can be quite unproductive (you're not a compiler), while compiling/running the application will quickly give you a bigger picture.

  • this doesn't seem to offer anything substantial over what was posted in prior 15 answers
    – gnat
    Commented Jun 27, 2014 at 21:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.