Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

881–890 of 969 posts

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

#881
I interviewed with Google about 10 or so years ago for a manger post. I was not selected after 3rd phone interview.

Potential job was about predicting number of servers required or something like that. I was recommended by a friend's friend who apparently worked there. Google contacted the day they saw my resume and did two quick phone interviews verifying my basic background.

In the third interview which was highly technical, they asked a bunch of techie things including what an inode was. Whatever answer I gave about inode was apparently OK, as the interviewer proceeded to ask me how I would repair a faulty inode.

Since I did not know the answer, I honestly said I do know and joked that I would "google" for the answer. My pathetic attempt at humor did not sit well with the interviewer and was told that I did not pass the current interview.

Fixing inodes or other hardware/software problems is certainly something that needs to be done, but I did not buy the interviewer's assertion that everybody in Google knows how to fix inodes. For making predictions about server needs, failure rates are just one factor to consider and the time needed to repair them.

Whether a prediction manager needs to know the low level details of fixing inodes is questionable in my mind. I just assumed that Google interviews a staggering amount of people and reject a large portion of them for the smallest of reasons (like how astronauts are selected). It also seems they hire people for one thing, but that does not preclude them in deploying them in totally different positions. Otherwise there was no reason to ask me techie questions.

What surprised me was how fast they moved, how upfront they were about overall interview process, and how they asked about non essential questions from my perspective.

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

#882
post #834
post #593

Earlier quoted context omitted.

(Very) embedded developer speaking here. What's this L1 cache you speak of?

It's level 1 CPU cache, the fastest (and smallest) cache. It caches both instructions and data. https://en.wikipedia.org/wiki/CPU_cache

GP is making the point that not all CPUs have a cache.

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

#883
post #872

Earlier quoted context omitted.

That's a big claim. Can you share some of the actual wording of the questions?

If you work at Google you can find them by searching for it.

Maybe not such a good idea to post an internal link? :)

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

#884
post #871

Earlier quoted context omitted.

> I wasn't extremely supportive of the interviewee once he turned slightly sarcastic and rattled off hexadecimal bytes instead of just saying "SYN" and "ACK," though. His response: > in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge". What do you think SYN and ACK stand for? Could it be "synchronize" and "acknowledge"? Moreover his point that knowing the bytes is more useful when you're look…

The messages contains a lot more than the flags though so those bytes aren't enough and he didn't mention SYN-ACK.

They're bits. SYN can be represented as 0x02, ACK can be represented as 0x10. 0x02 BITWISE-OR 0x10, ie SYN BITWISE-OR ACK or 'SYN-ACK' colloquially, is 0x12.

"in hexadecimal: 0x02, 0x12, 0x10".

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

#885

Earlier quoted context omitted.

Static versus dynamic typing is so fundamental that I don't see how a programmer could be remotely competent without having been exposed to those concepts enough to have internalized them. It would be like an accountant not knowing what the number 4 is. Yes, you can look it up, but if you need to then how did you ever get this far?

OK, ask me that question about defining the difference and I'll argue with the question, and back up my argument with examples of how type systems are far more of a spectrum of different cases than a stark static/dynamic binary. And then your non-engineer phone screener who's expecting the answer to match the scripted sheet will conclude that I don't know this "fundamental" thing and thus am unqualified.

This isn't a question a non-engineer phone screener can ask. Coming up with first pass filters that don't require an engineer to interpret is harder.

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

#886

Earlier quoted context omitted.

It is also a ridiculously dogmatic question. Many people believe into a fallacy that static typing makes safer programs, for example, and expect that somewhere in the answer.

Could you explain how static typing makes less safe programs?

I have yet to see a large static typed program that didn't -- somewhere -- run into the limits of static typing and contain a set of workarounds, using void* or linguistic equivalent. That's code a dynamic language doesn't need.

The only code you can be sure isn't buggy is code that doesn't exist.

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

#887

Earlier quoted context omitted.

The recruiter misunderstood the answers and or he is not qualified to ask those questions. Usually when you ask someone something that is not literal as in "what is 1+1?" You can't expect them to be literal. Questions like: Why Quicksort is the best sorting method? Guy gave very good answer showing that he has perspective and he is able to make a valid argument. The recruiter on the other hand just read the paper and…

No, I meant that the interviewee misunderstood the questions/answers given by the recruiter and thus misrepresented them when he wrote the blogpost. Since he couldn't even get the questions right I highly doubt that he gave a correct representation of the recruiters attitude as well.

Which of the following seems more likely?

A recruiter who was already giving the guy the wrong interview, and whose job revolves essentially around HR and sales, made mistakes in asking a series of technical questions.

An expert with decades of relevant technical experience misunderstands and confuses basic networking and system topics.

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

#888
post #779

That's not so surprising with Google, I'm afraid. I had the exact same questions (apparently for SRE-SWE prescreen), but a slightly more intelligent recruiter (who had actually chased me for 2 years before I agreed to interview, so they were a bit more invested than the OP's guy). I went on to a phone screen and then on-site interviews, and then the hiring committee. The HC decided that coding/algo was strong, but th…

> My actual areas of expertise (for the last 10 years) are 3D graphics and computational geometry. If I may ask, what put you off your former field so that you decided to move to the server-side world?

Nothing in particular. I was just looking for a bit of a change and to gain more rounded experience. Being pigeonholed into one specific area (3D/CAD/CAM C++ development) for many years isn't that great for future career prospects, especially in a market where most mainstream job titles seem to be split into a front-end or a back-end development category, and my experience doesn't seem to put me in either...

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

#889
post #517

Earlier quoted context omitted.

> Its average case is O(n log(n)). Its worst case is O(n^2). Which do you call its big-O? I know this is irrelevant to the larger point of your post, and I'm sure that you know this already, but the worst case is the big-O. This is just another reason why "big-O" is not the most helpful thing to discuss in practice.

Technically, no. Big-O is a way of categorizing the growth of mathematical functions. Those functions can represent anything. It is wrong to talk about the big-O of an algorithm without specifying what you are measuring. Be it average operations, worst case operations, average memory, worst case memory, amortized average time, amortized average memory, and so on. It happens to be that when we talk informally, we're u…

Apologies. Throughout my CS undergrad I had only been given the impression and understanding that Big-O measured worst case (lower bound, no worse than), Big-Theta average case, and Big-Omega best case (upper bound, no better than). Looking into it more now, I see that there are some more subtleties I either missed in class or was never taught.

Thanks for correcting me!

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

#890
post #630

Earlier quoted context omitted.

It has always been an alternative spelling.

Not so; as you can see in my other comment's link, we can cite OK about 90 years before we can cite "okay", and more reliably than that we can cite the alternative spelling "okeh" to 1919, which establishes pretty well that "okay" was not standard then.

by talking about this you've wasted all the bandwidth your two bytes would have saved a year.

As far as I understand this has been common vernacular since before my lifetime, I'm not usually one to welcome evolution of the base language but this one is before our lives we need to let it be.

Post reply on HN