This looks like a typical pre-interview recruiter phone screen… they're looking for shibboleths that identify the candidate as a genuine computer person who took CS 101, and exclude candidates who spam every job with bogus CVs. I'd start every candidate with this screen, unless I personally knew them & was familiar with their technical ability.
> none of these are on or related to the "director of engineering" interview guidelines or sheets
They'd be internal to recruiting, so you wouldn't see them unless you were heavily involved (doing interviews and recruiting trips isn't being heavily involved). They're for any recruiter to use to quickly eliminate bogus applicants.
> Particularly, when one side presents something that makes the other side look like a blithering idiot, the
> likelihood it's 100% accurate is, historically, "not great".
You can just outright call him a liar… I'd expect this to be a fairly accurate report. It looks like the recruiter misused the screen; instead of eliminating obviously bogus candidates, they used it to eliminate a candidate who may or may not get an offer (and thus a commission). They should have proceeded to the technical phone screen stage. If the guideline on the recruiter screening is: drop anyone with <100% correct, then I think that's silly.
I'd hope it's not too typical, since four out of the ten official answers are wrong, and even one of the questions manages to be wrong. (Specifically, the "why is quicksort the best?" is just completely ridiculous.)
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.
I wouldn't be surprised if the recruiter just googled to find a list of questions and answers. This candidate probably isn't even on any official radar. The recruiter probably just uses this as a means to evaluate candidates before they officially call dibs on them. Google could very well be different since they do many things differently but recruiting has always been a sales position with everything it comes with, namely leads, quotas, conversions, etc.
I don't think that's what happened. The questions look too familiar to me, and I've been through the SRE-SWE interview process which is what the top-level comment talks about.
The problem is, once you have a crud ton of false negatives, people stop wanting to apply to work for you, especially when you get excluded via junk like this. And every false negative that posts about it online... well, this post is at +1363 right now?
That's part of it, but the other part is what you mentioned earlier--leads, quotas, conversions, and don't forget diversity initiatives, inexperienced recruiters, and the fact that the first part of the funnel has to be dirt cheap to work at scale.
For what it's worth, lots of other companies seem to use almost the exact same process.
They do seem typical; the recruiter asked many of those same questions when I interviewed for a SRE position back in about 2004. I particularly enjoyed the bit count; I went back later and confirmed that the bit swiggling approach was faster on the machines I had handy. Large lookup tables have poor cache behavior.
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.
I was asked the "what syscall returns an inode?" question (and agree with DannyBee that this is extremely similar to my successful SRE screen) and I answered stat() without the clarification because I understood what the screener was doing and the parameters in which she was operating. That context on how phone screens work is missing from this transcript, but it's also unfair to expect that sort of context from a candidate because not every interviewee is familiar with the standard Google style tech interview.
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
No software can perform better than the hardware allows it to. End of argument. Even if you make 100% optimized ASM tailored to the hardware and workload, and you can still kill it hard with enough requests. For all we know he hosts the website on a free tier of whatever to show how well it performs. It being down doesn't tell anything useful other than the current workload exceeds its capabilities.
> 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.
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.
They're bits. SYN can be represented as 0x02, ACK can be represented as 0x10. 0x02 BITWISE-OR 0x10, ie SYN BITWISE-OR ACK or 'SYN-ACK' colloquially, is 0x12.
Those are just flags, the message contains much more than the flag. Therefore it is wrong to say that they just send the flags and that the flags are equivalent to SYN and ACK.
Although I can see why it's tempting to poke fun at this situation, his site could be down for any number of reasons not directly related to the quality of the code he wrote for G-WAN.
"They'd be internal to recruiting, so you wouldn't see them unless you were heavily involved (doing interviews and recruiting trips isn't being heavily involved)."
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 ...
"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
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.)
Anyone asking a question should be qualified to interpret the answers in context. If they don't, use a multiple choice quiz or something instead.
These questions/answers are just ludicrously out of sync.
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.
The recruiter misunderstood the answers and or he is not qualified to ask those questions. Usually when you ask someone something that is not literal as in "what is 1+1?"
You can't expect them to be literal.
Questions like: Why Quicksort is the best sorting method?
Guy gave very good answer showing that he has perspective and he is able to make a valid argument.
The recruiter on the other hand just read the paper and completely disregarded the fact that the person he is trying to recruit is a valid candidate.
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?"
No, I meant that the interviewee misunderstood the questions/answers given by the recruiter and thus misrepresented them when he wrote the blogpost. Since he couldn't even get the questions right I highly doubt that he gave a correct representation of the recruiters attitude as well.
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 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.
