Software Engineer How I Got Hired By Google

Two weeks ago I went through the grueling on-site interview at Google in Mountain View. I found out that I did well and the hiring committee approved me. Now I am in the process of project-matching, where members of different teams meet with me by phone and discuss their projects and find if I'm a good fit. After a week of this they already found "a few" matches so I expect everything to go smoothly from here on out in the process. Even if it doesn't though, my advice in this post will still be just as useful to someone trying to get past the on-site interview and get a job at Google. I can't tell everyone how to get hired by Google because this is based on my own anecdote and you don't have the same background as me, but you can still learn a lot from how I navigated the process.

Profile of a Successful Candidate

I want to say first and foremost that you do not need to be a genius or go to the best college. Yes, I am smart, but I'm no smarter than any other engineer. I didn't go to Stanford, I went to the University of Michigan (Ann Arbor). I don't have a PhD, or even a Master's degree, only a Bachelor's in Computer Engineering. I did not focus on Computer Science in school, I only took a couple 200-level courses and one 400-level operating systems course. My GPA upon graduation was just above 3.4, which was not good enough for Google's old interview methods where they cut everyone below a 3.8. I have not even worked as a software engineer for most of my career; I've been a Hardware-In-the-Loop, or HIL, tester for an automotive supplier for longer than anything.

Looking at all that, you might wonder how the hell I even got an interview with Google for software engineering. It didn't happen overnight. I have been applying to Google for years but they have always flat out ignored my resume. I had worked as a network administrator, web/desktop application developer, and HIL tester, not to mention that during college I did a 2-year stint as a direct sales rep for Cutco where I reached the highest promotion (commission) level and also became Branch Manager of my own office. None of that seemed to matter because my "current" job was as a HIL tester, and if I'm such a great software engineer then what am I doing as a tester?

I decided to leave my job as a HIL tester, even right as they were giving me the opportunity to be an expat in Germany for 3 years, which would have given me more money and more interesting work. I even speak German very proficiently, which was a daily occurrence at the German auto supplier, so it would have been an excellent opportunity for me to perfect the language. I passed it up because my passion is not in testing, it is in software development. I only left the field in the first place because the software company I was with was too restrictive and didn't allow me the freedom to learn or do things on my own. I was always falling behind schedule in my projects because there was no passion and I hated being told exactly how to do my job. I felt like the best way for me to master software was to get away from established companies and their outdated processes and learn it on my own. So during the years I spent as a HIL tester I was also busy at work designing, architecting and developing my own open-source applications. I taught myself the best practices of software development by doing everything the wrong way and reading online about how to do it better/more efficiently. I studied other open-source projects to see how they did things and incorporated those practices into my code. This type of learning anyone can do, it just takes a level of curiosity and persistence that not many people have, but if you do have it then you're probably exactly the type of person Google wants!

During those years of software self-study, I learned about all the various and sundry data structures and algorithms first-hand by implementing them all. I was naturally curious about how an AVL-balanced binary search tree worked, so I implemented one myself. I spent weeks on it because I refused to read a guide online until I at least had a working implementation of my own. Once I had my own BST (and accompanying test-suite...I was a tester after all), I figured out that with a few tweaks I could easily use it to implement a Map or even a Set object, so I implemented both of those with STL-style iterators and everything. I made my own Vector class, String that also does UTF-8 parsing, DList, SList, another type of List that doesn't store items contiguously but also doesn't copy all items whenever more space is allocated, etc... Of course there is no practical reason for anyone to implement these things today, given that the STL exists and there are plenty of other open-source libraries that provide such implementations. However, I was curious about how they worked and I learn better by doing than by seeing, so the best way for me to learn them was to implement them and work through all the difficulties myself.

Once I became satisfied that I had learned software well enough I wanted to get back into the field professionally. I applied at Google, among lots of other companies, but they sadly ignored my resume and I ended up getting a job, still in Michigan, as a Senior Applications Engineer. Oddly enough they did not vet me technically at all (no puzzles, coding tests or anything), so I could have been a grade-A bullshitter and gotten that job, but lucky for them I am as good as my resume says. After only 6 months at my new job, I already amassed a great list of accomplishments that proved my software mettle. I did work on every level of the stack - low level real-time processor and FPGA applications up to fully-fledged desktop GUI's in both C++ and C#. I was able to produce results so quickly as to be unbelievable from a project management standpoint. They scheduled 3 months for me to design and develop a new custom GUI application from the ground up, and I ended up finishing it in 3 weeks because of all my open-source experience. They assigned me to develop an FPGA application and accompanying Matlab-Simulink blockset, and planned 2 months for it, which I ended up finishing also in roughly 3 weeks. After only 4 months on the job I had nearly exhausted their entire supply of work and I spent the next couple months idling because we were waiting for a big project to come in. I got bored and had a lot of time to think about my future, and I realized that the only big opportunities for a software engineer are all out West and that nobody over here fully appreciates the value of a highly talented one. So in January I submitted my resume to several companies in California and waited to hear back.

