Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

Post reply on HN
Print view View original

791–800 of 969 posts

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

#791

Post by ubernostrum »

_wmd wrote: post #739
kev009 wrote: post #736

Earlier quoted context omitted.

This blog is exactly what an SRE interview is like. I breezed through these kinds of questions with the recruiter since I'm younger have a fairly fresh CS background. Then, my first SRE staff interviewer primarily asked how I would build a data center on the moon. I work on the FreeBSD kernel and TCP full time. I know what BDP, window sizing, head of line blocking, etc are way beyond what a typical SRE would and how…

> even though I would rate myself more knowledgeable than my questioner Don't get me wrong, I'm guessing you know your stuff, but you also strike me as someone who may likely have failed on culture fit down the line. Interviewers are often more sensitive to attitude than they ever are to aptitude, and for good reason, your HVAC knowledge may be irrelevant once you discover the custom designs in use behind closed door…

At the same time, it's a useful filter for the candidate.

Last year when I was job hunting I kept getting fizzbuz-style phone screens, even from companies who'd specifically contacted me because they knew who I was and what my skills/experience were, because they have to be sure to filter out those unqualified core committers of software they use on a daily basis.

Anyway, I got asked the "write a palindrome checker" question multiple times in those screens. I guess more companies than I thought have a Department of Palindrome Quality Assurance these days. But after about the fifth time, I just started going overboard on the question to make a clear point to the interviewers. I got a pretty good patter down where I could write out the code while describing all the random quirks phone screeners never have heard of: I'd start lecturing about combining characters, right-to-left directional shifts, the tradeoffs of considering solely Unicode code points versus graphemes, using the character database to identify categories of characters to ignore when considering whether a string is palindromic, etc.

Interviewers who took that poorly did not get my further cooperation. Interviewers who took it well (by being positive/polite about it, or even admitting that yes, this kind of phone screen is a waste of everyone's time when you already know you're interviewing someone who can code) got to talk a bit more. But I ended up accepting an offer from a place that actually worked to make their interview process better then this, and which continues to evolve it all the time.

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

#792

Post by empath75 »

krzyk wrote: post #597
djsumdog wrote: post #555

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…

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.

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

#793

Post by empath75 »

HereBeBeasties wrote: post #610
djsumdog wrote: post #572

Earlier quoted context omitted.

I think coding questions are really important. You see their logic flow. Now stupid coding questions (in a list, find all the number pairs that add up to another number in the list) are terrible. They're complex and even good programmers need time to think about them. Fibonacci is one that people expect, so they look up all the variations and you get people who are good test takers (would ace a GRE/MCAT) but not good…

I often ask the web browser one and find it quite illuminating. Best answer so far started with something like "Well, there's a microswitch in the keyboard if it's a decent one, and a circuit that debounces the input - err, is it a USB keyboard or a PS/2 one? Hmmm... How long do I have to answer this question?" THAT is the guy you want to hire...

I feel like there is a happy medium there.

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

#794

Post by ubernostrum »

odbol_ wrote: post #404
potatolicious wrote: post #375

Earlier quoted context omitted.

Disclaimer: I also work for Google, opinions are my own, etc etc. > "i always take "transcripts" of interviews (or anything else) with a grain of salt" I mean sure, a single instance of this might be overblown, exaggerated, or false in some way. But there is an avalanche of reports like this, to the point where it's become widespread industry insider knowledge. I enjoy working here, but the interviewing practices are…

The problem with Google's interview methods is that they all select for a very specific type of programmer: heavily math oriented, deep knowledge of obscure Computer Science theory, but not one test on knowledge of languages, architecture, design, or actual real-world problem solving. I walked into an interview with one guy and he literally did not even say hello: he just jumped straight into some problem I had to so…

Google's interview process, and interview processes modeled on it, do not select for "math-oriented CS-conscious" engineers.

These processes select for recent CS graduates from a handful of universities where Google expends recruiting effort, and anyone not from that background mostly only gets in by blind luck or by knowing someone already in Google who can navigate them through getting hired there.

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

#795

Post by tmptmp »

DannyBee wrote: post #152

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…

This reminds me the story of one of the WhatsApp founders getting rejected by FaceBook. [1]

Hope this doesn't turn out that costly for Google. But I'd be happy if it does, if it is the way the interview was really conducted.

