Welcome to the club. I spent a lot of time thinking why exactly this is surprising and the result improved my hiring game a lot. So the issue really comes down

Welcome to the club. I spent a lot of time thinking why exactly this is surprising and the result improved my hiring game a lot. So the issue really comes down to the fact that most people do not really have an idea what they are doing. They don't really know what their program is going to do before they actually run it. They don't have a model, an intimate understanding of what is really happening underneath the magic incantation they just laid on the screen. When you can't predict what your program is going to do, you also have a hard time debugging your own code (debugging, after all, is finding out how the program works different in reality from what it should be doing). When you are this person, a natural tactic is to continuously compile the application and verify it works. You write a function, you check if it works well. If something doesn't work correctly, you know it is most likely code you just wrote, so it makes it easier to fix it. Just keep changing the code you just wrote until it works. This lets people write code, but there are some huge problems associated. For one, it is very inefficient. Second, it does not work with large sweeping changes -- I many times worked with people who were paralysed by trying to run large refactoring on a code base. Among these types of developers this usually does not happen and rather than keep fixing existing codebase (which requires you to understand the codebase) people will default on rewriting (which is the process they already know). Third, it does not force you to get better understanding of the application you are working on and the framework you are using. It is a crutch that you never let go of and will forever keep you from being able to run until you do. Fourth, it hurts ability to design new features and take part in intelligent design discussion. But most importantly, it leaves a huge trail of bugs. When you write code not knowing what you do, you will generate a huge number of problems, but only fix the ones that presented themselves during testing, deployment or in production. So now when I hire developers, my coding exercise is specifically designed to, among other things, detect which type of developer you are. If you rely on running the code to tell you what it is doing, you will not pass the interview. I also thought about causes of this. I think, for the most part, the cause of this is that these people never had a stimulus to learn do better. I did and I am happy for it. Unfortunately, the way people learn is through tutorials and short succinct examples where they are constantly asked to write a short piece of code and then run it to confirm you are still in sync with the tutorial. It is also a natural way of learning a new topic, technology, framework, etc. -- when I learn something new I don't write long pieces of code because I just can't predict what it is going to do. Only through learning I can build my mental model of what the framework does and only then I can achieve the goal of being able to predict what the code does and run for long stretches of time.