Google's “Director of Engineering” Hiring Test

Early 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.