Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

691–700 of 969 posts

Re: Google's “Director of Engineering” Hiring Test

#691
post #598

Earlier quoted context omitted.

I agree. Why the hell would you ask someone at that level basic questions like fizz buzz? It's absurd. I also tend to shy away from asking coding questions in interviews, they don't tell me much about aptitude for critical thinking and culture fit. Skills can be taught but culture is much harder. ... But I'm not saying to throw in some questions that don't prove that they are actually competent, just be casual about…

My company has been giving the fizzbuzz for students applying for internship, with any language they wish and extra for style points. The results speak for themself. All the good applicants do it in no time, without hesitation and give a perfect answer and usually some style points on top. The ones who have second grade coding skills have always something wrong with it. It's a good 5 minute test whether someone can c…

How do you know the people failing your interview process have "second grade coding skills"? The fundamental challenge with evaluating interviews is that companies don't hire people who flunk interviews - so there is no easy way to reliably measure the false negative rate. Does fizzbuzz ability correlate with coding ability? Maybe, but you'd have to hire people who fail fizzbuzz to definitely answer the question. I know that I use google extensively at work - interviews don't allow you to use search.

Re: Google's “Director of Engineering” Hiring Test

#694
post #601

Earlier quoted context omitted.

Popcnt isn't particularly well optimized in most micro-architectural implementations.

Is it? It looks like on most recent Intel CPUs, it's 3 cycle latency, 1 cycle throughput on a 64-bit register. A 8-bit LUT solution is going to less than 16-bits per cycle on any recent Intel/AMD CPU (maximum of two load ports).

Hmm, much better than I remember. I guess this goes a long way to explain why this wasn't always seen in practice: http://danluu.com/assembly-intrinsics/

Re: Google's “Director of Engineering” Hiring Test

#695

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…

Medical Recruiter: "What are mitochondria?" Applicant Doctor: "They're double membrane-bound organelles found in all eukaryotic organisms, commonly between 0.75 and 3μm in diameter, that generate most of the cell's supply of adenosine triphosphate" Recruiter: "No. They are the powerhouse of the cell".

Except that, for some reason, medical professionals don't have to put up with this shit. But we do.

Re: Google's “Director of Engineering” Hiring Test

#696
post #385
post #338

Earlier quoted context omitted.

How can you imagine Google being totally right here? The disconnect between the questions being asked and the interviewer's lack of knowledge made the interview a waste of time no matter WHAT role they are interviewing for. Take, for example, the sorting question. "Why is QuickSort the best sorting algorithm?" The answer being looked for was, "It has the best Big O." And this is wrong. Its average case is O(n log(n))…

I can imagine Google being totally right because I can imagine the interviewee not accurately remembering the conversation here. (I expect, for instance, that he did not write down the interview as it was happening.) In fact, conditioned on the assumption that Google is right that this guy's experience is better suited for SRE than director-level, it is pretty likely that he did not understand the questions being ask…

> they asked another question here with a very small but important phrasing difference: "What is the signal sent by the kill command" instead of "What is the kill signal". If you make that change, the interviewee's answer of "SIGKILL" becomes wrong, and the interviewer is right to insist on SIGTERM (which would otherwise make no sense).

But... the kill command is the command to send arbitrary signals. It sends them all.

Re: Google's “Director of Engineering” Hiring Test

#697

FWIW: As a director of engineering for Google, who interviews other directors of engineering for Google, none of these are on or related to the "director of engineering" interview guidelines or sheets. These are bog standard SWE-SRE questions (particularly, SRE) at some companies, so my guess is he was really being evaluated for a normal SWE-SRE position. IE maybe he applied to a position labeled director of engineer…

IE maybe he applied to a position labeled director of engineering, but they decided to interview him for a different level/job instead.

A "different" job, several grades lower in responsibility (and pay). Without in any way prefacing him, beforehand.

Is that the way things usually work in the Google hiring process?

Re: Google's “Director of Engineering” Hiring Test

#698
Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function calls, how the TCP/IP stack works, and what big-O means to eventually qualify if you are interviewed at a later time. Good luck, bye.

Whether he got interviewed for the wrong position by mistake or not -- how can Google begin to think that putting technically illiterate people in charge of "vetting" obviously highly senior people... could ever possibly be a good idea?

