Google's “Director of Engineering” Hiring Test

The question was what function "returns" an inode.

Those functions return a error code, you pass in a stat structure and the function populates that structure.

He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code.

To me that is a big difference...

int lstat(const char path, struct stat buf);

vs stat* lstat(const char *path);

2 completely different functions.

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.

Yes, but the recruiter should have said "oh, you're technically right (the best futurama), next question".

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.

In C, what stat does is how you return multiple values from a function.

lstat has the same signature as stat: it passes the stat structure back through an output pointer.

But not if you're a literal lunatic who thinks that because you literally used the word return with an error code that's what it returns. And. Only. That.

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

I think the problem was that he didn't update his knowledge about what an inode is after the interviewer told him. He still thought it was an integer value, as opposed to a metadata structure. If inode meant inode number, it works be reasonable to assume there was a function that would return it.

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.

I never received a call back.

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

To be fair, the rest of the questions were demonstrably pedantic, and I would completely expect a question like this to be on the bill of fare:

   Q: What does lstat return?
   A: A struct
   >> Wrong, it returns an error code

That type of technical specificity about what well-known functions return is absolutely something I've heard people use as an interview question. Knowing it returns an error code (rather than the value you want) seems like a good indicator of "has actually coded in C" (whereas many other languages return the value you want and raise an exception if it had an error).

Here's the first sentence of the DESCRIPTION section of the stat(2) man page on my Linux systems:

    These functions return information about a file.

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.

>In C, what stat does is how you return multiple values from a function.

IIRC, you can return structs from functions in C. You have to access the values in the returned struct with dot notation, of course, like point.x .

Pre-ANSI C may not have had this, but later, it did. Remember reading it in the 2nd (ANSI) edition of the Kernighan & Ritchie C book, and also used it myself in some programs.

https://www.google.co.in/?q=can+you+return+a+structure+in+c

Edit:

Might want to consider the cost of copying, depending on the perf requirements, size of the struct, whether the function call is in a tight loop, etc.

Somebody sack the writer ;) - so, OK, I doubt I'd argue the toss if it were an interview situation. But when writing a comment or documentation I think I'd take inspiration from the documentation for either of these two fine systems.

OS X: (OK, so I lied about the "fine" part)

    The stat() function obtains information about the file pointed to by path

Windows, here the VC++ CRT - fantastically poorly described, if you ask me, though of course you shouldn't be using any of this POSIX shit on Windows, so if it confuses anybody enough to make them go and find FindFirstFile then it can only be a good thing:

    Get status information on a file

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.

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)

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.

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.

returning multiple values was the key part of the sentence