quicksort is O(n^2) which is definitely not the "best big-O" for sorting.
quicksort is O(nlogn) average case, and O(n2) on already sorted arrays.
Google's “Director of Engineering” Hiring Test
101–110 of 969 posts
Re: Google's “Director of Engineering” Hiring Test
#102I'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.
This strikes me as an interview with a recruiter. This is almost definitely not a legitimate Google interview.
Maybe it was for a vendor/contractor position.
Re: Google's “Director of Engineering” Hiring Test
#103The 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?"
Yah I get the feeling you're supposed to "act stupid" so you can get to the next interview. Definitely not an idea way of getting candidates - you are selecting for people who know how to manipulate screens (and thus increasing the risk of getting a bad candidate), or rejecting otherwise knowledgeable people who just don't have the time/inclination/"social savvy" to pretend to be stupid.
Why not? Especially in a managerial position, you will occasionally need to build a rapport with people who are convinced they have good technical knowledge, but don't. Being able to talk to them productively instead of picking fights is a skill worth selecting for.
If you can't figure out that the first person who's interviewing you has answers on a sheet of paper and you're supposed to parrot them until you get to the second person, how are you ever going to figure out that the first person you're selling to has some business requirements on a sheet of paper and you'll never get to the second person until you parrot those?
"Oh, we're not actually using Docker, we're using rkt, which is a compatible reimplementation of --" "I'm sorry, I've been told Docker is a requirement. We can't use your Cuber Netty thing until you support it. Bye!"
Re: Google's “Director of Engineering” Hiring Test
#104The 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?"
At that age, it becomes way more satisfying to educate somebody, rather than try to force your way in.
Re: Google's “Director of Engineering” Hiring Test
#105While there is a notion that devs are in demand for a company like google they have so many candidates that can be dicks to people and get away with it.
Re: Google's “Director of Engineering” Hiring Test
#106This is 75% similar to a phone screen I passed (somewhat surprisingly, in hindsight) in 2003-2004. I don't think this is a director-level test, it's just a coarse engineer-track filter.
Re: Google's “Director of Engineering” Hiring Test
#107I would agree with "metadata" answer being correct.
"Each inode stores the attributes and disk block location(s) of the filesystem object's data." [1] A file's "attributes" are independent of its storage. One could also argue the notion that a FS object's ACL are attributes of the file.
Re: Google's “Director of Engineering” Hiring Test
#108I'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've been responsible for writing network code on embedded systems, you do end up memorizing lots of the structures and constants from the specification because you're constantly looking at them "on-the-wire" to make sure it's write (or debug it if it's wrong).
Re: Google's “Director of Engineering” Hiring Test
#109I'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 had exactly the same kind of quiz at the beginning of the year on a Google phone screen interview. Some questions were exactly the same. I passed apparently but declined the in person interview. The recruiter over the phone was way more technical though and accepted answers not strictly matching his response sheet (and was able to discuss the technical whereabouts)
Re: Google's “Director of Engineering” Hiring Test
#110Early in my career I got asked a question about database reporting on sales items and totaling the number by a given date. This was one of the hardest questions I was ever given because I had to "write" the sql out over the phone and was not given a schema so I had to make one up as I went. I was then asked how I would go about writing one that included $0 sales days. At the time I didn't know the answer to this -- just that querying for something that doesn't exist is not straight forward in sql. I explained that I didn't work much with reporting so I had not encountered this solution before and gave a list of possible answers:
* Generate a complete list of dates in memory and see which do not exist. * Create a temporary table to match it up that way. * Do post-processing on the report. * Research prior art.
I was not offered the job.
Years later I was given the task of creating a "data warehouse" to enable easy reporting by business analysts so they could stop bothering the engineering team. So, it being the first time I had done this, I read up on different techniques. I solved the problem the previous interviewer proposed by have a table of dates with attributes on them (is weekend, is national holiday, day of week, etc) and all dates foreign key to this table.
However, because I couldn't think of this solution within a few minutes -- despite it not being in my background -- I did not get the original job from years before.
In many ways, I'm thankful the original interviewer passed upon me. I was able to get a different job that valued being able to think of creative solutions AND being able to research prior art so we don't invent a badly designed wheel over and over again.
I suspect the author of this article will experience the same feeling with time and it is a real shame companies are valuing root memorization and keyword matching over real problem solving skills.