Software Engineer My On-Site Interview At Google
I just got back from my trip to the San Francisco bay area to interview at Google. Overall it was a very positive experience, and I think I pretty much hit it out of the park but we'll find out for sure in the next couple weeks. I want to write about my long day of interviews, partly for my own future recollection and partly to help anyone else interviewing there for the first time. Unfortunately I signed a NDA so I can't give you any specific details of the questions or their solutions, but from my account you will at least see the types of questions I was asked. The day was divided into five 45 minute interviews, three before lunch and two after. Some of them went better than others, but on the whole I got very good vibes.
After the third interview we broke for lunch. I am funny when it comes to food, so I actually don't eat lunch normally, and I have a highly restricted diet due to health reasons. Therefore, my host and I decided to walk around the Google campus instead.
We walked all the way to the Googleplex, stopping to sight-see in a few places. I saw an open field owned by Google where people were playing soccer, and an area for weightlifting and other outdoor activities. There was a playground where there was an on-campus child care (apparently it is prohibitively expensive to most Google employees though). I saw a complimentary valet parking service for employees, so they can optimize the use of what limited parking space they have, and so engineers/managers don't waste valuable time searching for parking. Of course I also saw the colored bikes everywhere, helping people get around campus. Just grab a bike and ride, then leave it in any of the reserved GBike parking spaces or racks. Helmets are found (and returned) in any lobby of any Google building.
It was really a gorgeous campus, and even though it was rainy that morning (in a drought, the one day it had to rain!) the skies cleared up and the sun came out by the afternoon. I was really happy I got to wander around and see all the cool buildings and see what a bustling campus it is around lunch time. We walked through a crowded courtyard and I asked my host what percentage of the people did he know in that courtyard and he said roughly 0%. That gives you an idea of the sheer size of Google's workforce.
Arrival and First Impressions
My interview was in the YouTube building, and that was immediately apparent by the room names. My room was called "Pork and Beans", which I guess is a viral YouTube video but I've never seen it. It turns out all the rooms are named after viral YouTube videos, like "Charlie Bit My Finger" and "Star Wars Kid". I am not a YouTube aficionado so I only recognized a few of them, but I found it really cool that they do that.
As I walked to my interview room I saw some very interesting things in the office. One cubicle had no chair or computer, and the desk was filled with a Lego structure that someone was working on (it was a fancy bridge and something else I can't remember). They had a full kitchen on every floor, stocked with everything from milk and cereal to coffee to fresh fruit to candy. They basically stock it with everything people like to eat, so I can totally see why nobody needs to grocery shop if they work at Google. There was a massage room, not a temporary one like once per week as I've seen at other companies, they had their own room dedicated to it and there are massage therapists there every day. I also saw a video game room with a big screen and all kinds of games and systems. It was like no other office I've ever seen, it was very impressive.
Interview #1
All of the interviews were done on a whiteboard (as they had warned us beforehand). The first interview I guess was a warm up, because compared to the other interviews it was very basic. It focused mainly on the semantics of coding in my favorite language: C++. The duduk kasus was fairly straightforward, but the interviewer was very particular about writing code that actually compiles, and made me correct everything, down to the matching squiggly braces. He had me solve the duduk kasus first without caring about efficiency, then analyze the asymptotic complexity, then come up with ideas of how I could make it more efficient.
This was the only interview that I had mixed feelings about, because while I do have great puzzle solving skills, I have difficulty demonstrating that when someone is watching me write code on a whiteboard. When I write code I do it on a computer with nobody watching, then I can write code freely while I study the duduk kasus and eventually come up with something that works. When you write code on a blackboard, you don't have the luxury of experimenting with various snippets of code, so you have to do it all in your head. That's what gave me trouble, because going cold into a coding duduk kasus you don't have all of your faculties primed yet for that kind of duduk kasus solving. So I eventually came up with a good solution, but I could tell the interviewer was not very impressed with my speed. I felt bad, but didn't have time to worry about it because the next interview started and I immediately had another question.
Interview #2
The second interview started with an opportunity for me to talk about one of my projects. I chose to talk about a real-time audio processing system I'm working on. I was glad somebody asked about it because it really involves all of my skills. Several Google engineers told me they're interested primarily in generalists, people who know a little about a lot, and a lot about a little. So I talked about a real-time system I made that involves a digital signal processor (DSP) connected to an FPGA, connected to a desktop PC, thus demonstrating my embedded coding, DSP, FPGA and desktop GUI experience. At first the interviewer thought it was something I was doing for work or something, but when I told him it's my hobby and it's sitting in my living room right now he got really excited.
Then I was given another coding duduk kasus to solve. It involved a binary search tree, and was primarily focused on the data structures and algorithms, so he didn't care about the syntactical correctness of my code. It was not very difficult if you're good at recursive algorithms and understand how a BST works.
Interview #3
I really enjoyed the third interview a lot. It was not a coding duduk kasus but a system design problem. The interviewer wanted to see how I would design some kind of complex system. Such a system would be very difficult for most people to design, because it requires knowledge in many different fields, like networking, databases, algorithms and distributed systems, to name a few. This is where I really hit my first home run of the day.
It started out with a description of a potential new system at Google, and it needed to be able to support specific use cases within certain parameters. As I articulated the system, he occasionally stopped me with follow-up questions to dig into the depth of my knowledge and also to help shape the design of the system. It then turned into a conversation among peers about the highly technical subject matter, and I kept pace with him and I think exceeded his expectations because of the feedback he was giving me. After several design choices I made he said, "Excellent choice, I like that a lot", or some variation of that, and scribbled furiously in his notebook. I also preemptively recognized the risks and limitations of my system, which he also was very happy about. In the end he told me that I did extremely well and I made a great system.
A few days prior I did an interview workshop that was facilitated by Google to prepare us candidates for the interview. During the workshop they said that not everyone gets system design questions, but if you do then it's because Google is looking for you to be able to solve such problems in your potential new role. That made me feel great because in the area they were looking for me to shine I shone with flying colors.
Lunch
We walked all the way to the Googleplex, stopping to sight-see in a few places. I saw an open field owned by Google where people were playing soccer, and an area for weightlifting and other outdoor activities. There was a playground where there was an on-campus child care (apparently it is prohibitively expensive to most Google employees though). I saw a complimentary valet parking service for employees, so they can optimize the use of what limited parking space they have, and so engineers/managers don't waste valuable time searching for parking. Of course I also saw the colored bikes everywhere, helping people get around campus. Just grab a bike and ride, then leave it in any of the reserved GBike parking spaces or racks. Helmets are found (and returned) in any lobby of any Google building.
It was really a gorgeous campus, and even though it was rainy that morning (in a drought, the one day it had to rain!) the skies cleared up and the sun came out by the afternoon. I was really happy I got to wander around and see all the cool buildings and see what a bustling campus it is around lunch time. We walked through a crowded courtyard and I asked my host what percentage of the people did he know in that courtyard and he said roughly 0%. That gives you an idea of the sheer size of Google's workforce.
Interview #4
After "lunch" was over, I immediately started the fourth interview. This time there were two interviewers, one "real" interviewer and the other was shadowing him, learning how to conduct an interview himself. The shadow was taking his own notes though, so even though he didn't speak I still had to impress him as well as the real interviewer.
And impress them I did. I really liked the duduk kasus they gave me, which was one part planning/design and one part coding/implementation. He started by asking me to implement a function that did something interesting, which could be implemented a million different ways. So I kept coming up with ways to implement it, and he kept asking about the strengths and weaknesses of each way, then asking me to improve on it. So I started with a very basic implementation and ended up implementing a fairly complex multithreaded class by the time it was done. I was really hoping I would get a multithreaded duduk kasus because I wanted to demonstrate those skills. It was something I learned about in college but perfected in my hobby code. I made it clear to them that I not only knew how locks and wait conditions work, but I had lots of experience developing multithreaded applications.
But that wasn't the end of the interview. I completed the first duduk kasus with 15 minutes to spare, so they gave me another one. It was a simple string searching duduk kasus that was nowhere near the complexity of the first problem, so I could tell it was just "filler" to pass the time until the next interview. Nevertheless I worked hard at it and churned out the optimal O(L) solution on my first try. I felt the fourth interview was another home run for me, but I didn't get feedback like I did from #3. They mostly kept their reactions to themselves, but whenever I said a key phrase, like when I identified the proper data structures to use, they would scribble furiously in their notebooks so I knew I was doing well.
And impress them I did. I really liked the duduk kasus they gave me, which was one part planning/design and one part coding/implementation. He started by asking me to implement a function that did something interesting, which could be implemented a million different ways. So I kept coming up with ways to implement it, and he kept asking about the strengths and weaknesses of each way, then asking me to improve on it. So I started with a very basic implementation and ended up implementing a fairly complex multithreaded class by the time it was done. I was really hoping I would get a multithreaded duduk kasus because I wanted to demonstrate those skills. It was something I learned about in college but perfected in my hobby code. I made it clear to them that I not only knew how locks and wait conditions work, but I had lots of experience developing multithreaded applications.
But that wasn't the end of the interview. I completed the first duduk kasus with 15 minutes to spare, so they gave me another one. It was a simple string searching duduk kasus that was nowhere near the complexity of the first problem, so I could tell it was just "filler" to pass the time until the next interview. Nevertheless I worked hard at it and churned out the optimal O(L) solution on my first try. I felt the fourth interview was another home run for me, but I didn't get feedback like I did from #3. They mostly kept their reactions to themselves, but whenever I said a key phrase, like when I identified the proper data structures to use, they would scribble furiously in their notebooks so I knew I was doing well.
Interview #5
Going into the fifth interview I was super confident. I had just obliterated the last two interviews so I was ready for anything. I was kind of hoping for another system design question so I didn't have to code anymore, but that was not my fate. In fact the last problems I got were the hardest of the day. When he first told me the duduk kasus I almost shit myself. It was seemingly impossible, at least to do on a whiteboard in 45 minutes. I even attempted to get out of it because it involved a binary search tree and I had already solved a BST duduk kasus that day. He said, "Thanks for letting me know, but we'll do it anyways."
After resigning to not being able to escape the problem, I tried to relax and focus. It popped into my head that I could represent the duduk kasus in a different way and it would be much simpler to solve. I didn't know it at the time (it only occurred to me after I had time to reminisce on my solution), but the solution I came up with used dynamic programming concepts. That essentially means that it solves the duduk kasus by breaking it down into separate, simpler problems and solving those instead. In the end I solved the duduk kasus with 10 minutes to spare, so he gave me another filler duduk kasus that had to do with search, and had me go as far as I could until the time ran out.
I also felt the fifth interview was a home run, because even though I panicked at first, I quickly recovered and came up with the optimal solution to a dynamic programming problem, and I still had time left over to start a second problem.
After resigning to not being able to escape the problem, I tried to relax and focus. It popped into my head that I could represent the duduk kasus in a different way and it would be much simpler to solve. I didn't know it at the time (it only occurred to me after I had time to reminisce on my solution), but the solution I came up with used dynamic programming concepts. That essentially means that it solves the duduk kasus by breaking it down into separate, simpler problems and solving those instead. In the end I solved the duduk kasus with 10 minutes to spare, so he gave me another filler duduk kasus that had to do with search, and had me go as far as I could until the time ran out.
I also felt the fifth interview was a home run, because even though I panicked at first, I quickly recovered and came up with the optimal solution to a dynamic programming problem, and I still had time left over to start a second problem.
Overall Impressions
I was really impressed with the Google engineers I met. They were all very smart, well spoken and friendly. I did notice the lack of female engineers (the interviewers were all men), but I'm used to that from my computer classes in college. The campus was one of a kind and seemed like a place I would really like to work. I really hope they extend an offer and move me to California, that would be my dream come true. Stay tuned for updates as I should hopefully find out in the next couple of weeks!
Advice to My Fellow Software Engineers
If you read this post and you're thinking, "There's no way I would be able to answer those questions," fret not, it can all be learned. It helps to have a degree in computers, either CS or CE, but it really requires putting effort into learning outside of what you do at work. Looking at my resume you would see that I spent most of my career so far as a hardware/software tester. There is no way I would have gained the skills to answer their questions by simply doing my work and going home at the end of the day. I designed and wrote my own hobby applications on most weekends, creating my own problems and solving them myself. I implemented my own versions of many data structures you study in your algorithms courses (BST, Set, Map, Heap, DList, SList, Vector, String etc...) so I know intrinsically how they all work and how to use them. Anyone can do that, it just takes devoting your time to it. I literally spent months implementing and testing them all, and nobody was paying me; in fact I gave away all my code for free under an open source license. The payoff is getting a great job because you know how everything works behind the scenes. So be curious, reinvent the wheel, design and implement your own systems and do it all for free because from what I've seen it is far more impressive to companies than anything you do at your "real" job.
