This strikes me as an entirely trivial point, the meaning of the question was pretty clear. It wasn't "what is the literal return value". Many APIs will return error codes, and people still talk about them as "returning" certain values colloquially. Of course, if the OP's answer would've been "it returns an error code :) but I assume you're talking about..." I would think that's fine.
Btw, that is the only thing I really disagreed with OP on, the rest seemed just ridiculous.
There's a precise distinction, and thinking about it as "returning" anything other than an error code is chummy human thinking rather than the sort of precise knowledge the test was (supposedly) looking for. The question was actually worse than asking "I'm thinking of a number between 1 and 10, what is it?" because rather than applying a random filter to candidates, it punished the candidate for having precise knowledge.
The difference is memory management, completely different. Don't ask me for a function that "Returns" something in a technical interview and when I call you out on it say I'm wrong, when I'm not.
It's a technical interview, the question should have been technically correct. "What function passes by-reference copies of inodes?"
My worst offense of this was for a linux admin position when asked from another abmin about how to list connections on a machine. My answer was "lsof -i, since I've found it's easiest to pull granular information."
"lsof just prints open files... you would use netstat, not lsof."
I tried correcting him, but he wouldn't listen and ended the call soon after.
Most people don't know that lsof works into two modes- the typical one is to run it against a process ID. The rarer one is no args, which runs it against everything on the system. however, I observe that lsof needs to run as root to print the same information that netstat -tanp returns for a reglar user.
Yeah, you're right about needing root (edit: for processes not owned by the current user). Though, if you have the access, it's a very, very worthwhile tool to learn:
~ $ lsof -a -n -c chrome -iTCP:443 | head -2 #sanitized output
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chrome 1234 me 12u IPv4 12345 0t0 TCP 127.0.0.1:12345->127.0.0.2:https (ESTABLISHED)
Yes, but we are all chummy humans with our chummy human thinking :) We are generally gifted with the ability of shorthand, context, and understanding that surpasses a purely technical understanding of words, and this is exactly the kind of situation where that helps.
I personally wouldn't want to work with someone who wasn't able to understand what I mean (in such an obvious case, at least) and wasn't able to answer to that meaning.
(Of course, I'd also personally prefer someone who would point out that this is inaccurate, but do so in a charming and off-hand way, to make me feel comfortable. A high bar, maybe, but for a director that's definitely a bar they should clear).
On the other hand, you are interviewing a programmer. Their daily life revolve around technicalities where the difference between returns and fills matter a great deal. Expecting them, all of a sudden, to throw that out of the window and parse technical questions in a hand wavy way is ridiculous.
I can't disagree with you enough. Engineers should always strive to be as clear as possible about what they're doing. The word "return" has a precise meaning in the C language. If the recruiter was unaware of that, that's their bad entirely.
Actually, OP replied exactly as he should because after the first few exchanges, you can tell how anal the interviewer is and as such you have to answer accordingly. Some easy going interviewers might say that its about right, some might say its technically right, etc.
Remember, you have to walk through the interview thru OP's mindset and how he took into consideration the interviewer's analness.
Btw, that is the only thing I really disagreed with OP on, the rest seemed just ridiculous.