Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

781–790 of 969 posts

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

#781

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…

I never said anything about your integrity but you inferred from my comment just like others will do from yours. The difference is the individual you're disparaging is a real person with a reputation. You, like me, are a throw away account on a message board. You have no integrity because you have no identity.

>The difference is the individual you're disparaging is a real person with a reputation.

So? If the criticism is invalid, then it's inoffensive. If it's valid, it's deserved.

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

#782

I had very similar intervies at Palantir and Yelp, albeit Yelp was understandably just a quick phone screen with a recruiter. However, the "trivia" interview at Palantir came from a forward deployed engineer on the DC based team I was interested in working with and one of my last hour long, onsite interviews of the day. Seemed like a big red flag at the time.

> the "trivia" interview at Palantir ... Seemed like a big red flag at the time. Besides the bigger red flag that it was Palantir, you mean.

No, at the time Palantir was mine and a lot of other people's too choice at Berkeley. They spent a ton of money on recruiting my class and I went there for dinner/lunch several times.

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

#783

Earlier quoted context omitted.

I got an interview with Amazon, but failed the first round, because I did not do well on the reasoning part of the online test. You couldn't skip questions, so I spent too much time on some of them and had to rush the ones at the end. They failed me despite getting the coding part 100% right. Oh well.

Can you elaborate on what types of things you were asked to reason about in this test?

Sorry, I only saw your comment now. They were asking stuff like finding patterns (like in IQ tests). Then they also had ones where you had to read text and then say what you would do with it based on certain requirements. You couldn't skip questions so I spent way too much time on the number ones.

I cannot obviously tell you the exact specifics because of the NDA.

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

#784

Earlier quoted context omitted.

>Judging an entire recruitment process based on one side of a story from a person who's clearly upset about an interview, It's not just this guy. There have been others: https://twitter.com/mxcl/status/608682016205344768 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. I've also heard a few…

Yep, those engineers they took on in the last ten years must suck, they've only managed to develop technologies that grew Google's annual revenue from 10 billion dollars in 2006 to 75 billion in 2015. That's the kind of track record that has to make you question the hiring process, right?

There are a lot of assumptions being made here. Sometimes companies grow despite poor hiring decisions. I think you need a finer-grained view than just revenue to really tell whether you're doing a good job or not. Lots of terrible decisions have been justified by this "the revenue went up so we must be doing a good job" line of reasoning.

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

#785

Earlier quoted context omitted.

It is also a ridiculously dogmatic question. Many people believe into a fallacy that static typing makes safer programs, for example, and expect that somewhere in the answer.

Could you explain how static typing makes less safe programs?

If the type system is not expressive enough and you have to get around it?

The claim that "dynamically type language" allows code to more closely follows the business logic has merits. And you could follow from that to claim that type system could be causing more bugs (ie less safe).

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

#786

Earlier quoted context omitted.

>Judging an entire recruitment process based on one side of a story from a person who's clearly upset about an interview, It's not just this guy. There have been others: https://twitter.com/mxcl/status/608682016205344768 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. I've also heard a few…

Yep, those engineers they took on in the last ten years must suck, they've only managed to develop technologies that grew Google's annual revenue from 10 billion dollars in 2006 to 75 billion in 2015. That's the kind of track record that has to make you question the hiring process, right?

You seem to be confusing "I have a smug twitter-sized sound-bite response" for "I have a worthwhile counter-argument".

It's a common failing these days, but you should probably look into getting it fixed.

That said, yes, Google's hiring process is questionable. The Web is full of horror stories from obviously-qualified people who Google passed on, often very early in the process when no engineer had talked to them, and this suggests Google's success is not sustainable so long as that continues. They'll be able to hire fresh CS grads out of Stanford forever with this process, but the experienced/unconventional people they flunk out on the early screens are not going to come to them, and when their current crop of experienced/unconventional engineers retire or take jobs elsewhere, Google's finally going to have to fix this problem and stop pretending that it's better to pass on a thousand highly-qualified candidates than to give one unqualified candidate an on-site. That, or tumble back down into mediocrity.

(which, to be fair, is already mostly the case; Google is largely a mediocre company, with only a couple of externally-visible brights spots of talent or innovation clustered in a couple of particular teams, and otherwise Google runs on inertia and the hope that the 0.1% of interesting stuff they come up with will keep the 99.9% of mediocrity afloat)

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

#787

Earlier quoted context omitted.

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.

Maybe it's the whole "better to have false negatives than false positives" philosophy Google espouses?

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?

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

#788

Earlier quoted context omitted.

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

> they are written down wrong.

Please, feel free to correct the record, then, with the correct screening questions. The proverbial cat is out of the bag, and has gone tearing down the street towards everyone trying to make a buck by "training" hopeful young graduates on how to make it through the Google interview process.

> 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

No, it won't. Because it's the tech equivalent of a lottery winner saying they think the lottery system is a fair and equitable way to distribute money.

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

Same problem. If you're in, you passed the Google employment lottery, so it's much more interesting (and should be more meaningful to management) when insiders agree that the hiring process has problems.

Now then, of course, so long as directors find that they have plenty of applicants to back fill attrition and grow, they have no reason to think the hiring process is broken; so long as Google is happy hiring not necessarily the best people for the job, but the ones lucky enough to dodge more false negative flags than everyone else. Better to be lucky than good.

All that said, yeah, Google's hiring process works for Google. Coming here, to a conversation started by a crappy screening experience, and expecting respect for a process with so many false negatives is a bit optimistic, though.

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

#789

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.

I think you're neglecting the continuous improvement of successful projects, which take quite a bit of engineering effort.

Was it software quality that killed Wave and Glass, or was it more of the market not wanting either of those things? (To digress, it seems like both of those products came too early. Do you think that wearable computers will _never_ exist? And Slack seems to be the Wave-like thing that the market wanted.)

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

#790

Earlier quoted context omitted.

My kick-out questions: "Could you write out what an HTTP request and response looks like on the board?" I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger? "What's the difference between a GET and a POST request?" "W…

I believe 90% of my coworkers and former coworkers would be unable to answer the HTTP response question. And 95% haven't used netcat or wireshark. I wouldn't have either, if it wasn't for some particular work related to messaging. They're able to develop reasonable line of business websites in spite of that. I would be extremely worried if they were unable to answer about the difference between GET or POST, or the di…

I basically lived in Wire shark for a couple of years working for a voip company and still use stuff like curl all the time and I don't think I could walk through an http request of the top of my head.
Post reply on HN