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 deliv

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.