←back to thread

1764 points fatihky | 1 comments | | HN request time: 0.215s | source
Show context
DannyBee ◴[] No.12701869[source]
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".

replies(28): >>12702181 #>>12702207 #>>12702219 #>>12702265 #>>12702346 #>>12702460 #>>12702555 #>>12702650 #>>12702692 #>>12702698 #>>12702714 #>>12702888 #>>12702998 #>>12703034 #>>12703135 #>>12703156 #>>12703184 #>>12703554 #>>12703778 #>>12704177 #>>12704657 #>>12705201 #>>12705560 #>>12705982 #>>12706518 #>>12707763 #>>12708151 #>>12714459 #
ozgung ◴[] No.12702650[source]
So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.
replies(7): >>12702739 #>>12702813 #>>12702973 #>>12703024 #>>12703078 #>>12703204 #>>12704968 #
DannyBee ◴[] No.12703204[source]
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 not. Plenty of companies promote people just because they last long enough. So 20 years experience managing may translate into a high level manager, it may not!

I hold a bunch of patents too on compilers and other things, it's not indicative of much in terms of skill, because almost anything is patentable.

Lastly, SRE is not an ordinary site maintenance position by any means. I"m not even sure where to begin to correct that. I guess i'd start here: https://landing.google.com/sre/interview/ben-treynor.html

Does this mean this person is under/overqualified/exactly right? I literally have no idea. I just don't think it's as obvious one way or the other.

"Well, that sounds like a dumb recruitment process."

Judging an entire recruitment process based on one side of a story from a person who's clearly upset about an interview, and even 3 sentences i wrote on hacker news, seems ... silly.

If you want to do it, okay.

But everyone in this entire thread seems to be making snap judgements without a lot of critical thinking. That makes me believe a lot of people here have a ton of pre-existing biases they are projecting onto this in one direction or the other (and you are, of course, welcome to claim i fall into this category too!)

I almost didn't jump into this discussion because it seems so polarized and rash compared to a lot of others

I think i'm just going to leave it alone because it's not clear to me the discussion is going to get any more reasonable.

replies(5): >>12703234 #>>12703322 #>>12703366 #>>12703407 #>>12704580 #
falcolas ◴[] No.12703366[source]
> 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 sentences i wrote on hacker news, seems ... silly.

This kind of opinion is not formed in a vacuum. It's formed of the dozens of posts that appear every year about how someone who seems qualified is turned down for spurious reasons like "being unable to reverse a binary tree on a whiteboard". It's what makes this particular post so believable - it fits the stereotype. Even your own developers who post here say "yeah, that's more accurate than inaccurate." Perhaps it wouldn't hurt to "undercover boss" your way through the interview process...

Speaking for myself, and only myself... I turn down all Google recruiters because I know I would not pass Google's interview process. Not because I don't have the skills, but because I don't have a college degree. Because I don't see the return on investment for studying for the next 6 weeks just to pass the interview process, especially when I won't even know if I'm getting a job I'll enjoy.

> I think i'm just going to leave it alone because it's not clear to me the discussion is going to get any more reasonable.

How about the responses from your own employees which are pointing out that they see the problem too. Are they being unreasonable?

replies(3): >>12703464 #>>12704693 #>>12705989 #
1. delroth ◴[] No.12705989[source]
> 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