Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

721–730 of 969 posts

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

#721

Earlier quoted context omitted.

> There's another measure I use to measure the quality of their hiring process. The output. Namely the track record of products Google has developed in house in the last 10 years. That's a poor metric to evaluate the rampant complaints about a high false negative rate. I don't think that many people are disputing that the people who do get hired are qualified most of the time.

When the in house engineers come out with products like Wave and Glass while things like Maps and Android are purchased you have to wonder.

Not sure what you're saying here. Wave was great technically; the market fit just wasn't there.

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

#722
post #368

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…

So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.

They really don't. I have been called by one of their headhunters recently who explicitly refused to tell me what sort of position I would be interviewing for. He told me that:

"That is not how we work. We will evaluate your abilities and then, if you pass, offer you a position on a team that we deem best fitting your skills."

Needless to say I have thanked him for his time and declined. I am not going to fly to another country to be grilled with stupid coding interviews only to be offered an entry level job on a team I am not interested in.

Another such thing was an invitation from Amazon's HR for an "accelerated testing session" where I was expected to go for a full day of coding tests (together with many others) and then they would pick who they invite for real interviews later where you may learn what sort of position they might offer you. Again, no idea what position/job you are interviewing for and wasted entire vacation day - for their convenience. System clearly targeting 20-somethings straight out of school. No, thanks.

The questions from the original article are familiar - but these are often external staffing agencies doing these pre-screens today. Google used to do it in-house with actually technically very competent HR staffers (I have done a few phone calls with someone in their California HQ back in 2002ish), but now if I get contacted by them every now and then it is always an external headhunter.

The staffing agencies employees tend to be very technically incompetent. Basically, they often have no idea whatsoever about the technical requirements for the position they are trying to fill. They only match keywords on the CVs in their database (often LinkedIn profiles, etc.) against the keywords in the job description, then they spam everyone that matches with an excited mail about having a "perfect match job". The matches are usually on the completely generic stuff like "C++", "Python" that everyone has on their CV, so in most cases the "dream job" is anything but - in a field the person knows nothing about or is not interested in.

I have been literally hounded for weeks by a headhunter once for a position that I had zero qualification for (Windows/.NET stuff - I was mostly Unix guy back then). It finally turned out that she wanted me only because I spoke/understood the Czech language. And she fully expected me to move to a "sweatshop" that company had in Czech Republic, trying to do a job I knew nothing about and paying less money that I had as teaching assistant at a university at the time. Some people are just nuts.

The phone screens are the same story - the headhunter has a script provided by their client with a bunch of keywords they are looking for in the answers. They are basically playing bingo with the candidate's answers, ticking off the "correct" keywords. Don't expect them to actually understand what they are asking. They can't - this week they are recruiting a Google engineer and next week they would be trying to fill a civil engineering position and a week later perhaps a chemistry lab technician.

I believe this is exactly what happened here. I have been in a similar situation before myself (not with Google). The hiring managers are complaining about how hard is it to hire talent, but why are they then wasting everyone's time with incompetent HR agencies, pointless phone screens that filter out even good candidates and stupid coding tests. Ask for references (I will be happy to provide), ask to see some code at the interview, check my public code (Github for ex), hire for a trial period. But give me a break with this ridiculous testing/screening nonsense. Nobody else except software engineers seems to have to put up with this type of crap.

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

#723

Earlier quoted context omitted.

> "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 eviden…

No, the policy/process DannyBee references is fiction. What's standard is what happens in reality. I'm clearly not talking about statistics. For your second point, DannyBee focuses his efforts on discrediting this seemingly exceptionally qualified candidate, never yielding an inch from his position that Google is exceptional and can make no mistakes.

> What's standard is what happens in reality.

Infering what is "reality" from a sample size of ~0.0001% is clearly ridiculous. By that logic, it would be "standard" to be born a conjoined twin. Actually, it would be 10x as likely as what "standard" is.

> I'm clearly not talking about statistics.

You might benefit from doing so, though. It might help you realize what nonsense you are saying.

> DannyBee focuses his efforts on discrediting this seemingly exceptionally qualified candidate

No, this is factually incorrect. Repeating something factually incorrect doesn't make it more correct.

