Hacker News Reader

Comment by adekok | Hacker News Reader

> I'm a senior dev with 10+ years of experience. I don't do interviews that require a coding portion. It's a little insulting to me.

I've interviewed multiple people with such experience who knew next to nothing about C.

    char *p;
    
    *p = 'c';

Q: What happens here?

A: The character 'c' is assigned to the location pointed to by 'p'.

Q: What does 'p' point to?

A: Memory

Q: Can you be more specific?

A: To dynamically allocated memory. By the compiler.

<sigh> Get out.

The conversations are a bit longer that that, but that's the short summary. Some people can operate in a corporate environment, but have literally no idea how to use the language they've "programmed" in for 10 years. I say "programmed" because I have no idea what they're doing, but it isn't using the language they claim to be using.

View on HN

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.)

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.

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.

> 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."

Sounds like corporations should either:

1. Lower their standards and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering. Software is in a state where you can be a non-engineer and still write performant code, or at least satisfactory work, thanks to the other people who actually write those libraries. Entire successful products, even companies, have been launched on less-than-optimal code.

2. Actually spend time cultivating their engineers, and allow them to gain access to deeper understanding of CS, by giving them the chance to work on non-trivial problems. Maybe stronger standards need to be built into the industry as a whole, engineers should be encouraged to take a regular coding challenge outside of work, to ensure that they still remember their fundamentals. Or at the very least, they should be assigned work by the companies that is more than API gluing.

Either way, it seems unfair to place the entire blame of a candidate who has 10 years of actual development experience for having the wrong type of experience. I'm sorry, but that wrong type of experience could still make deadlines, launch products, and bring value to companies.

Either be open and transparent about your industry requirements, and give engineers a chance to live up to them, or accept that technology has advanced to a point where people can "program" for 10 years without knowing- or remembering- the fundamentals. And at the end of the day, isn't that the abstraction and convenience we're pushing for?

Also remember that there's a difference between a developer who's been working on say Rails apps ten years, and one who's been working on compilers or embedded code.

As far as the examples you brought up: did those candidates actually develop in C for ten years?

>>and admit that many, many coding positions are API gluing and tinkering with libraries to fulfill business requirements, and not actually about engineering

Sounds like the True Scotsman Fallacy.

Why isn't tinkering with libraries and glueing code "actual engineering"?

Do you think engineers of other professions invent everything from scratch? Or are they given a set of tools, materials and requirements and figure out how to accomplish the task?

Yes.

People can put anything they want on their resume. I got a resume once where a person said they were working at company X from 1995 to 1999. I knew it was false because they sat next to me at company Y in 1997 for three weeks before disappearing, they didn't even call to say they were quitting. Who knows what would have happened on the company X reference check if we had bothered to get that far.

By the way, half the startups I worked at went under or were acquihired by companies which did three more mergers, so who knows if my HR records exist. Most references I know of are chats with someone claiming to be an ex-manager or colleague.

The phone screen questions I ask, and the initial in-person technical questions I ask have a very low bar. Over half the people I talk to can answer them. I ask them because I have seen multiple people with seemingly perfect resumes who are unable to answer simple questions.

Speaking of references, I don't understand people who are fine giving three references, but are bothered by technical questions. For me it's the opposite. I'd rather not call three ex-bosses, make sure I have their current contact info, and ask for a favor that I can use them as a reference for a job I might not even get. Asking a technical question of me that I may or may not know is much less of a hassle.

Hehe, I once had a manager, who was also a programmer, asking me about the difference between new and malloc. He wasn't testing me, I was working at the company. His question was something like "Isn't it that if you use new you get virtual memory but with malloc you don't get virtual memory?"

Was he even a C programmer? I don't know if it matters if a Ruby or Java programmer knows new vs malloc.

Well, he had somehow managed to write an awful lot of C++. Most of the code base at that company was in old school C++ (huge monolithic classes). Since he was one of the founders I can only assume C++ was his main language.

...be aware that in Windows, there are two main ways to allocate memory: HeapAlloc(), which comes from your process heap and is equivalent to Posix malloc(), and VirtualAlloc(), which comes from the kernel and is the equivalent to allocating anonymous pages with mmap(). (Windows malloc() usually wraps HeapAlloc().)

So he's not necessarily completely wrong. If he's used to a system where the default C++ allocator uses VirtualAlloc() but malloc() still uses HeapAlloc(), then referring to memory allocated from VirtualAlloc() as 'virtual memory' makes sense, in a specialist weird-windows-terminology kind of way.

