It's one thing to blindly apply a simple questionnaire without thinking about the answers that come back, and yet another thing to do it with a questionnaire that's doesn't even get stuff right.
For what it's worth, lots of other companies seem to use almost the exact same process.
On the other hand, the recruiter did not tell me whether I got the right answer (or I didn't miss any). It was pretty clearly a scripted initial phone screen with someone who wasn't a programmer.
Oh, and they didn't ask anything truly ridiculous like the QuickSort question.
The screener is the wrong person to walk down Pedantry Lane or Hexadecimal Packets Street and that's the sort of thing you save for the actual interview. But yes, I agree that it's shitty that the incentive is to answer for the test instead of the exact truth. (I wasn't extremely supportive of the interviewee once he turned slightly sarcastic and rattled off hexadecimal bytes instead of just saying "SYN" and "ACK," though.)
As an unrelated addendum, I'm intrigued by the following four things:
1) The author wrote a Web server and framework, G-WAN
2) I've seen G-WAN advertise itself questionably in the past w/r/t perf
3) gwan.com is powered by G-WAN
4) Under Hacker News load, the entire gwan.com domain is hard down
His response:
> in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge".
What do you think SYN and ACK stand for? Could it be "synchronize" and "acknowledge"? Moreover his point that knowing the bytes is more useful when you're looking at packet dumps is valid.
"in hexadecimal: 0x02, 0x12, 0x10".
Except that you did draw a conclusion.
Actually, this is a super-bad assumption, pre-screening questions, etc, are all public to google internally. There are no magic internal-to-recruiting parts to the questions, and they are in fact, listed as SRE pre-screening questions, so ...
returns a few hits, including:
https://www.glassdoor.com/Interview/Linux-system-call-for-in...
which lists the question as "system call for inode data" - which is importantly different from a system call to return an actual inode.
This post says something similar: http://gregbo.livejournal.com/182506.html
"There were some questions I just didn't remember the answers to, such as "What system call gives all the information about an inode?" and "What are the fields in an inode?""
(Argh, the blog post is down, so I can't compare some of the others, but several of them seemed to have been changed in ways that made the question itself seem wrong.)
((Thanks to leetrout below for bopping me on the head with the google cache. Next bit added thanks to said bop.))
Another one: The blog post lists "what is the name of the KILL signal?", but googling for: google sre interview questions kill signal
turns up this post on glassdoor: https://www.glassdoor.com/Interview/site-reliability-enginee...
Which lists the question as "What signal does the "kill" command send by default?"
That matches much more the answer SIGTERM that the interviewer was described as insisting on.
That suggests a few likely possibilities: (a) The interviewer misread the questions; (b) There was a horrible communication failure between the interviewer and the interviewee; (c) The interviewee failed to actually listen to the questions before answering.
I have no information with which to assign weights to those possibilities, but all of them seem more likely than "the interview questions themselves are actually this horrible" (they're not as broken as the blog post made them out to be. After writing this, I looked.)
I managed to find them and I don't work in recruiting, they are for SRE pre-screens. The guy misunderstood most of the questions which is why he failed and then worded them incorrectly on his blog, it wasn't the fault of the questions or the interviewer.
Also at the end the recruiters attitude aweful. Like what is that, he was reading answers from a paper, couldn't make valid arguments back to the candidate and at the end turns and says to the candidate "sorry my paper says you don't know this and that, and goodbye?"
A recruiter who was already giving the guy the wrong interview, and whose job revolves essentially around HR and sales, made mistakes in asking a series of technical questions.
An expert with decades of relevant technical experience misunderstands and confuses basic networking and system topics.
A person fails to read a question verbatim.
A person who has been the "smartest person in the room" for decades has an inflated view of his fluency on a topic and makes mistakes in his favor when he tries to reconstruct the questions from memory.