There's a deeper problem here, though. If you're asking, "So, that's what you think your code will do... what does the standard say?" the problem isn't really that they don't know the standard, it's that they've written the code in a way where it's ambiguous what it does.

If I see

    static int i;

in code, I'm going to change it to

    static int i = 0;

even if I know that static integers are initialized to 0 in the standard, because I know that eventually someone will have to maintain the code who doesn't know that. I don't particularly care what the standard says there: the code shouldn't assume detailed understanding of the standard, which isn't realistically a valid assumption.

You nailed it. Standards are nice and all, when they're perfectly unambiguous, and when everyone follows them exactly. That is not the real world. Writing code clearly and explicitly has far more reward for the effort put into it than learning all the standards pedantically.

Me too reply...

Don't get cute and always prefer to explicitly state in code what you get for free implicitly. The maintenance guy that follows behind you will be the one to espouse how clever you actually are. That's how I mentor junior engineers as a general rule.

The field has to accept some knowledge deficits if it's going to pretend to meet business demands. I thought the original post heavily implied that the 'dumber' programmer shouldn't be hired or have a job; are we going to turn away all potential C programmers until they've mastered everything that the 'smarter' programmer knew? I'd say that would heavily discourage new C programmers if they had to commit to mastering all of that before they could think about getting a position. That would lead to shortages, of course.