Google's “Director of Engineering” Hiring Test

It's a bit strange to have someone non-technical interviewing a techie. You end up with stupid discussions like the one about Quicksort. If you point out qs is one of several things with the same big-O, you'll probably also get it "wrong". But the real problem is that a guy who is just reading off a sheet can't give any form of nuanced feedback. Was the guy blagging the sort algo question? Did he know if in detail? Does he know what the current state of research on that area is? There's no way to know that if your guy is just a recruiter, but I'm sure even a relatively junior coder would be able to tell if someone was just doing technical word salad.

I wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face.

There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part of being a practicing programmer; knowing how to find out is.

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.

    These functions return information about a file.