Google's “Director of Engineering” Hiring Test

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 engineering, but they decided to interview him for a different level/job instead.

But it's super-strange even then (i've literally reviewed thousands of hiring packets, phone screens, etc, and this is ... out there. I'm not as familiar with SRE hiring practices, admittedly, though i've reviewed enough SRE candidates to know what kind of questions they ask).

As for the answers themselves, i always take "transcripts" of interviews (or anything else) with a grain of salt, as there are always two sides to every story.

Particularly, when one side presents something that makes the other side look like a blithering idiot, the likelihood it's 100% accurate is, historically, "not great".

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 communication latency would cause major issues. That confused the questioner. I can't think of anything else I'd have said wrong, my background is systems engineering and I know more about power distribution, HVAC, and data center design than I care to. The lady was skeptical of my answers and it felt really humiliating even though I would rate myself more knowledgeable than my questioner, because of the candidate/interviewer positioning and failure.

The next man, on another day, asked me a bunch of math trivia like estimating the angles on the hands of a clock and orders of magnitude guesses of a small item like a marble to fill a room. I told him I was no longer interested in working for Google and he was really startled because "he didn't get to ask me systems questions yet".. well, good luck with that.

Everyone was really sad at that point, including the recruiter. Nobody from Google has contacted me again, which is a relief. I found the entire process gross.

> 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 doors, and a bad attitude toward learning where you're weak can be a much more fatal problem for a new hire.

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.

In the time since that Google interview, I've moved into management and have built a very high performance team recognized as such by peers and the executive team.

For internal hires, I convinced people to come work for me that I had immense respect for by using casual conversation and pitching the idea and vision for a new operating systems team.

I've found this is also a classy way to hire external people. I've since hired people off freebsd-jobs@ mailing list and twitter by being upfront about the good and bad of working at this company. No trick questions, just a conversation about what we like to work on. This was easy because I had an idea of what they have accomplished by their commit logs.

Most recently I hired two women, masters students, for summer internships. This was very different because I had no idea what the candidates had done as coursework or projects beyond a simple resume. I again used casual conversation, no trick questions. I posed some real world situations, passively seeing if they understood concepts like deadlock, manual memory management, indirection, and had very good working CS/OS vocabulary. This eliminated most of the other candidates, and it was pretty clear who had slogged through their OS and networking classes without passion. I let each person tell me about projects they worked on which really excited them. One had done Linux USB driver on her own time, among other interesting things. The other had implemented a scheduler and file system on a teaching OS as part of her course work. Both worked out phenomenally and both have patches in the FreeBSD.org source tree from the 2 month internship experience. I am very proud of this, and of my team for mentoring them so successfully.

The people I hired were often confused; "That's it?" at the end of the phone or in person interview. They thought they had done something wrong because they are so used to being sweated for the sake of being sweated.

I am now convinced this is the only ethical way to build teams and hire -- start with some seasoned vets then grow new talent while refining and reinforcing shared values.

I don't really see what the stereotypical SV tech interview accomplishes. Blind leading the blind. Leadership is piss poor in this industry.