Hacker News Reader

Comment by david-given | Hacker News Reader

Mmm. Be careful --- I've been programming in C for years, including frickin' K&R C, and I'd probably say something like A here (although instead of 'memory' I'd probably have said 'it points at whatever you set it to, what do you mean?').

The reasoning is: the code as written makes no sense; therefore it's incomplete. Obviously, then, it's not intended to be read literally, and is just an abbreviated portion of the real code. The first line just declares p as a pointer. The second line dereferences the pointer. The pointer assignment has been elided for brevity and is not relevant to this question.

That's an expectation impedance mismatch. I'm expecting you to want a high level description of how pointers work. You're expecting me to provide a blow-by-blow machine level breakdown of the instructions involved.

(Also, the blank line enforced by HN between paragraphs really doesn't help here.)

View on HN

This reminds me of the Google phone screen article that went around recently where the recruiter was reading off a sheet of answers and failed the candidate because the candidate gave answers which were too technically nuanced to fit what the answer sheet said. And is also why these kinds of things are a terrible fit for recruiting experienced-to-senior-level people.

I am developing a rule of thumb for this: the more pointedly in-depth your technical question is, the more likely you produce false negatives through obfuscation of intent. The grandparent's "what does this mean" question suffers particularly from being in-depth without stating it. Every CS student who learns C gets the high level treatment of pointers. But in many cases, their class does not proceed on to examine what this looks like in assembly code, except in a separate course devoted to ASM or compilers where it might be mentioned obliquely that such a representation exists. That is a relevant skill, but you have to ask for it. An easier way to get there is to ask how a C compiler turns a pointer assignment into executable binary, working backwards from the output. There are now degrees of success, since the candidate gets to discuss how compilers work if they're really engaged. But a basic answer can still capture the essence.

> The reasoning is: the code as written makes no sense; therefore it's incomplete. Obviously, then, it's not intended to be read literally, and is just an abbreviated portion of the real code. The first line just declares p as a pointer. The second line dereferences the pointer. The pointer assignment has been elided for brevity and is not relevant to this question.

No. The pointer assignment has been elided to see if anyone clues in that the pointer is, in fact, uninitialized.

The correct answer is "the pointer is uninitialized. Writing to it will result in undefined behavior, possibly even a SEGV."

I concur. Not to mention, this code wouldn't pass the automatic static analysis we use for all commits to our repository, so it literally would never come up as is. We turn on "warnings are errors" and turn on most warnings. I literally wouldn't think this code could compile (or at least get committed) as written, so would assume there was stuff missing for the sake of brevity.

It's testing to see if people understand C.

No, it's not omitted for the sake of brevity. The point is that if you can't find bugs in trivial code, you shouldn't call yourself a C programmer.

Reply on news.ycombinator.com