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

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 such that I actively warn friends applying/being referred to temper their expectations of a repeatable/reliable process.

Most colleagues I've spoken to about this, including myself, have strong doubts we would have made the cut if we interviewed again - even though all are strong engineers with great perf records.

At what point do we start taking reports like these seriously? We don't have to accept every detail of the reporting as gospel, but there's clearly something here.

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 solve on the whiteboard.

The problem with that approach is you end up with a very homogenous team of really smart, logical people, but without the balance of more creative, empathic types. Ideally, a well-functioning team will have both, and will have people from many different backgrounds and educations, because that's when you get true collaboration and innovation: by mixing unrelated disciplines.

It tells more of the interviewer than the interviewee. They don't ask the questions you mentioned because they don't know or they don't know how to best judge the answers. They asked the questions they know well, that show you what the breadth of their knowledge is. It's like the saying A-players hire A-players while B-players have a hard time judging A-players.