[1] https://twitter.com/brianacton/status/3109544383

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

#796

Post by empath75 »

throw_away_777 wrote: post #691
exDM69 wrote: post #598

Earlier quoted context omitted.

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

We actually do let people use Google during our code interviews. They'll use it at work, so why not.

We do watch them work though so if they just copy and paste from stack overflow and they don't understand the problem, it's pretty obvious.

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

#797

Post by delroth »

falcolas wrote: post #527
DannyBee wrote: post #497

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…

> Then why ask about the nitty gritty details required by maintenance personnel as part of the screening process

I'm not sure what "nitty gritty details" you're talking about here.

As much as some people here think it's impressive knowledge[1] to be able to give the size of an ethernet MAC address without Googling it, that's something that anyone with experience in computer networking oughts to know. Not at all because it's useful knowledge, but simply because if you actually spend time looking at network traffic dumps or ARP tables or DHCP configuration or SLAAC assignments you'll be seeing MAC addresses so often that it just becomes obvious. Just like knowing that an IPv4 is 4 bytes and an IPv6 16 bytes. Or that a TCP connection starts with a 3-way SYN/SYN-ACK/ACK handshake.

And the same thing applies to the other questions that look like meaningless details: knowing what an inode is and what syscall returns inode data for a path is something that someone with system-level C programming experience should know. stat(2) is far from being something obscure. Knowing what signal is sent by the kill(1) command is maybe slightly more on the trivia side IMO, but it's still a very well known fact.

A candidate is most likely not expected to know the answer to all of these questions. But failing in all of the categories is IMO a fairly strong red flag for someone interviewing for SRE, where in general people are usually expected to be comfortable with at least one of {networking, system administration, Linux internals}. In fact, this domain specific knowledge is the biggest differentiator between "standard" SWE and SRE-SWE, even though the lines get blurrier and blurrier.

This also indirectly answers this:

> things I would rather have my high level employees looking up rather than relying on a possibly faulty memory

You would have to be out of touch with the field for quite a while to forget such basic things. Which is likely something that you want to test for in such interviews. To go with a metaphor: if you claim to be a fluent English speaker on your resume, you can't be excused of "faulty memory" if you forget how to conjugate "to be" in the present tense. It's not something you forget easily, and if you did forget you most likely can't say you're fluent anymore.

Disclaimer: I was an SRE at Google for 2.5 years, but I'm not familiar with the early phases of the recruiting process.

[1] https://news.ycombinator.com/item?id=12701486

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

#798

Post by EpicEng »

lucb1e wrote: post #192
lordnacho wrote: post #13

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…

> I mean who would know just how long a MAC address is? Uh, my main languages are PHP and Python (high level stuff) and I'm a student (not someone with 10 years of experience) but I knew that. 3 bytes for the vendor block, 3 bytes for the device. > Or what the actual SYN/ACK etc tcp flags are? Yeah the actual bytes, who ever uses that? A MAC address I've seen plenty of times in my life as hex, and I've seen the TCP s…

Yeah, you're a student; you probably just took a class on this stuff. You'll forget it soon enough if you don't use it.

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

#799

Post by empath75 »

whoops1122 wrote: post #671
zzzcpan wrote: post #594

Earlier quoted context omitted.

Now take into account stress, lack of preparation, environment the person is not used to, unusual syntax patterns for them, biases against them, their way of talking, their appearance, etc. and you get yourself people good at your kinds of interviews in your biased view. You can only hope they are at least average at their job.

The most beautiful and elegant part of coding is the logic, Not how to use a for loop. Anything question that can be answered with google should be forbid from a interview test. show him a method, ask him how he can improve the performance. ask him a opinion based question on OO design. if you hiring a house builder u would not ask him what a brick looks like right?

Yeah, but if your have to get through 100 house builder interviews and half of them don't know what a brick is, it saves a lot of time, no?

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

#800

Post by mcphage »

krapp wrote: post #329
gautamdivgi wrote: post #310

Earlier quoted context omitted.

You proved P = NP??? In a little more than 45 mins or did you misunderstand the question?

If I were asked that question, my answer would be that obviously P != NP because the former doesn't have an N at the front. The pain of being tossed out onto the pavement would totally be worth it.

What if N = 1?
Post reply on HN