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

281–290 of 969 posts

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

#281

Post by gaastonsr »

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…

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

Thanks for the refresher! I knew that too when I was in college. Good luck remembering that 5 years from now :)

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

#282

Post by snovv_crash »

madamelic wrote: post #248
chrismorgan wrote: post #131

Earlier quoted context omitted.

But hang on, the primary colours are red, yellow and blue! I know, they told me so in primary school.

I legitimately had a huge argument with my (former) roommate over primary colors. She was more artsy, I was insistent that the primary colors were RGB, she was insistent that they were RYB. We googled. We were both right in some senses.

CMYK would be right. RYB means you can't produce cyan or magenta or vivid purples or pinks.

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

#283

Post by [deleted] »

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…

[deleted]

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

#284

Post by fefe23 »

tptacek wrote: post #52
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 knew all these answers too, because I was a developer in the 1990s. There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part…

Technically stat neither returns nor fills in the inode, because the actual structure of the inode can vary by filesystem, and the inode will contain more fields than struct stat.

In a recruiting situation, if the recruiter is going all "right and wrong" on the interviewee, they should know these dirty details.

I also disagree on the ethernet address length. You know how long IPv4 addresses are, you know how long IPv6 addresses are, why would it be so extraordinary to also know how long MAC adresses are?

I think it could be useful to find out in an interview whether the applicant knows stuff because they have actually implemented low-level code and gained an intricate understanding, or whether they just did used some high level APIs and were never interested in more details than "I have a handle right here, it does all I need". For some positions that would be an important distinction.

Personally, if I were interviewing people, I'd hire the guy that explains something to me that I did not know, but that I find interesting and would have attempted to understand, too.

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

#285

Post by ivan_gammel »

dkonofalski wrote: post #250
ivan_gammel wrote: post #234

Earlier quoted context omitted.

That's wrong. The recruiter has a goal to get "correct" answers: if someone passes the interview without providing these answers via some "soft skills" (it more looks like a social engineering), then the recruiter fails. Because of that, there's no point in trying to explain your answers in hope, that recruiter will somehow agree that they match the answers from checklist. More adequate approach will be to find the w…

What's wrong? I think this is exactly why this test exists. They don't care if you get the "correct" answers at this stage in the process. This is a glorified personality test that, in my opinion, the author misinterpreted as a technical exam. Directors at Google are not going to be the people that know the answer to everything and talk down to people. They're the people that have technical skills while, more importa…

Well, it's just your wishful thinking that it's a such kind of interview, not reality, and any personal attacks on me won't help you to prove your point. I have software engineering management experience in multinational companies and I have hired other managers: there are much more effective ways to find a person with good soft skills than such remote screening with a purely technical checklist. This way it's simply too costly: first, you need really smart recruiter with good soft skills himself, so he will expose the candidate's weaknesses and strengths. Then, there should be very well designed checklist that will allow to derive candidate's mentality from answers on purely technical questions. That's almost impossible, I'd say.

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

#286

Post by throwaway2016a »

tptacek wrote: post #52
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 knew all these answers too, because I was a developer in the 1990s. There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part…

> his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth

While I agree, I have seen interviewers where if he answered "fstat" they would have come back with "Wrong! fstat passes the structure back by reference, it does not return it!"

With this style of interview I can't blame him for thinking it might be a trick question and then trying to explain why he didn't say those other functions as an answer.

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

#287

Post by mortehu »

mox1 wrote: post #84
tptacek wrote: post #52

Earlier quoted context omitted.

I knew all these answers too, because I was a developer in the 1990s. There is absolutely no purpose to knowing off the top of your head how long an ethernet address is, or even what system call will retrieve an inode (his bickering over stat() "filling in" rather than "returning" was bogus, for what it's worth). The top Google search result for each of these questions has the answer. Knowing these things isn't part…

The question was what function "returns" an inode. Those functions return a error code, you pass in a stat structure and the function populates that structure. He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code. To me that is a big difference... int lstat(const char path, struct stat buf); vs stat* lstat(const char *path); 2 completely different functions.

I think the problem was that he didn't update his knowledge about what an inode is after the interviewer told him. He still thought it was an integer value, as opposed to a metadata structure. If inode meant inode number, it works be reasonable to assume there was a function that would return it.

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

#288

Post by tomsaffell »

madamelic wrote: post #248
chrismorgan wrote: post #131

Earlier quoted context omitted.

But hang on, the primary colours are red, yellow and blue! I know, they told me so in primary school.

I legitimately had a huge argument with my (former) roommate over primary colors. She was more artsy, I was insistent that the primary colors were RGB, she was insistent that they were RYB. We googled. We were both right in some senses.

Good job you didn't have a third roommate who worked in printing...

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

#289

Post by nickpsecurity »

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…

Your comment combined with this one...

https://news.ycombinator.com/item?id=12701650

...creates an alternative interpretation in my mind that's not as bad. That is that the questions were a filter attempt done wrong in that it didn't account for stronger candidates giving better answers with a way for interviewer to confirm them. On top of that, a simple, data, entry error by HR person or whoever forwarded his name to them might have put him in wrong interview category. That's two, small problems vs a huge one implied here.

Although the damage appears huge if they're filtering out candidates with his track record with the pre-screens.

Post reply on HN