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

181–190 of 969 posts

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

#181

Post by apathy »

googlya wrote: post #177
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…

Not agreeing with the recruiters attitude but "if Google is down you will need to know this to diagnose what the problem is." was his comment. In that case the developer should have cheat-sheets printed on their desks.

if Google is down you'll have other problems (SYN, ACK, SYNACK won't help much with the DDoS that's killing it)

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

#182

Post by colordrops »

johan_larson wrote: post #23

The meta-question is, "Do you have the social savvy to give the conventional answers when being judged by someone who doesn't know what he is taking about?"

While this recruiter probably failed at their task, I do agree that there is skill in communicating technical information to non-technical people, and it is a valuable skill. I wouldn't be surprised if the author of this blog post acted a bit curt or acrimonious to the recruiter, and stubbornly insisted on being "right" rather than communicative and agreeable.

Know your audience.

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

#183

Post by lordnacho »

user5994461 wrote: post #143
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 wonder what would happen if ordinary people recruited for medical doctor jobs? Would you be comfortable rejecting a guy who'd been in medical school for 10 years based on his not knowing what the "funny bone" is? Wouldn't you tell your boss that you felt a bit out of that league? It's amazing you can get someone to do this without them going red in the face. The medical recruiter asks to see the diploma. The doct…

"Diploma says DO, not MD. You don't get the job."

https://en.wikipedia.org/wiki/Comparison_of_MD_and_DO_in_the...

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

#185

Post by lucaspiller »

buttershakes wrote: post #7

I had almost exactly this same engineering test when google interviewed me in 2006. It was terrible, and left a bad taste in my mouth. Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.

> Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.

I had the same a couple of years ago, at the time I was a Rails developer at a small startup. The first screening they asked me some basic technical questions (I guess it was a recruiter), then the second screening they asked me to walk through some data structures and algorithms off the top of my head.

I knew they would do this, and hadn't looked at any CS algorithms since university, so got a copy of Programming Pearls and studied through that every evening for the week before. I picked a few that I hoped would come up, and it turned out that's what they asked for. I think first a linked list (maybe doubly linked?) and then a tree sort.

I surprisingly passed, but the attitude of the interviewer really put me off. He said he knew Python, Java and Go - none of which I had used - and wasn't too happy when I said I wanted to use Ruby (which the first guy I spoke to, said was fine). Then throughout the interview it seemed very much like he was fighting against me and trying to prove me wrong.

After that I couldn't be bothered any more, I didn't really want a job at Google, it's just a recruiter contacted me and I decided to try it out. I guess this style of interviewing must work for Google, but it's just not the way I like a company to introduce itself to me. It just seems like they are approaching it with so much ego, as if I would be privileged to work there, but to me a job should be mutually beneficial.

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

#186

Post by tptacek »

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.

In C, what stat does is how you return multiple values from a function.

lstat has the same signature as stat: it passes the stat structure back through an output pointer.

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

#187

Post by ksec »

JorgeGT wrote: post #63
ohitsdom wrote: post #29

It is scary if this is how Google hires engineering directors. Passing this test would select all the bad candidates! Answers to many technical solutions are "it depends". If you have a director that "knows" the right answer, they won't be very likely to encourage their engineers to experiment and find the best solution to the specific problem at hand.

A brilliant professor of mine liked to say "The Answer of the Engineer: it depends".

That is nearly the answer i give to every questions. But when i asked for more detail no one likes it. They all simply want "answers".

Well much like most things in life, there is no such thing as concrete answer.

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

#188

Post by caoilte »

endtime wrote: post #42

I've been at Google for five years as a SWE and I've been interviewing for 3 of those. I'd fail this pop quiz. This strikes me as bizarre and inconsistent with all the practices I'm aware of. The idea that we'd ask anyone this stuff, let alone director candidates, strains belief.

The only way this makes "sense" is if you already have the candidate (or pool of H1-B candidates) you want in mind, but have to prove you opened up the position to the general public first.

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

#189

Post by dmayle »

TheCapn wrote: post #41
buttershakes wrote: post #7

I had almost exactly this same engineering test when google interviewed me in 2006. It was terrible, and left a bad taste in my mouth. Given the complexity of the work I was doing at the time, the entire thing seemed ridiculous.

The inode question gave me flashbacks to my interview with Amazon. They wanted me to explain what a hash function is. I kept giving answers for about 3 minutes explaining hashing, common algorithms, reasons to use it and places it applies. Recruiter: "I was looking for you to say it's a fingerprint " So I guess I was wrong, because despite explaining them in decent detail, I didn't use the one keyword.

I'd have failed too, because I use a very particular way to describe a hashing function.

A hashing function is actually a sorting function. It's supposed to take an input space and sort it in an unpredictable and evenly distributed way across the output space. What's more, neighboring points in the input space, no matter the sort used to determine proximity should not result in neighboring points in the output space.

Fingerprinting is just an emergent value that comes from choosing fixed length hashes, and the fact that the mapping from input to output is stable.

Post reply on HN