> never yielding an inch from his position that Google is exceptional and can make no mistakes.

You either can't or won't read. They very clearly acknowledged the possibility of a mistake several times in each post they made.

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

#724
post #620

Earlier quoted context omitted.

"The goal of a fingerprint hash is to convert an input space of "large" values to an output space where the output space values are much shorter- typically fixed size and two similar input values have effectively random outputs" But this is also the goal of non-crypto hash function like those used in a data structure no? Basically mapping a large space of inputs to a smaller space of outputs. I would say the cryptogr…

both types of hash convert an input space to an output space where (typically) the input space is much larger. What matters is whether similar inputs get mapped to the same output. For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash, although those are expensive so you want a cheaper approximation, which is exactly what finge…

"For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash"

That's what I was trying to say:

"a tiny change in the input causes a substantial change in the output."

But I probably didn't articulate that very well. I think we are saying the same thing.

You mentioned:

"The problem is that as the input values counts approach sqrt(output value size), you're going to start getting collisions"

Can you elaborate on the significant a square root here? Does this relate to the load factor?

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

#725

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…

Having only seen the candidate's paraphrase of that conversation (and never having worked for or interviewed with Google), I would STILL be inclined to give that candidate a thumbs down. To solve difficult technical discussions, it's important to be able to restate the other side's arguments in the light most favorable to THEM , while the candidate was entirely focused on paraphrasing the interviewer's argument in th…

So what you want to see from the author is a Mao-era self-criticism stating why Google were 100% right in rejecting him.

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

#726
I am doing neither of those things. I said it was tempting, because it puts things I've read about G-WAN into perspective (the claims I saw some time back when I was shown a heads-up versus nginx were questionable, and it's an interesting data point). That's why it's an unrelated addendum, and it's completely unrelated to the blog post at all.

I have no desire to discredit someone I have never met and whose name I do not know, much like I have no desire to have my intentions explained to me by a Hacker News commenter. I wrote, quite clearly, that I wasn't doing something. To directly assert that I am in fact doing that thing and then ascribe further malice to it is to challenge my honesty and integrity, and I'd appreciate if you'd not do that in the future because you've never met me and know nothing about me.

There is an interpretation of my first bullet that would support your conclusion, but I only put down my first bullet to establish relevance in the comment, not to connect the two things.

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

#727
post #368

Earlier quoted context omitted.

So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.

It seems to me parent's answer only reflects the general attitude at Google: they don't question anything they do, they don't do "customer support" and they don't display humility Yes, I'm not expecting the conversation to have been exactly that, but it shows problems regardless.

Listen, you have been hired by the greatest software company on the planet, you survived ridiculous recruitment process with multiple pointless whiteboard interviews, CLEARLY you are special. How dare those unworthy peons slander the name of your company? they arent qualified, you are. "customer support"? You are not being paid >200K to sit 8 hours in a chat telling people to turn it off and on again.

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

#728
post #620

Earlier quoted context omitted.

both types of hash convert an input space to an output space where (typically) the input space is much larger. What matters is whether similar inputs get mapped to the same output. For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash, although those are expensive so you want a cheaper approximation, which is exactly what finge…

"For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash" That's what I was trying to say: "a tiny change in the input causes a substantial change in the output." But I probably didn't articulate that very well. I think we are saying the same thing. You mentioned: "The problem is that as the input values counts approach sqrt(outp…

https://en.wikipedia.org/wiki/Birthday_problem Basically, you get 50% chance of collision around sqrt(size of table).

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

#729

Earlier quoted context omitted.

My father is a civil engineer and late in his career, he interviewed for a senior position at a construction company. He figured out that the interviewer didn't know what he was talking about early on the interview and confronted him with that. The interview came to a end, he was put in touch with a senior engineer at the company. He didn't take the job for other reasons. I don't think this kind of rubbish would fly…

A civil engineer is a professional engineer. I would assume your father is a certified PE [1]. This rubbish flies in our industry since we are not professional engineers. [1]: https://en.wikipedia.org/wiki/Principles_and_Practice_of_Eng...

Nonsense. It's because your industry is relatively new and hasn't established the same institutions.

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

#730

Earlier quoted context omitted.

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,…

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.
Post reply on HN