For many people, "C" means C+{gcc/clang}+{x86/arm}, which has much more specific semantics than the C99 abstract machine. They'll ask interview questions like

For many people, "C" means C+{gcc/clang}+{x86/arm}, which has much more specific semantics than the C99 abstract machine. They'll ask interview questions like "what's sizeof(int)" expecting a number, and will find "it depends on the compiler/architecture" evasive, unless you follow it up with "but it's always 4". To be fair, this is how 99% of people use C in practice, and x86/arm behave pretty similarly to each other in the scheme of things (vs, say, a LISP machine). Taking into account ABI constraints, including x-{language,module} call safety, threading expectations, and more, a typical C programmer has to have a decent idea of how the machine works, relative to a Python/JS/Ruby programmer. I don't love that someone "learning C to learn how the machine works" will think malloc()/free() are how the machine works, and will get have wrong expectations ideas about memory when using, say, V8's bump allocated nursery + compacting GC. But it's not a bad first step for someone who doesn't know what a pointer is to the machine.