Designing a solution is still far from having code that works. You have designed a solution, and now you need to test it. In significantly complicated codebases

Designing a solution is still far from having code that works. You have designed a solution, and now you need to test it. In significantly complicated codebases, there are often all kinds of obscure issues that can crop up and make your (manual or automated) testing fail. These are not things you can think of beforehand in your design because it is not possible for you to have known about all of these issues. In fact, later in your comment you allude to this yourself -- "with no time for tests". You're worried about interviews not having time for tests. But tests are a edit-compile-debug feedback loop. If a test fails, you need to debug it, fix the issue, and recompile. Often you have to do this many times. This is precisely what the blog post is talking about. You're generalizing the term "trial and error" to mean something more than what your teachers probably meant. (I do agree that those interview practices are silly. But the blog post is not talking about stuff like that.)