('Virtual memory', here, having nothing to do with virtual memory in the Linux sense.)

In Windows (as in most OS:es), any memory you allocate in user space is virtual, end of story.

Ok, not really end of story (I just said that because it's mostly true). You can allocate physical memory from user space but that is for very specific purposes and your general purpose CRT allocator (whereas new or malloc) will not be doing that.

Also (last I looked) the MSVC CRT "new" uses malloc.

Now I'm curious how you'd like to see this question answered, or how you would answer it yourself ?

The code snippet shows a bug, p is an uninitialized pointer. The behavior is undefined. Theoretically it could point to some valid memory, but saying that it points to dynamically allocated memory definitely implies a misunderstanding.

Which is why I would disagree with this example. I suspect the interviewee's answer was due to a misunderstanding rather than a lack of knowledge. For example, change the first line to:

    char *p = ...;

Now, the implication is not that p is uninitialized, but that it's not important what its value is, which is likely what the interviewee thought. As for dynamically allocated memory, that's what pointers are used for the vast majority of the time, right?

I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"), because the most fallible part is likely to be human communication.

To be fair, this is an absolutely essential thing to be a stickler about in C. It's a dangerous language, and placement of semicolons and recognition of unititialized variables should be burned deep into the psyche of an experienced C developer.

This is why people advocate for alternatives like Rust where the compiler can be precise on your behalf. But as long as C is still in use, its practitioners need to be exceptionally pedantic with their code.

That is true, but my point is that in the context of an interview, the purpose of "char *p;" might simply be to indicate the type of p, but not necessarily to indicate that it is uninitialized. It's hard to know what the interviewee thought without asking them.

Though it might be a good thing to say "well, p is uninitialized," it might also come across as obnoxious if that wasn't what the interviewer intended. So it comes down to guessing which response the interviewer is looking for.

I do not know how to convince you as others have failed, but I really believe that trying to understand the correct understanding about the memory allocation was the essence of these questions.

The final answer that the memory was dynamically allocated by the compiler is as wrong as it can be.

If I saw this code then my first reaction was that this code probably will produce a segmentation fault in the best case scenario. Well, that was after I verified that this is not some pointer usage question, as I am not an experienced C developer.

> the purpose of "char * p;" might simply be to indicate the type of p, but not necessarily to indicate that it is uninitialized.

It's C code. Your interpretation is not the one used by the compiler.

The point was to catch trivial bugs in code. In this case, the interview didn't.

That's a very gracious interpretation I think. The snippet illustrates a kind of trivial bug (uninitialized variables) that should really jump out at anyone who is used to writing C code. (And I think it's clearly C code, and not pseudo-C code.)

In fact, it will generate a compiler warning (with -Wall).

The conversation (which OP said was condensed) clearly demonstrates that the interviewee does not understand that the pointer is uninitialized.

To suggest that the interviewee confused it with

  char *p = ...;
  *p = 'c';

makes no sense, because he said the memory was dynamically allocated 'by the compiler'.

Also it would still matter what ... is here.

For example if it was a constant initializer like "string", then the memory would be statically allocated and write-protected.

If on the other hand it was a call like malloc(1), then you would expect some error checking to see if malloc failed.

It's actually a pretty neat little snippet.

As I responded to another commenter, the purpose of "char * p" might simply be to indicate the type of p, not necessarily to indicate that it is uninitialized. If you wanted to indicate the type of p, what would you write instead?

Regarding pointers, though, you have a point that char * is commonly used for statically allocated strings. I concede that it's fair to criticize the interviewee for saying the memory was dynamically allocated (by the compiler??), though I don't know if that rises to the level of "Get out."

> If you wanted to indicate the type of p, what would you write instead?

Then you would just write it as a function like this:

    void foo(char *p) {
        *p = 'a';
    }

> I would react to stories like this with skepticism, whether told by the interviewee or interviewer, especially when accompanied with a pretentious attitude ("Get out"),

Do you know how to read? Apparently not. I said explicitly that he conversations are a bit longer that that.

My comment was described as a short summary to illustrate a point. Instead of taking it at face value, you've read all kinds of nefarious emotions into it, and read magical interpretations into the technical portion, too.

This is called "projection".

p contains whatever happens to be on the stack at the position assigned to it by the compiler. Basically that means that p could point anywhere, so by assigning a char 'c' to a "random" address the best thing that could happen is a GPF/segfault. Most likely you'll spend weeks looking for a multitude of weird bugs that seemingly appear at different places out of nowhere, only happens sometimes and never in debug builds.

