I once coded chess playing algorithm for fun, and can confirm that the recruiter was correct on #9: you count bits by using a lookup table and then sum the results. It's the quickest way. But I am not sure if this is possible to figure out immediately without such experience...
Google's “Director of Engineering” Hiring Test
371–380 of 969 posts
Re: Google's “Director of Engineering” Hiring Test
#372#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.
Re: Google's “Director of Engineering” Hiring Test
#373I'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'm just reaching here, but is there a chance at all that the test wasn't really about whether or not he knew the correct answers but more that he knew the correct answers and was able to simplify them to the extent that a non-technical user could understand and compare them? I have a feeling that Google is far more interested in someone being able to get their point across than someone that just wants to sit there a…
If this was the point of the test he should have been told this was the point of the test. Gotcha's make poor interview questions.
Re: Google's “Director of Engineering” Hiring Test
#374Earlier quoted context omitted.
"Dumb recruiter"? What? Nobody's calling the recruiter dumb. Everybody is calling the process dumb. A process that puts somebody that cannot answer these questions, in charge of asking them and evaluating the answers. Having the candidate evaluate the competence of their recruiter is not part of the interview process. What the hell.
I believe in the phone screen Google uses non-technical people to ask technical questions (as engineers are a scarce resource) so they're only able to handle "right or wrong" but you can probably work your way around that by being nice - this guy seemed to be being an ass...
Then do a multiple choice quiz on a website.
Re: Google's “Director of Engineering” Hiring Test
#375FWIW: 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…
Disclaimer: I also work for Google, opinions are my own, etc etc.
> "i always take "transcripts" of interviews (or anything else) with a grain of salt"
I mean sure, a single instance of this might be overblown, exaggerated, or false in some way.
But there is an avalanche of reports like this, to the point where it's become widespread industry insider knowledge.
I enjoy working here, but the interviewing practices are such that I actively warn friends applying/being referred to temper their expectations of a repeatable/reliable process.
Most colleagues I've spoken to about this, including myself, have strong doubts we would have made the cut if we interviewed again - even though all are strong engineers with great perf records.
At what point do we start taking reports like these seriously? We don't have to accept every detail of the reporting as gospel, but there's clearly something here.
Re: Google's “Director of Engineering” Hiring Test
#376On #9, is it 16-bit or 64-bit values? Sounds like you may have been answering a different question. Isn't the standard answer to use a 65536 entry lookup table? Edit: oh, are you reinterpreting the array of 10000 16-bit integers as 2500 64-bit integers? But then what operation do you use on each? Either way, if you find yourself arguing with the recruiter, it's probably a bad sign.
> Isn't the standard answer to use a 65536 entry lookup table?
Yes, it is, but is it such a common knowledge?
Re: Google's “Director of Engineering” Hiring Test
#377I 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 got an interview with Amazon, but failed the first round, because I did not do well on the reasoning part of the online test. You couldn't skip questions, so I spent too much time on some of them and had to rush the ones at the end. They failed me despite getting the coding part 100% right.
Oh well.
Re: Google's “Director of Engineering” Hiring Test
#378FWIW: 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…
This was very similar to my first experience interviewing for an SRE role at Google. After about 20 minutes I got tired of arguing with a clearly non-technical recruiter and politely excused myself.
My second interview well, that was a whole different bucket of problems.
Re: Google's “Director of Engineering” Hiring Test
#379I'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…
It happens because great developers do not do recruiters' job :)
Re: Google's “Director of Engineering” Hiring Test
#380I'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…
I wouldn't be surprised if the interview process for experienced engineers is unrefined.
At this point in Google's lifecycle most of the qualified, experienced engineers who would want to work at Google already do. There are orders of magnitude more new-grad engineers to interview and so it makes sense that they would lack the practice and refinement on those candidates, even if those are the most valuable candidates to hire. The recruiter might have just been confused and gave him the standard list for any "technical" job that they have to use for new-grads and so cannot ask things with nuance.
When I was an interviewer at Google it felt like 90%+ of interviews were with candidates who had less than four years of experience. Probably half were fresh out of college. After the fifth candidate in a row who can't do simple recursion or algorithmic analysis (and I mean simple) you get pretty discouraged. In one phone interview I got to interview an experienced engineer with over twenty years of experience in C. He completed the question I usually have to spend 45 minutes on with a new-grad in <10 minutes. It was probably my favorite interview of all time because I actually got to discuss the subtleties and he reaffirmed that I could maintain high standards.