But can he invert a binary tree?
Google's “Director of Engineering” Hiring Test
81–90 of 969 posts
Re: Google's “Director of Engineering” Hiring Test
#82Have had similar phone screen experiences for various roles, and sometimes the screener seemed to understand that I had a lot more knowledge/experience they did, and trusted my explanations, because I'd talk to them some more and explain the answer (their answer) in more detail back to them. Some of them may have thought I was completely BSing them, but a few seemed to grok I was more than qualified based on the answers and put me through.
Also took a computer-based test at a recruiter once, re: PHP, and it was... 20 questions. One of the questions was wrong, in that the syntax of the question as posted was incorrect. Pointed that out, and got a "thank you, we'll call you" kick out the door.
Re: Google's “Director of Engineering” Hiring Test
#83This is epic. Why would not Google just give a written test and not use a recruiter for this? I do not see the point.
Re: Google's “Director of Engineering” Hiring Test
#84I'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…
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.
Re: Google's “Director of Engineering” Hiring Test
#85I'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…
But what if Google is down and you are tasked with diagnosing it?
Re: Google's “Director of Engineering” Hiring Test
#86I'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.
I only have a sample size of one, but I blew threw a phone interview with Google about a year ago -- and the guy giving it was very technically skilled. We talked about the subtler aspects of the questions as we went. They offered an in-person interview, of course, but I declined when I found out that they were only hiring for Google Payments in Boulder. I'm sure the job has interesting aspects, and maybe my imaginat…
I know someone working in that area--apparently lots of string parsing. It's vitally important (moving money usually is) but not very exciting/cutting edge (moving money usually isn't--after all, it's an old technology).
Re: Google's “Director of Engineering” Hiring Test
#87Ha ha re: > 10. what is the type of the packets exchanged to establish a TCP connection? > Me: in hexadecimal: 0x02, 0x12, 0x10 – literally "synchronize" and "acknowledge". > Recruiter: wrong, it's SYN, SYN-ACK and ACK; if Google is down you will need to know this to diagnose what the problem is. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. Y…
Are you surprised though? If a person who does not have the merit to judge the answers very well this is what happens.
Re: Google's “Director of Engineering” Hiring Test
#88I had very similar intervies at Palantir and Yelp, albeit Yelp was understandably just a quick phone screen with a recruiter. However, the "trivia" interview at Palantir came from a forward deployed engineer on the DC based team I was interested in working with and one of my last hour long, onsite interviews of the day. Seemed like a big red flag at the time.
Re: Google's “Director of Engineering” Hiring Test
#89It 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.
[deleted]
Re: Google's “Director of Engineering” Hiring Test
#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.