Interviewed at Google Pt.2

Some people asked me why I wasn't publishing the second part of my Google interview experience. Well I didn't care so much about Google and job interviews in general after I moved to Norway. Anyway, I finished the whole blog post back in September at the airport in Zürich. So you might as well read the rest.

So lunch was great. Google has his own canteen with dedicated cooking staff etc. There is a salad bar, free drinks, desert and 3 dishes to choose from every day. Not bad. The canteen was packed when we went. It must have been 200 people or so.

Anyway, after lunch the next interview was again with two people, of which one was talking and the other one listening. This time I had two coding exercises in the interview. The first one, was to come up with an implementation of a class, which you could send a function or a block of executable code to, that should then be executed after 34 seconds. The second exercise was to suggest a unit test for a function producing random floats values between 0 and 1. For the first task I picked Java as concrete language and suggested using a ThreadPoolExecutor, Callable and Thread.sleep. The interviewer asked me, how we could bring down the test execution time, as we did not want to wait 34 seconds every time the test runs. I suggested having the time span configurable, so that it would fire after the configured amount of seconds. A better answer would have been to refactor the code, so that it was given an instance of a class representing a clock. I knew the clock test pattern but I was not able to pull it out in this situation - too bad. As for second task, testing random float values, I suggested creating a test set and group/count the values using some array indices. The test validation should only allow a certain degree of deviation. The interviewer then asked me how to calculate the deviation based on the input size but it was out of my league and I could not answer. For the correct answer you need some good knowledge in statistics I suppose. This was probably the worst interview I gave this day. It was also a bit harder for me because the interviewer had a very strong French accent. I had to ask him to repeat a couple of times, which might have been annoying for him. This is particular maddening because a co-worker I worked with for 3 years was French, so I should have been used to French-English.

The next interviewer was from Poland. He was a very cool guy and very friendly. We talked a bit about Apache Cassandra, which I had mentioned in my CV, since he knew one of the Facebook developers working with Cassandra. The coding exercise he had for me was about a graph problem. He gave me a class data-structure holding a list of File objects. The Files were supposed to have references to each other, pretty much like edges in a graph. I was given the task to print out the Files in a specific order. Unfortunately I understood him wrong and suggested a standard DFS traversal. But he was interested in a very specific order, which required a modified DFS approach. It was a nice interview anyways and he told me I was actually the first guy who had implemented a DFS using a stack and that he liked it. Well, I thought using a Stack for DFS was the default way, strange.

Time went by and after 45 minutes I found myself again in a very test-orientated session. The first 20 minutes or so, I was asked a lot of test related questions like "How would you do performance testing and let the development team know about the results?". My gut feeling was that I didn't give very great answers to these questions. Basically in my previous companies we never had an organization, where there was a unit of Software test engineers supporting the main developers. It is often the developer itself who does the performance testing and has the results at hand.. At least at this point, I realized I should have prepared myself more for test related questions since this was a Software Engineer in Test position after all. In my preparations I spent most time focusing on solving technical questions. But okay you never know this in advance. The final coding exercise in this interview was to come up with a suggestion on how to verify a file backup (directory structure) so that it matches a given source directory. I suggested to create an abstraction for each physical file or directory which would store the filename and a checksum. Then you could do a traversal of each tree, building up two linked lists. Finally you start removing the first item in each list and compare the items. If they don't match, it is either the directory structure that was wrong or something with the files. As the last step, I had to implement this in a language of my choice. I used again Java.

After a long day, the final interview started. A very nice girl, who worked with the Google search as a Software engineer, started to ask questions about my current job position. Surprise, this was actually the only time someone showed interest in what I was currently doing. I spoke about our system, the problems which we had and have. She asked me questions like "What happens if the database fails in this case?" and so on. I think she was testing my overall understanding of how different parts of a software system affect each other. The second part of the interview was performed as a code review. She had printed a function in Java and I my task was to review it. It was easy enough to find most of the potential issues like using static members (testability), not validating input, thread safety, going over the index bound of an array etc. I mixed up the explanation for bitwise XOR with AND, embarrassing but hey you are nervous. After doing the code review I had to rewrite a recursive function call into a iterative one, which I somehow managed. When the time was up, we said goodbye and she guided me out of the Zürich office building.

So what do I think about the interview? I think it was a great experience. I met nice people and they showed me some of my weaknesses. The preparations I had done upfront helped me only to some extend. There were less technical questions, no behavioral questions and definitely no questions about me or Google's history. A better preparation would have been to read some books on Software testing and less books about algorithms and data-structures.

So much for the second part. Here is something I am adding to the text I wrote 9 months ago. Never add technologies to your CV which you only know superficial. This can get you into embarrassing situations. Less is more. I have seen CV's for candidates who have worked with everything that exists out there - not good. For a Google interview, I think it is a plus if you know more than one language. Back then I was a Java only guy more or less. It's great if you can Python, C or C++. Some of my whiteboard examples where too Java specific, i.e. when using something like ThreadPoolExecutor take a step back and talk more about concepts than JDK classes. Don't expect every interviewer to know the language you are good at. Finally, expect to be disappointed if you fail. This can hit you hard, especially if you are used to getting a job offer every time you been to an interview.