6 ms·
While knowing the standards makes you a better programmer, it's still bad programming practice to write non-excplicit, cryptic code. I think the boy's initial
by Maro 15y ago
While knowing the standards makes you a better programmer, it's still bad programming practice to write non-excplicit, cryptic code.
I think the boy's initial "I would never write code like this" response is spot on. I also agree with the boy's implied annoyance and "who cares what this badly written program actually does" stance.
These are fairly terrible interview questions. They test knowledge of standards and various obscure behaviour, but it's far more important what kind of code (readable, explicit, maintainable, simple, architected, commented, performant, bug-free, etc.) the person writes. In real life, the boy may actually be a better programmer than the girl. It's just not a good, comprehensive test.
Nevertheless the examples are fun, but I would never ask them in an interview. Interview time is precious and not to be wasted on stuff like this, unless you're interviewing for a compiler job...
EDIT: Most of the above applies to the first, C part of the interview. In the second, C++ part, the stuff the girl says is mostly basic knowledge that is useful on a daily basis.
- pwaring 15y agoI 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.
- mnutt 15y agoKnowing 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.
- astrange 15y agoWell, you can't fail to initialize a static variable, so maybe you meant accidentally initializing it to the wrong value.
- mquander 15y agoI 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.
- philh 15y agoI 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."
- sirclueless 15y agoSure, 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.
- pwaring 15y agoIf 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. :)
- zvrba 15y agoWell, 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".
- Maro 15y agoKnowing what not to write and knowing what happens when you write it are two different things.
- zvrba 15y agoIndeed. 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.
- Maro 15y agoIANACM, 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.
- msteinert 15y agoI 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).
- 0x12 15y agoRegarding 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.
- davesims 15y agoGood 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.
- deleted 15y ago[deleted]
- toksaitov 15y ago"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.
- screwt 15y agoI'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.
- SamReidHughes 15y agoHow 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.
- Dylan16807 15y agoI'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.
- astrobe_ 15y agoIndeed. 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.