Out of all the companies I applied to, the last one I expected to respond was Google. I applied to SpaceX, Tesla and Green Hills Software in Santa Barbara (who had previously posted at length about the interview itself, but now I have had more time to digest the interview, and I have the knowledge that I satisfied the hiring committee, so I can confidently provide insight into this part of the process and what it takes to succeed.

Breakdown of the On-Site Interview

The specific questions I got are immaterial, and I can't discuss them anyways due to an NDA. I can at least tell you about the spirit of the questions, and how I believe their interview was designed. My on-site consisted of five 45-minute interviews with different people (some people only get four), all of which were technical and most involved coding on a whiteboard. The people who interview you are not the people who decide at the hiring committee, so it's up to you to impress the crap out of them so they take good notes to convey your greatness to the committee, who will never get to meet you in person. Impressing some of the smartest people in the world in only 45 minutes is not easy, and it's something that makes the best of us nervous. To make matters worse, you practically get 0 time to talk about your past accomplishments or experience; all they want is for you to code this persoalan right here, right now.

I'm not going to lie and say I was totally cool and collected. I was nervous as hell, and had spent the previous day in the hotel lying in bed silently meditating from 3pm until the next morning when it was time for the interview. I thought about every question they could ask and how I would respond and made sure I was able to explain every data structure or algorithm. Early in the recruiting process they give you a study sheet that tells you every type of question they might ask, so I spent weeks prior to the interview shoring up my knowledge on everything, and I highly recommend you do the same. You should be going into the day confident that you know everything on that study sheet because the questions will literally come from anywhere. If you're not worried about the types of questions then you'll be able to focus more on the soft presentation skills like building rapport and speaking clearly, which really go a long way at Google. I practically got no sleep that night, but since I spent the whole day in bed I was alert and thankfully not tired at all on the day of the interview.

The first interview was obviously a warm-up, as it was the least CS-intensive. It was mostly focused on the mechanics of writing code in your favorite language (mine is C++) and using code to solve a basic problem. My persoalan was somewhat challenging, and since the interviewer said not to worry about performance my first solution was to guess every possible solution and test if it's true. It turns out there is a much better solution, which I came to after the interviewer and I discussed the persoalan and he provided subtle hints. Then he made me code the solution and pretended he was a compiler and gave me the same feedback that a compiler would until I had an application that built. Then he pretended he was a computer and ran the jadwal and told me the output, which was buggy. After joking that it doesn't run that way in my head, I looked again at my code and found the run-time error he was talking about and fixed it. It was an interesting exercise, and was unique for the day in the sense that nobody else cared about fully-compiling and bug-free code. Everyone else was interested only in the solution in general and writing code that was legible to humans.

The second interview was all about data structures and algorithms, but before we began the persoalan he thankfully asked me about the best project I was working on. He only gave me time to talk about one (I would have loved to talk about five) so I chose to talk about my real-time audio project I'm working on at home. I own DSP and FPGA starter boards which I use together with my PC as an audio processing system. It's still very early but already it has fairly advanced functionality. For me it was the best thing I could talk about because it clearly demonstrates the broadness of my skills. Google is most interested in people with broad, rather than specific, talents. They like you to know a little about a lot, and a lot about a little. So my project demonstrated that I can develop an FPGA system using VHDL, which talks bilaterally with both a PC and a DSP, shuttling data back and forth between them. It demonstrated that I can write a full-fledged desktop GUI in C++ which interacts with the system. It also demonstrated that I can write a high performing bare-metal (no operating system) DSP application in C++. He looked puzzled when I told him about this, and asked at which job I was working on all this. I then emphasized that this is my hobby and nobody is paying me to learn or do this. I bought all the hardware myself and it's sitting in my living room now. I realize not everyone has such a project to talk about, but maybe you should start one! Not necessarily real-time audio, but do something that you can be passionate about which expands the horizon of your technical expertise.

I could have talked about my projects forever, but the second interviewer still had a technical puzzle for me to solve. Like I said it had to do with data structures and algorithms, and would be fairly straightforward if you know how a Binary Search Tree works and you have written algorithms that use them. Since I have my own implementation of a BST at home and have implemented many recursive algorithms to search it, this was not a hard persoalan for me to solve. I did run into difficulty coding the solution however, because I was still warming up for the day and my mind was still partly working on the last interview problem. I got near finishing the solution when the next interviewer had arrived, and he graciously gave me a few more minutes to finish the solution. After that though, I started to feel rushed (not because of anything the interviewer did, but because that's how my mind works) and my mind closed up, I lost sight of the solution and couldn't put on the finishing touches. However, I think the interviewer had mercy on me because I did a good job describing my solution and he knew what I was trying to do. When I told him I was lost in the forest and would need to start the persoalan again, he even grabbed a marker and finished the code for me. I felt awkward about it at the time, like it can't be a good thing that the interviewer had to finish the persoalan for me, but now I know Google is hiring me so it can't have been too bad. Now I even think it was a good sign, like I built enough rapport with him that he wanted me to succeed, so he helped give a complete solution to the hiring committee to increase my chances. After all, the simpulan photo he snapped of the whiteboard did contain both his and my code. So from this experience I learned that success has as much to do with how you present yourself and your solution as it is the solution itself.

The third interview was a system design interview, the only one without coding, which not everyone gets. I got one because with my broad background apparently they saw me as potentially more than just a software engineer (i.e. Tech Lead). I felt honored to have gotten a system design interview, and I did my best despite the system being something completely outside anything I have ever designed before. Actually this was the first interview that I felt I really hit a home run, based on the uber positive feedback I was getting from the interviewer. I can't tell you the system I designed, but I will say that in preparation for the interview I read about how the Google File System (GFS) works, and I was very glad I did! The GFS is a distributed file system developed by Google that supports billions of users, is robust and stays online through massive hardware failures. I don't know how it works in detail, but I know enough about its basic framework to be able to apply it to the interview question at hand.

It's not like I knew exactly right away how to make the whole system, and at first glance it seemed so daunting I didn't even know where to start. But I made the connection early that this is not that different from the GFS, so I said aloud, "Let me think for a second about how the Google File System works and see if I can use any of it here." Then I described what I knew about the GFS and it was all gravy from there. The interviewer immediately said that was a great idea and I should diagram it on the whiteboard. He guided me at every step of the way with the questions he asked, like, "How will you handle this scenario?" or, "How could you make that more efficient/robust/secure?" Looking back I'm astounded at what I was able to design, but I realize I never would have made it alone with just a blank whiteboard. I needed help from the interviewer, and he was more than happy to provide it because I was engaging him in the design process. It felt like a conversation between peers, which I knew was a great sign, so I was on a natural high when we broke for lunch.

You have to be careful not to get too high on your performance in any one interview, since there are more to come and they don't care how you did in the previous interviews. This is one of the things I coached myself on while meditating in the hotel room the day before, because from prior interview experience I already knew the feeling of being humbled by a hard persoalan after thinking I was the greatest, and I knew that my problem-solving performance degrades significantly once I start thinking, "I've got this in the bag." I was also sure that the problems would get harder throughout the day, and indeed that was the case. So I kept a cool head through lunch, never letting myself focus on how well the last interview had gone, but I knew I was doing awesome at that point.

The fourth interview after lunch had two interviewers, a main guy who asked all the questions and a "shadow" who was learning how to interview and also providing feedback on me. Since there were two of them taking notes and the main one was apparently a very good interviewer given that he was pelatihan another, it was that much more important that I stay focused and do well in this interview. It started very simply, he gave me a function signature and described a very basic requirement of the function and asked how, of the million possible ways, might I implement this? It was vague, and was intended to start a discussion rather than provoke me to start implementing something immediately. So we spent 5 minutes talking about various drawbacks of the naive implementations I started with and improved the solution until eventually I proposed using a background thread to do it. We discussed different ways it could be done using multiple threads, each had their pros and cons, until I arrived at the "best" one, and he then wanted me to implement it on the spot. If you have never done multithreaded programming then you wouldn't have stood a chance. Thankfully due to my open-source experience I have already implemented several multithreaded solutions, so this was a piece of cake for me. I very calmly penned out my solution on the whiteboard, describing it as I went. It used mutex locks, wait conditions and a hidden bonus data structure that you get extra points for if you know you need it. To pass this interview you really needed to have thorough knowledge of multithreaded solutions, but it was made much easier because he let me use any libraries or API's I want. He said, "Just tell me what classes you need and describe the interface, and you'll have them." Since I use Qt so often, I chose to use all Qt classes, and even invented one that doesn't exist, but he let me do it because it was that "bonus" structure I mentioned, and it was only important to him that I recognized that I needed it.

I finished the multithreaded solution with 15 minutes to spare, so I got an entirely new question, completely unrelated to the first (I knew that was a very good sign because the more questions you get to answer the more information they can relay to the hiring committee). It was another basic coding persoalan designed to be easily solvable in under 10 minutes and if you know your Computer Science you'll do it in the most efficient way the first time using the proper data structure.

The fifth and simpulan interview was the hardest of the day, in no small part because I was getting tired of interviewing, but the problems were also the hardest. I tried to let my brain relax in the few moments between interviews, but wasn't very successful. When they told me the next question I about died thinking about how much work it would be to solve it. I thought for a moment, "That's it, this is where I fail. This is where I spend all 45 minutes scribbling incoherent nonsense on the board and never arrive at a functional solution." While I thought about how much effort it would be, I started to think that maybe there's a simpler way. It's no secret that good engineers are lazy, and they try to design things so that they are easy to implement and maintain. In my desire to avoid work I actually came up with a brilliant solution that turned out to be the best one (I know because I looked it up afterwards). I felt like such a pro, because I knew that 99% of software engineers would have done it the obvious but painful way and I saw how to do it in an indirect but very efficient and easy to implement way. It just took keeping a cool head and knowing some key CS concept and applying it to the problem. I knew I did well too, because the interviewer had basically no follow-up questions for me, as I was preemptively answering everything I knew was coming. "This solutions is O(N)," or "I know this isn't 100% correct but to handle the special cases I would do this..."

I also finished that question with time to spare so he gave me another completely unrelated question, which again I took to be a great sign. It was a basic search question, but to find the optimal solution took a bit of work. I was pushed to my mental limits by that point of the interview, but I still managed to solve the persoalan conceptually. The time ran out before I could code the whole thing, but I wasn't worried given that I had dominated the persoalan before it and he had said it didn't matter if I couldn't finish, just take it as far as I can.

The Hiring Committee

My story would not be complete without mentioning the letter of recommendation my boss wrote me for the hiring committee. Letters of recommendation won't help you get past the on-site interview, but they will help you at the hiring committee. I felt in my case it was especially important given that I was only at my job less than a year. Believe it or not, due to having a great relationship with my employer I was able to elicit the most awesome letter from my boss, which gushed over my various accomplishments in such a short time of employment. I don't know how much letters of recommendation actually make a difference, but I felt like mine sealed the deal for me. They like to see that you have a good relationship with your current employer, and they will in fact call your references.

There was one oddity with the hiring committee that I can't find anything about online. I was told by my recruiter that it took them an extra day to come to a decision on me because I was a "special case", and they needed a second opinion for approval. I asked what made me a special case but they didn't say because the process is confidential. Whatever it was, I feel humbled that I was able to get approval from two Google hiring committees.

How I Succeeded

Looking back at the interview as a whole and the questions I got, I realized that nothing in my "real" job would have prepared me for this type of interview. All of the problems I solved used concepts that I learned from developing open-source applications on my own time. So you can't rely on your job experience and think that you're "senior enough" that they won't care if you can't use mutex locks correctly. I never implemented a multithreaded application as a professional software developer, I have only ever done it in my own applications and it was because I wanted to learn how to do it, not because anyone was paying me.

I also noticed that I used hashes or hashing concepts in 4 of the 6 interviews (including the technical phone interview) and again I never learned about hashing on the job. Sure I used dictionary or hash_map types but I never needed to worry about how they worked I just consumed them. I learned the most important lesson about hashes while implementing my open-source Universal Chess Interface, because chess programs can use a look-up table during the opening moves to figure out the best move without having to calculate all the possibilities. This is called an "opening book" and it works by creating a hash value for the position of the board, incorporating the positions of all the pieces and whose turn it is, among other things. It magically combines all of this positional information into a seemingly random 64-bit integer that you can use to instantaneously (i.e. O(1)) look up the best move from a table. Being able to apply that knowledge, that you can encapsulate a large chunk of information into a small piece of data for comparison, was critical to me doing so well in the Google interview. They list this very prominently on the study sheet they give to candidates, so take it seriously!

You should be confident with what you know, but not arrogant. If you get a tough problem, acknowledge that it's tough and try to solve what you can, the interviewer will help you if you're vocal and they know what you're trying to do. If they ask about a topic you know by heart, pretend you're a teacher, go into presentation mode and describe everything you know - they want to know how deep your understanding goes, and will often push you to your limits to find out.

Lastly, don't panic and don't elate yourself in any circumstance; do your best to keep a cool head. It helps to psych yourself into thinking that you're at least as smart as your interviewer (again watching out for arrogance because chances are, you're not), but the best way to avoid panicking is to be well prepared. The Google recruiters do a great job of helping you prepare for the interview. They tell you every topic you need to study and the good websites to go to for practice. A week before the interview there was a hangout session with a Google engineer who gave all the candidates advice on how to do well at the interview. So it's clear they want everyone to succeed; they're not trying to exclude anyone. They wish everyone would pass the interview but the reality is most people won't. I am really glad I did, and I hope my advice helps you in your own quest for employment at Google.

Share this post