Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

841–850 of 969 posts

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

#841
post #597

Earlier quoted context omitted.

Why it is important to know the difference between statically and dynamically typed languages? If one writes in only one of those (or one set) it is not important to him/her and doesn't specifically make him/her a worse programmer in that particular language.

If they didn't know it, I'd want to dig down into whether the understand the specifics of their particular language at least. I actually just sat down in a meeting with a dozen programmers, some of them with decades of experience, and half of them didn't know what functional programming was.

And the half that didn't know where much worse programmers than those that knew?

Your example shows that not every programmer has to know that.

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

#842
post #189

Earlier quoted context omitted.

I'd have failed too, because I use a very particular way to describe a hashing function. A hashing function is actually a sorting function. It's supposed to take an input space and sort it in an unpredictable and evenly distributed way across the output space. What's more, neighboring points in the input space, no matter the sort used to determine proximity should not result in neighboring points in the output space.…

Why do you use the word "sort" rather than "map" here though.

I'd guess because sort implies an ordering, which, when total, implies a distance.

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

#843
post #208

Earlier quoted context omitted.

I've had two phone screens with them and both times they were very technical people. Then again it was some time ago and with the bigger scale they may have changed it up. It is unfortunate, but as mentioned above, you need to just play the game until you get to the real part. It's like when I call customer support, I gotta play along with the non-technical people and get them to bump me up the chain to someone techn…

>I've had two phone screens with them and both times they were very technical people. Then again it was some time ago and with the bigger scale they may have changed it up. Just to clarify, at least for the SRE hiring process, you first have a single technical phone screening with a technical recruiter (not an engineer) which is literally on the phone. At least it was for me, no webcam or anything. It's a pretty shor…

You're exactly right. I was asked some of these exact questions yesterday. The guy should have realised what he was dealing with, the recruiters don't claim to be technical, and the questions are flagged as being straight forward pre screen questions.

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

#844
post #672

Earlier quoted context omitted.

"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 ...

But they appear to be changed in subtle ways from what's listed on other sites. For example, googling for: Google SRE interview questions inode 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://greg…

I got asked some of these questions literally yesterday by Google and you're right. The wording was how you've presented it, not how he did.

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

#845

Earlier quoted context omitted.

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.

GET / HTTP/1.1\r\n and some kind of sensible response is not too much to expect someone to know. HTTP is super easy and I see the HTTP transaction test as "did you ever get curious as to how exactly a core part of the current Internet actually works". I'm sure that there are app developers out there who can spin crud stuff all day and have no idea about this, just as there are curious people who couldn't stand up todomvc to save their life, but in general, all of the most talented people I've worked with knew their stuff front to back, and had at least a few areas of expertise.

CGI is also cool to learn about the workings of, since it almost seems too simple.

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

#846
post #438

Earlier quoted context omitted.

> they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. To be fair, I've interviewed people at previous companies that had patents and 15 years at IBM on their CV and completely failed even the most basic system / coding questions. (fizzbuzz style). There are a lot of people that read great on the CV but then it turns o…

> completely failed even the most basic system / coding questions. But could they at least tell you why quick sort was the best sorting algorithm?

Apart from the fact that it isn't always the best sorting algorithm and it's pathological worst case is in fact as bad as a bubble sort's worst case (O(n^2) with a higher base operational cost, as at least bubble sort's worst case is somewhat cache friendly). This happens in three cases; 1) all the elements are sorted in descending order, 2) all the elements are sorted in ascending order, or 3) a special case of 1) and 2) combined, all the elements are equal.

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

#847

Earlier quoted context omitted.

That's a preposterous attitude. Just imagine if we took a similar approach to hiring for other kinds of jobs: "OK, so you'd like to work here as a mechanic. What's the difference between automatic and manual transmission?" "It's not fair to expect me to know that off the top of my head. If I need to know, I'll just do a Google search."

That's a crap comparison. You're gonna have a hard time drawing a comparison between a line of work where you build things and one where you fix things.

Ok, how about "What is the firing order on a Chevy LS1?" ?

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

#848

Earlier quoted context omitted.

I agree with the first and second sentence. As to the third: what would be your thought process as to someone who claimed to be a network programmer on the phone but couldn't answer most of those questions?

I think you can probably predict it: I would generate a work-sample test for it. For a network programmer, I might have them implement a 3WH coded directly to pcap_write() (which requires you to populate the Ethernet frame header). Like the best work-sample challenges, doing a raw 3WH is kind of fun if you haven't done it before. My friends and I used to spend bar nights drinking over torturous interview questions (y…

> You can't learn about someone's capabilities by putting them on the spot with trivia questions.

But that's not the point of these questions. These questions are a 5-10min phone pre-screen before getting to the actual interviews. They test if the candidate has experience in a given field, not if they can search for information or what are the precise bounds of their capabilities.

It's trivia, but it's trivia that is a reasonably high confidence proxy for experience in e.g. network programming/design (resp. other fields). If someone claims they have networking experience and don't know SYN/SYN-ACK/ACK it's in my opinion a large red flag.

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

#849

Earlier quoted context omitted.

In all fairness, if you can talk normal HTTP 1.1 over telnet with some service, someone configured TLS wrong ;) And if you can talk HTTPS over telnet unassisted... well, I am truly impressed.

There's always openssl s_client

Yep, and when devs watch me key in the s_client pipe to OpenSSL to dump the cert info it's like I've become Neo and entered bullet time. I guess they don't need to know this stuff, but trying to do things like editing a hosts file in OSX, flushing dns, opening an incognito tab, looking at the SSL cert through the GUI, manually comparing it to one in an editor....vs a pretty short one-liner with curl or OpenSSL and a diff....I guess I'm either biased or lazy. I also almost never get asked WTF I just did, just a "wow, thanks" at most.

A previous employer had a sysadmin wiki. We call it Devops now, but I really liked working with the plain-text files of Dokuwiki there. Confluence is good for some things, but as a notebook of shell snippets and when to use them, it's not great.

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

#850

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…

> 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.

Why is it a poor metric? Isn't the point of hiring employees to ideally build and launch successful products?

I think Google is pretty good at hiring "qualified" engineers who are very good at maintaining and scaling existing systems, but the process definitely selects against entrepreneurial product-focused engineers. Maybe Google thinks that's fine though: they can always pick them up through an acquisition later, albeit at 100x the price.

Post reply on HN