Re: Google's “Director of Engineering” Hiring Test

#699

Earlier quoted context omitted.

First, it is definitely standard process to tell him (if they didn't, that's a definite failure). Again, remember you only have one side of the story here. I like to try to gather facts before assuming things. IE Ready, aim, fire, not fire, ready, aim. Admittedly more difficult in this case (and certainly, i have no access to it) Second i'm going to point out a few things: Experience may translate into wisdom, it may…

> SRE is not an ordinary site maintenance position by any means Then why ask about the nitty gritty details required by maintenance personnel as part of the screening process - things I would rather have my high level employees looking up rather than relying on a possibly faulty memory. > Judging an entire recruitment process based on one side of a story from a person who's clearly upset about an interview, and 3 sen…

So, as someone who went through the process and got through it (so is less inclined to hold a grudge):

> Then why ask about the nitty gritty details required by maintenance personnel as part of the screening process - things I would rather have my high level employees looking up rather than relying on a possibly faulty memory.

AIUI you can get easily 5 or more of the pre-screen questions wrong and still proceed to the next stage, depending on your experience and how wrong you are. The point here is not that you know each and every one of those things, but to show that you are, in general, knowledgeable enough to spend Engineer hours on.

And your judgement of these questions is seriously impaired by the fact that they are written down wrong. I assume, that the author of this post has written down a rough transcript from memory and as such it's colored by their own (mis)understanding of the question and whatever got leaked from memory in the meantime. The questions he wrote down are, at the very least, not verbatim the ones from the checklist given to recruiters (and there is a strong emphasis on reading them out verbatim there, so I consider it relatively unlikely that the recruiter didn't do that).

> It's formed of the dozens of posts that appear every year about how someone who seems qualified is turned down for spurious reasons like "being unable to reverse a binary tree on a whiteboard". It's what makes this particular post so believable - it fits the stereotype.

Exactly. You are reading "dozens of posts every year" from disgruntled interviewees who got rejected and are pissed. On the flip side, a quick internet search will tell you that Google gets on the order of millions of applications each year, meaning you don't hear from >99.99% of applicants.

There is also the widely advertised fact, that the Google hiring process accepts a high false-negative rate, if that also means a very low false-positive rate, so it is to be expected that a good percentage of qualified applicants still get rejected. It is thus also to be expected, that you hear from some of them. Meanwhile, again, you are not hearing from the thousands of qualified applicants that do get accepted each year. Because an "I interviewed at Google. It was pleasant, everyone was really nice and they got me a good offer" blog post won't draw a crowd on hacker news, even if it was written.

> How about the responses from your own employees which are pointing out that they see the problem too. Are they being unreasonable?

Let's not ignore the responses from Employees that don't think there is a problem.

From reading this post, I'd say a likely reason for the rejection is, that this person wasn't being particularly pleasant. Frankly, he comes of as kind of an arrogant prick. And, as a general rule, engineers at Google, just like everyone else, don't particularly like having unpleasant people on their team. And I also believe this post has gotten enough upvotes, that someone will look into the situation to see what went actually wrong here.

Re: Google's “Director of Engineering” Hiring Test

#700

Earlier quoted context omitted.

First, it is definitely standard process to tell him (if they didn't, that's a definite failure). Again, remember you only have one side of the story here. I like to try to gather facts before assuming things. IE Ready, aim, fire, not fire, ready, aim. Admittedly more difficult in this case (and certainly, i have no access to it) Second i'm going to point out a few things: Experience may translate into wisdom, it may…

>First, it is definitely standard process to tell him (if they didn't, that's a definite failure). Again, remember you only have one side of the story here. "Standard process" is what actually happens in the real world. Alas, standard process is to not tell him. >But everyone in this entire thread seems to be making snap judgements without a lot of critical thinking. That makes me believe a lot of people here have a…

> "Standard process" is what actually happens in the real world. Alas, standard process is to not tell him.

Inferring what's standard from a sample size of 1 (which is ~0.0001%) is very questionable.

> Still, you spend all your effort on saying why for example this guy's patents mean nothing and he's likely incompetent.

That is not at all what they where saying. They where saying that patents aren't conclusive evidence of competency.

Post reply on HN