Good point, but I think this is probably more true for a higher-level language (C#, Java, Ruby, etc.) in a domain that is probably more focused on feature delivery than performance.

For an embedded systems C coder (which was the stated context of the interview) working in a memory and CPU-constrained environment, seemingly arcane knowledge of the compiler and runtime can be crucial, so in context I think these questions were very appropriate.

I would say rather than exclude low-level exercises like this, in favor of more high-level concerns like GOF, SOLID, etc., why not use both types in order to find out what kind of strengths the coder is bringing to the table?

I've found that a lot of coders who tend to be very design/architecture/strategic focused (for instance, me!) tend to have weak areas in low-level/tactical concerns, and visa-versa. Both kinds of coders can be a great asset to a team, and provide a diversity of expertise while pushing each other to grow in weaker areas.

If you can find a coder that does both strategic and tactical very well, you might have found a team lead.

I agree on the "I would never write code like this" point. I have never read the C standard and don't know off the top of my head what happens when you fail to initialise a static vs auto variable, but I don't really care because I would never write code which relies on whatever the implicit behaviour is. If I found code which did that on a project I'm involved with, I'd search for what is supposed to happen and then fix the code to make it explicit.

If I was interviewing, I'd much rather hire someone who said "I'd never write code like that" to someone who reels off what might happen in every possible scenario, unless I was hiring for a compiler writer.

I disagree. I feel that knowing what might happen demonstrates that the individual has considered the design of C carefully and taken the time to find out how it is, and why it is the way it is. I think that sort of knowledge always leads to better code in the language.

The man in the example might know to "never write code like" a variable incrementing and assigning to itself again, but there might be other, more subtle pitfalls in design and implementation that he succumbs to because he hasn't given much thought to all the different ways that the rules of the language can interact.

I agree - the girl's knowledge might be a net win, provided she doesn't go out of her way to use it.

Note that it's not all stuff that you can just look up: although you can look it up, it might not be obvious that it needs to be looked up. I had no idea there was a difference between `int f()` and `int f (void)`, and if that ever caused problems for me I doubt I would have been able to track it down easily.

"A gentleman is someone who knows how to play the bagpipes, and doesn't."

I think there is a point of expected knowledge though, as somethings really won't matter in the long run. It's been a long long time since I've touched C, but if I remember right a big issue with int main() & int main(void) is that if you don't have the void to tell the compiler that main takes no argument then you can cause lots of micro-controllers running your code to crash. This fact makes the void knowledge more important for micro-controller programmers then it does for Windows programmers (although it's very simple knowledge that a lot of people state).

Sure, but would you really care whether someone knew off the top of their head that %zu is the escape sequence for size_t? Some of the stuff she shows off is pretty arcane, though pieces of it are actually useful.

Understanding the memory model and execution model is a big plus, because it lets you write correct and efficient code (and if you are using C you care about correctness and efficiency). Recalling arcana about the C99 standard is just overkill and asking someone to pull stuff like that out of a hat in an interview is asking too much IMO.

I have to work with folks who confuse size_t with int, and as a result they have overflow bugs depending on whether O_LARGEFILE is in use. So yes, I care. Not because printf format strings are terribly important, but because understanding and adhering to the type system is essential to write bug-free software.

If they get overflow errors then your build process does not have the right warnings enabled/logged.

Suggestion: enable -Wall and treat warnings as errors.

Of course. You and I know they're doing it wrong, however sirclueless suggested above that type correctness is "arcane" and asks if "we would really care" when it comes to type issues in printf format strings.

Handily, gcc has -Werror, which turns all warnings into errors. So -Wall -Wextra -Werror should catch most things.

Except if you're using gcc (mingw) on Windows:

gcc -v shows that it's been configured with --disable-werror

If you're being sensible and using -Wall with gcc, it will pick up the %zu thing anyway:

sizeof-test.c: In function ‘main’: sizeof-test.c:5:3: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’

Compilers have warnings so that you don't have to remember archaic bits of C. :)

Learning arcane trivia is a side effect of learning the necessary stuff.

Yes, I would care. Someone who didn't know might notice the sizeof() and note that it returns size_t, but not know what to do about it, and end up saying "screw it" and just using "%d", which is not portable, and the program might crash when compiled for a different system. It might even run on his sytem today, but not tomorow, or run in the debug image but fail in production. I've seen this and similar things happen many-a-time.

Pet peeve alert: sizeof is not a function. It's a unary operator.

The parenthesis you usually see after it are part of the argument, which for type names looks like a cast to the type in question. Like any other cast, the syntax is the type name in parenthesis.

Apologies if you already knew this.

> I agree - the girl's knowledge might be a net win, provided she doesn't go out of her way to use it.

It's only a net win if the price is right and the project requires such knowledge (in the case of C, mostly likely the trade-off would be a bad one, experience at that level comes at a steep price, fixing bugs due to a lack of knowledge about what happens 'under the hood' is expensive too...).

I agree. It's a little like a Java programmer knowing JVM bytecode: definitely not _needed_ but you'll be much better at understanding why (for example) some code structs are more efficient than others.

Knowing what happens when you fail to initialize a static variable may be useful for debugging when you (or someone else) accidentally fails to initialize a static variable.

Well, you can't fail to initialize a static variable, so maybe you meant accidentally initializing it to the wrong value.

Well, knowing the dark corners of the language is not useful "per se", but it allows you to say "I wouldn't write code like this" more often. And, consequently, it makes you NOT write "code like that".

Knowing what not to write and knowing what happens when you write it are two different things.

Indeed. The first is blindly following a dogma, the second is true knowledge.

An example: I have been taught to never attempt shifting the gear in a car before pressing the clutch. I accept this as a dogma, but I have no idea what would have happened had I tried really hard. When I asked "why", the only answer I got was roughly "the engine would break". Only some car mechanics / engineers have enough understanding to explain in detail what would have happened. They have knowledge, I'm following a dogma.

Actually, with enough experience with a given vehicle, it is quite possible to smoothly shift it without the clutch. When the engine reaches the appropriate RPM, you let off the gas as you take the car out of gear, smoothly and firmly shift to the next gear at the right time (a super-narrow window), and ease into the gas again. Unfortunately, if you get any of that wrong, you get an unpleasant (and somewhat damaging) grinding.

Your transmission is a series of gears with varying ratios of wheel revolutions to engine revolutions. When you upshift, your engine requires fewer revolutions to drive your wheels. When the no-clutch-shifter lets off the gas, the engine's RPM begin to fall. With the correct timing, the shift is performed during this drop in RPM such that the engine's current RPM matches the RPM necessary to drive the car at this speed in this new gear. This obviates the need for a clutch, since the engine and the rest of the drivetrain (for which the transmission is the link) are being manually synchronized: the shift is performed with a technique that keeps everything spinning at the same relative speed.

When you depress the clutch pedal, the transmission disengages from the engine, allowing you to freely shift without regard to the engine's machinations. When you let out the clutch, what typically occurs is that a carbon disk slips a bit before fully reëngaging, allowing the engine and the rest of the drivetrain to gradually synchronize. This is the "catch" that you feel when you let out the clutch.

To illustrate explicitly, let's say we're shifting from 3rd gear to 4th gear at about 30 MPH, and for this car at 30 MPH the engine must spin at 5000 RPM in 3rd gear and 3000 RPM in 4th. Without the clutch, you left off the gas and pull the car out of gear (taking it out of gear is a split-second after letting off the gas), the engine's speed (RPM) begins to fall as you pull the shifter into 4th, and just as the engine hits 3000 RPM (on its way down to 1000, the idling rate), you shift the transmission fully into 4th gear. With the clutch, you jam the clutch and shift, and the engine could be anywhere from 1000-4500 RPM when you let the clutch back out. The clutch slips a bit, allowing the engine to reach the appropriate 3000 RPM before it is fully engaged. Without the clutch, you have very little room for error.

IANACM, but I think car mechanics have a model in their head about the gears and rods that make up the shifter, but they certainly don't know off the top of their head which exact gear will break or bend when you try shifting from 2nd to 3rd in a 1990 Ford Focus.

I also ANACM, however I can guarantee you that it is impossible for any gear to break or bend under those conditions (the first model year for the Ford Focus was 1998).

Regarding such 'trivia that might come in handy one day', it is possible on some cars to shift gears without using the clutch, but you have to get the timing exactly right.

If you time it right the shift will happen from say to 2nd to neutral at one rpm (to neutral is always possible without the clutch), then you reduce the rpm until you know it will match 3rd gear for that speed (good hearing helps here) and then you can make the shift from neutral to 3rd without any force at all. The more 'sloppy' a gearbox the easier this goes.

As long as you don't force things you'll be fine, if you do force it you'll likely be greeted by expensive grinding noises.

On the classic 'beetle' and 'mini' engines I can do this without fail or any chance of damage.

Modern cars (read more expensive) I haven't tried.

Of course this is not what you're supposed to do but it's interesting when you have a 'junker' to play around with it until you can do it right.

"In real life, the boy may actually be a better programmer than the girl.”

I think in real life the boy will shoot himself in the leg without knowing the order of evaluation in C.

I'm worried that the girl will leave a loaded shotgun for someone else to shoot themselves in the leg by writing code that relies on order of evaluation rather than by using parantheses. The girl clearly knew her stuff, but I'd be much happier if she prefaced this example by also saying "it's dangerous to write code like this because...". I wouldn't want to work with someone who writes code that relies on all the features discussed in the C examples.

How would one write code that depends on order of evalution, instead of using parentheses? Where can you use parentheses that lets you write code that doesn't depend on order of evaluation? I think you missed something here because nothing about the example at hand has anything to do with the use of parentheses.

I'm actually worried the girl's going to shoot herself in the leg.

  void foo(void)
  {
    int a = 41;
    a = a++;
    printf("%d\n", a);
  }

She says 'a gets an undefined value' but that's not true at all. There are compilers that will look at that undefined function and omit the entire body, including the print.

It is extremely important to understand that undefined behavior can and will break everything, even if it appears to be behaving whenever you look.

Indeed. Rather than exploring the obscure standard corners, with a boring code snippet, one should better test that the candidate masters pointers, the pitfalls of implicit type casts, and that s/he can spot the most common traps of the language, etc.