[paskozdilar]

> All we did were tiny console C programs. I realized that very late, CS classes are meant to let you know about the fundamentals. You probably won't use these skills directly at work, but you will have ideas about how the languages and systems work internally. That pays in the long run.

At one point you realize, when you remove all the boilerplate, every piece of software is fundamentally just a "tiny console C program". All IPC and networking is isomorphic to reading stuff from stdin and writing to stdout. And when you ignore IPC, all you're left with is just pure algorithms.

Leetcode (and the likes) always made sense to me. It's measuring how well you can solve the fundamental problems, not how well you can fill out vendor-specific bureaucratic forms.

[explaingarlic]

I think that you're missing the linking element of software units. It can be very intimidating, particularly from an outside view.

I have been writing C for years and I can tell you in a second if you are accidentally dereffing the stack or not doing a bounds check. Yet, I still barely know my way around CMake! It's daunting, and I haven't worked on any enterprise scale C projects, hence I have no reason to learn how to properly separate, and later integrate, my software components.

[paskozdilar]

I agree, but even modularity is just an implementation detail, rising from the finiteness of human work capacity and computer resources. Algorithmic solution to the problem is the same, whether it is implemented in a single implementation-specific C file or a cross-platform multi-repo project. Also, it is (IMHO) much easier to learn engineering principles, than how to solve algorithmic problems. The latter is akin to solving mathematical problems, which require finding a problem-specific needle of knowledge in the haystack of mathematics.