Yay, the joys of uninitialized variables!

It could point anywhere, but the question here was where it does point to.

And that's a remarkably unsuited question for a coding interview as it's going to depend on which compiler you use, which flags you have set, and whether the declaration is inside the same function as the reference. The C FAQ (when there was such a thing) used to contain a whole section on things like this.

As a conversation starter it could perhaps be useful, if you can phrase it suitably. My own experience is that trick questions posed as if they had a singular answer will do strange things to nervous people. It's just doesn't tell you much.

If I had this question dropped at me, my hunch would be that the interviewer had a slightly inflated idea of their own knowledge of the language and would likely not take kindly to being taken down. That might well colour my take on the answer. It's not always rewarding to argue minutiae.

I'm not a developer and I think the question makes sense. I would have given a similar response to what amag wrote, although I would have skipped this bit: "Most likely you'll spend weeks looking for a multitude of weird bugs that seemingly appear at different places out of nowhere, only happens sometimes and never in debug builds."

It's pretty clearly a conversation starter and there are lots of valid ways to answer the question.

> If I had this question dropped at me, my hunch would be that the interviewer had a slightly inflated idea of their own knowledge of the language and would likely not take kindly to being taken down. That might well colour my take on the answer.

If the interviewer responds poorly to this kind of answer then I don't want to work there anyway. Also, this kind of answer is not "taking down" anyone.

I think it's a fine question. "Q: where does it point to? A: that depends," and move on.

> but the question here was where it does point to.

No, the question was "what happens here" and the obvious answer is "you write 'a' to an undefined location, likely segfaulting". Since the candidate failed to spot this a hint was given hoping that the candidate would realize that the pointer didn't point at a valid location.

This answer explains the real issue. The problem is the question is asking the person to find the bug in the code, but the way it's asked is in a way that would make someone feel like a freshman in college.

I would say that an experienced C developer would blurt out that there is a bug in this code as an first reaction.

Bugs like these are one reason why we can not have the nice things on Earth, and an experienced C developer should notice them even when not looking for a bug.

Well, that is at least my impression, as I am not a one, it is just based on my experience with the language.

Pointer is not initialized, program will crash.

I don't understand your comment. He says he thinks the coding portion is nonsense and your reply is you have discussions about C code snippets. The two things are very different. What you are describing isn't a coding exercise.

As one who claims to know C on my resume, but I too am a < 3 month novice, lemme try to answer this one.

You declare some pointer and give it whatever value 'c' is?

I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh.

    char *p;

p doesn't point to anything[0]. You have declared a pointer to char but not given it any memory to point to. It is uninitialised.

    *p = 'c';

So what are you dereferencing here? You can't dereference something you haven't initialised.

[0] well it might point to something, it is up to the compiler as it is UB.

Edit: btw if you could not answer this very simple problem please do not advertise yourself as a C programmer as you are not yet. Learn C and then advertise yourself as a C programmer.

Yeah, one more thing. C and C++ type languages where you have to manage memory allocation are a different kind of intellectual challenge than languages like java or python. It takes a certain amount of try and failure and intellectual carefulness to get the ability to write trustworthy code. Just keep going at it. And be careful not to call yourself an expert c programmer, even after you get basic fluency. That's usually a sign that someone is not a great programmer in my experience :-)

> I probably would have gotten the question wrong too and just saying "Get out" is kind of harsh.

If you can't do that, you don't understand pointers. If you don't understand pointers, you're going to write really buggy code.

I've never told someone to leave an interview early. That's a bit unprofessional in my view. But I certainly wouldn't hire a C programmer who doesn't understand pointers.

Get out would be rude. If you interview a lot of people who say they are programmers, you get people who can't do anything sometimes. It is frustrating perhaps but that's no reasonable way to treat people.

Back to the question. In C or C++ the pointer is pointing to a memory location. If you don't set it to something (ie no malloc, or assignment, then it is uninitialized and you can't use what it points to. It is essentially a random number. Looking at a random memory location "(* p)" could likely crash your program, but it won't be anything useful that you should use. So when you say "* p" = 'c'; you say overwrite the memory location (which is randomly chosen) with the ascii code for the character 'c'.

Side note - the surprising markup language here doesn't let you use asterisk p directly, you have to put a space in I just discovered.

Reply on news.ycombinator.com