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

611–620 of 969 posts

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

#611

Post by HereBeBeasties »

optimuspaul wrote: post #510
johndubchak wrote: post #485

Earlier quoted context omitted.

Perhaps that suggests you're giving them the wrong interview.

I agree. Why the hell would you ask someone at that level basic questions like fizz buzz? It's absurd. I also tend to shy away from asking coding questions in interviews, they don't tell me much about aptitude for critical thinking and culture fit. Skills can be taught but culture is much harder. ... But I'm not saying to throw in some questions that don't prove that they are actually competent, just be casual about…

The question is, "why wouldn't you?" If the person is competent they will dismiss it in seconds and you can move onto something more interesting.

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

#612

Post by gcp »

monocasa wrote: post #531
greyman wrote: post #372

Earlier quoted context omitted.

Yes, but without that instruction, the algorithm mentioned by recruiter is really the quickest way. I coded chess algorithm in the past and this was exactly the method top chess open-source engines used. But imho it is hard to figure that out without prior experience with this problem.

Yep. Went and tried the lookup method against a 5 step parallel shift and add method (which is the fastest bitwise way I know of without, and the lookup is ~5% faster than the bitwise way. https://gist.github.com/monocasa/1d44a03cbd0170bfffc6a4a5c37...

Your code has 6 shifts, 6 adds/subs and 6 ANDs.

You can do it with 4 shifts, 3 adds, 1 MUL and 4 ANDs.

Your code is simply suboptimal.

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

#614

Post by gcp »

greyman wrote: post #372
jblow wrote: post #90

#9 is especially stupid because it's so context-dependent. SSE4 gives you a popcount instruction, for example, which would be easily the fastest way to do this, if available.

Yes, but without that instruction, the algorithm mentioned by recruiter is really the quickest way. I coded chess algorithm in the past and this was exactly the method top chess open-source engines used. But imho it is hard to figure that out without prior experience with this problem.

I coded chess algorithm in the past and this was exactly the method top chess open-source engines used.

Your statement is rather vague in time, but for example Stockfish did certainly use the hardware intrinsic at some point. Some of the top closed source engines were using SWAR approaches mixed with loops (when the expected population is 0).

The answer is very dependent on the exact HW architecture and the cache pressure in the surrounding algorithms.

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

#615

Post by djsumdog »

elcritch wrote: post #339
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…

Personally, these questions and the way the recruiter asked them reaffirm my view that Google would not be a place I'd like to work at as a experienced software developer. First the recruiter's lack of technical knowledge points toward a beaurocratic or management first mindset common (necessary?) in such a large company. Second, the questions and expected answers seem biased toward just graduating but smart engineer…

It makes me think there's a screening recruiter, non-technical, before the "real" interview process. At big companies like Google with so many people interviewing, I can imagine these kinds of kick out questions.

Still, it shows a massive company trying to streamline some things and failing terribly. I personally wouldn't want to work at Google today. What might have been cool once is now nothing but a standard large company like IBM or Amazon. There's a great Quora post by some former Google people that say as much.

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

#616

Post by steego »

krzyk wrote: post #597
djsumdog wrote: post #555

Earlier quoted context omitted.

My kick-out questions: "Could you write out what an HTTP request and response looks like on the board?" I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger? "What's the difference between a GET and a POST request?" "W…

Why it is important to know the difference between statically and dynamically typed languages? If one writes in only one of those (or one set) it is not important to him/her and doesn't specifically make him/her a worse programmer in that particular language.

Knowing a cursory difference between a statically and dynamically typed language in this day in age is not an unreasonable requirement for many developer positions, especially web development where you're often using a mix of languages.

As always, this sort of question is a test of competence by proxy and there are usually outliers, but statistically speaking, I think you'll find a very high correlation between inept programmers and people who don't know the difference.

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

#617

Post by kaishiro »

DannyBee wrote: post #547
falcolas wrote: post #527

Earlier quoted context omitted.

> 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 sen…

"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. " This is one reason why i find it super-strange. It's not a set of "high level employee" questions. It's a standard SRE pre-screening. "How about the responses from your own employees which are…

I suspect for someone who has failed - rightfully or not - a recruitment exam in this manner, it may in fact be the only cathartic mechanism.

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

#618

Post by sthatipamala »

spcelzrd wrote: post #576
euyyn wrote: post #369

Earlier quoted context omitted.

> Employees on an H1-B visa have drastically less job mobility than US Citizens. This creates a power advantage for the employer. Yet Google pays the lawyers needed to get you a Green Card as fast as possible.

Yet a Green Card does not give an employee anywhere near the same level of job mobility as a US Citizen.

A green card allows you to live and work in the US without employer sponsorship. There is complete mobility, on par with a US citizen.

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

#619

Post by djsumdog »

krzyk wrote: post #597
djsumdog wrote: post #555

Earlier quoted context omitted.

My kick-out questions: "Could you write out what an HTTP request and response looks like on the board?" I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger? "What's the difference between a GET and a POST request?" "W…

Why it is important to know the difference between statically and dynamically typed languages? If one writes in only one of those (or one set) it is not important to him/her and doesn't specifically make him/her a worse programmer in that particular language.

General domain knowledge. We do Scala and a little bit of Python here and there. You should know the difference to show you're well rounded. Senior devs sound have some experience in both types.

I have a follow up question, "What are the advantages of a dynamically typed language over a statically typed one?"

This one kinda exposes the "Java-zellot" side of programming. If you love Scala and you're applying for Scala position, you don't often think like this. Being able to think critically about the things that are harder in Scala, that would be easier in a language without strict type checking, is a another good way to gauge if people can think critically.

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

#620

Post by dekhn »

bogomipz wrote: post #588
dekhn wrote: post #253

Earlier quoted context omitted.

The goal of a fingerprint hash is to convert an input space of "large" values to an output space where the output space values are much shorter- typically fixed size and two similar input values have effectively random outputs (without spending the CPU cycles to implement a cryptographic hash). This permits a wide range of optimizations (a document can be fingerprinted, and looked up by its fingerprint, to see if it'…

"The goal of a fingerprint hash is to convert an input space of "large" values to an output space where the output space values are much shorter- typically fixed size and two similar input values have effectively random outputs" But this is also the goal of non-crypto hash function like those used in a data structure no? Basically mapping a large space of inputs to a smaller space of outputs. I would say the cryptogr…

both types of hash convert an input space to an output space where (typically) the input space is much larger.

What matters is whether similar inputs get mapped to the same output. For the case where you want to minimize the probability that two inputs which are highly similar land in the same bucket, you want a crypto hash, although those are expensive so you want a cheaper approximation, which is exactly what fingerprint hashes do. The problem is that as the input values counts approach sqrt(output value size), you're going to start getting collisions, and ideally, you want those collisions to be evenly spaced.

In the case of a similarity hash function, you want the opposite, the closer things are in some metric space, the more likely they end in up in the same bucket.

Post reply on HN