←back to thread

Google's “Director of Engineering” Hiring Test

(www.gwan.com)
1764 points fatihky | 1 comments | 13 Oct 16 15:15 UTC | HN request time: 0s | source
Show context
lordnacho ◴[13 Oct 16 15:43 UTC] No.12701486[source]▶
I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing.

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.

replies(34): >>12701588 #>>12701606 #>>12701620 #>>12701625 #>>12701648 #>>12701659 #>>12701722 #>>12701725 #>>12701748 #>>12701796 #>>12701805 #>>12701854 #>>12701894 #>>12702003 #>>12702005 #>>12702106 #>>12702118 #>>12702186 #>>12702310 #>>12702312 #>>12702327 #>>12702439 #>>12702478 #>>12702496 #>>12702544 #>>12702566 #>>12702572 #>>12702655 #>>12702699 #>>12702757 #>>12702829 #>>12703332 #>>12706141 #>>12708605 #
tptacek ◴[13 Oct 16 15:55 UTC] No.12701606[source]▶
I knew all these answers too, because I was a developer in the 1990s.

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.

replies(9): >>12701685 #>>12701692 #>>12701960 #>>12702093 #>>12702100 #>>12702332 #>>12702334 #>>12702435 #>>12702610 #
1. ktsmith ◴[13 Oct 16 17:46 UTC] No.12702610[source]▶
What's bogus about his comment on stat() exactly. It literally returns an int and fills in the struct that it takes as a parameter. If he had no idea what it did he could check Google or the man pages which are going to give him some variety of the same answer such as the two examples below.

Linux:

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

    stat() stats the file pointed to by path and fills in buf.
Mac OS X 10.11:

    int stat(const char *restrict path, struct stat *restrict buf);

    The stat() function obtains information about the file pointed to by path.  
    Read, write or execute permission of the named file is not
    required, but all directories listed in the path name leading to the file must be searchable.
It may be pedantic but stat definitely doesn't "return" an inode. One of the problems with technical interviews like this is you often have no idea what the interviewer is really looking for. Some might just want to know what you would use to get the information about an inode and another might be seeing how you describe it as a test of your knowledge of pointers or something. Often it's impossible to know and that could have been easily a trick question where the right answer is "there isn't one but you can use stat to get this information as it takes a struct pointer and will place the information into that struct". Of course you know that better than most or you wouldn't have made stockfigher.