Long time C coder here. Knowing this stuff just shows you've had more interaction with your C compiler(s) than with humans, which is fine (I knew quite a few of the details except for some of the C++ differences because, well, I code C, not C++).<p>That said, <i>relying</i> on obscure stuff is where the problem lies. Long time C hackers almost always agree on one thing (if maintainable code is their goal and they're not engaging in some silly contest on how to squeeze a certain program into a ridiculous number of bytes or on how to write a program that you can't understand on purpuse): If you want your code to be maintainable in the long run try to be as transparent as possible about what the code does, don't rely on obscure or implementation dependent features.<p>So the 'girl' probably has huge experience, but the 'boy's answer is equally valid from a novice's point of view, because it (probably) gets the job done with a minimum of fuss (at least wrt to the initial set of questions). At some point he'll have to expand his knowledge.<p>If you had to sit through an exposition like that for every silly simple question the days wouldn't be long enough to get any work done. Literal answers like the girl gives are rarely productive, but it is good to have the knowledge that allows you to give those answers. It isn't a must for every position though, and even 'lesser' programmers have to learn somewhere (but when you're hiring you want to hire the best you can at the right price).<p>Oh, and please, do initialize your local variables before first use ;) Even if you are compiling with the debug options on, not initializing your locals before first use is a really bad idea, no matter how much you know about your compiler.<p>Later on in the series the differences get more interesting, keep clicking :)<p>What is probably frightening off many people from C is that there is a lot of arcane knowledge that the 'girl' is exposing that can actually be helpful during the debugging stage of writing a program, and that there isn't really a manual that you can read that will tell you all that stuff.<p>The only way that I know to come by it is to write code for many years and to run into those issues. I've had a couple of all-night debugging sessions that are still pretty vivid after many years and it is interesting that those bugs taught me lots about how compilers optimize, possibly more than I learned from reading books on the subject.<p>C bugs can be pretty subtle. The 'girls' knowledge can be helpful while doing hardcore stuff.<p>Given the choice between the two candidates I'd probably pick the girl (assuming she wants the same salary, which is very unlikely) and put a daily time limit on exposition ;), the 'boy' simply doesn't have that much experience yet.<p>Oh, and you can declare your 'main' fuction to be int main(void) all you want, argc and argv and envp will still be passed to it.<p>Keeping your globals 'static' in the file they are declared in (instead of (gasp!) having a bunch of globals that are declared 'extern', try to avoid that if you can) is good practice.<p>And so on. In short, there is a lot to know about any programming language, you can use questions like these to gage experience levels, don't rely on obscure stuff, explicit is better than implicit, don't expose more than you have to and so on.