Software Engineer Next Steps Of The Google Interview
I went through the technical phone interview at Google, and it went well! They just called and said I made it to the next step, which is an on-site interview at the Googleplex. I have to say that the technical phone interview was an incredibly positive experience. I got the impression that the interviewer actually took time to read my resume, and I was very impressed with the thoughtfulness of their questions. It turns out I was way more nervous than I needed to be for this part of the interview process.
I spent the last 2-3 weeks studying my ass off, filling in the few remaining gaps of my software knowledge and solving tough programming puzzles on Project Euler and TopCoder. Most of that preparation was basically useless for this first technical interview. I could have easily done the technical problems they gave me blindfolded. The point of this interview was not to quiz data structures and algorithms trivia, but to make sure I am what I say I am: a senior applications engineer. It was the kind of stuff you know by heart if you claim to be a software engineer. Of course, this is only one account of a Google interview, taken from a senior engineer's perspective who already has 5+ years of industry experience. I'm sure they would ask different questions if you're coming straight out of college, because they can't trust any of your prior experience to appraise your value as an engineer. But for me it was more like they were making sure I'm not lying on my resume by striking up a technical conversation about things in which I claim to be an expert. Then they can see how deep my knowledge goes by the way I answer the questions.
For example, we had a conversation about hash functions, not because they explicitly mentioned hashes, but because they asked how I would design a certain kind of system, and to me the best answer was to use hashes. Then they probed how deeply I understood hashes by asking about the properties of a good hash function for this hypothetical system. I would love to divulge the exact line of questioning, but I want to respect the confidentiality of the interview questions, and I'm afraid it wouldn't help you anyways because they were not all planned questions. The interviewer was firing from the hip in response to my answers. So the more knowledgeable you are on a subject, the deeper technical questions you will get and the more bonus points you get for knowing the answers.
What surprised me more than anything was the first question I got, because it was not technical. They asked about the first job on my resume: when I used to sell Cutco knives during college. I wasn't just a successful salesman in the drect-sales organization, but during the summer of 2007 I opened my own branch office in Grand Rapids, MI. I used my late grandmother's inheritance to pay for everything myself, including office rent, furniture, utilities, advertisements for new candidates, etc... I interviewed hundreds of candidates and personally trained more than 50. After the initial 3-day pembinaan seminars I ran each week, my reps came to ongoing pembinaan meetings twice a week in which I gave recognition to those making sales, and gave mini-lessons on topics like how to increase your average order size or closing ratio, or whatever I felt the team was struggling with. It was a great undertaking but also incredibly risky, and in the end for me it was not incredibly profitable. But the experience was once in a lifetime; you don't get that kind of experience any other way and it looks incredible on a resume, especially if you're an engineer.
So the first question I answered was (paraphrased), "Tell me in your own words about your Cutco sales/management experience, and how it has made you a better engineer." That was the perfect question for me, it was like they were setting the ball for me to spike it. I got to explain how I used to be very quiet, introverted and lacked confidence, but when I started selling Cutco I made it a personal challenge to improve my communication skills and get better at working with people, and that is what broke me out of my shell. Now I'm an expert communicator and orator, soft-skills which are invaluable in an engineer.
Apparently those types of soft-skills are what Google is looking for in their engineers. If you can find a way to highlight that on your resume, so much the better. It impressed me that they even noticed that part of my resume, because it was direct sales experience buried under 4 other technical jobs that I've had. Most companies (including the one I work for now) do not even notice it until I point it out and explain it, but even then it doesn't resonate with them the extent to which I actually started and ran my own profitable business.
After the first question broke the ice, they went right into a simple coding problem. Without telling you what it was, it went something like this: Write a function in your favorite language (it must be a real language, no pseudo-code) that has the given signature and does something interesting. It was super-simple, with the purpose only to make sure that I know the basics of the language I chose. But then they constrained the persoalan by saying that this will run on an embedded device where runtime is precious, so how would you change the algorithm? Okay and now the input value is 16 times wider than the original, how would you accommodate that? What about if memory was not an issue? Again, these are things that should occur to you intrinsically if you have the right software experience.
The next coding persoalan involved writing a class (I told them I was good at object-oriented programming, so OOP questions I got). The class has to contain a collection of items and have two functions that change the collection in some interesting way. The naive implementations were very easy, and gave me a chance to show how well I know C++ by using templates and some STL containers. Then they asked how I could improve it, and every time I came up with something they said, "Very good. Now make it better." up until the point where both functions were O(1), and even then they wanted me to think of another way to do it. It really pushed me to the limits, and that was the apparent purpose of the question. They wanted to see how well I really understood the asymptotic complexity of functions and to see what kinds of things occur to me to improve it. One of the solutions I came up with improved one function at the expense of the other, which I was quick to point out and earned even more points for saying it before they did. Even though the simplest and most obvious implementation eluded me at the time, I still impressed them by coming up with some creative methods, and demonstrated that I have a thorough understanding of the consequences of my code.
The last question I got was a real curve-ball, but I knew I was doing well because they told me to expect 2-3 questions and I had already gotten 3, or more if you count all the follow-up questions. So the fourth question I got had role-playing, with me in the role of project manager. They wanted to know how I would measure and prioritize a certain metric of development progress - WHAT?? I thought I was applying for a software engineer position, and they're asking me questions about managing a project?! Combining my soft-skills and engineering skills and applying it in a management role has been a long-time career goal for me, and at Google no less! So when they asked that last question I just about died. I can't even remember what I said anymore because I was so unprepared for the question, I gave one or two good responses but they wanted more and I kept thinking of different aspects of the same things. I can't feel too bad about my response, because just the fact that they asked that question makes me feel awesome.
Going into the interview I was nervous, because of some of the things I read online about how they ask really obscure Computer Science questions, even to senior engineers who don't generally care about that stuff because everything is already implemented in a library somewhere. I was happy to find that that was not the case; all the questions I got were incredibly relevant for software engineers and they stuck to the areas of my purported expertise. I was relieved they didn't make me implement an AVL-balanced binary search tree, or do a breadth-first search on a graph or find items in a trie (although they might if/when I do the onsite interview...who knows?) I think you can see that this is not something worth cramming for, because the questions can come from any direction, and they will easily be able to spot if you only have an ankle-deep understanding of the concepts. Again, this is only one account of an industry professional, so graduating students probably have a much different experience and I don't have any advice for them. But for all you other industry pros out there, I think the best way to do well is to relax, have a resume that speaks for itself and actually be what you say you are.
I'll update again after the on-site interview. I've never been to the bay area before and I'm sick of Michigan winter, so even if I don't get the job I'm excited about a free mini-vacation out west. I'm off to Mountain View!
I spent the last 2-3 weeks studying my ass off, filling in the few remaining gaps of my software knowledge and solving tough programming puzzles on Project Euler and TopCoder. Most of that preparation was basically useless for this first technical interview. I could have easily done the technical problems they gave me blindfolded. The point of this interview was not to quiz data structures and algorithms trivia, but to make sure I am what I say I am: a senior applications engineer. It was the kind of stuff you know by heart if you claim to be a software engineer. Of course, this is only one account of a Google interview, taken from a senior engineer's perspective who already has 5+ years of industry experience. I'm sure they would ask different questions if you're coming straight out of college, because they can't trust any of your prior experience to appraise your value as an engineer. But for me it was more like they were making sure I'm not lying on my resume by striking up a technical conversation about things in which I claim to be an expert. Then they can see how deep my knowledge goes by the way I answer the questions.
For example, we had a conversation about hash functions, not because they explicitly mentioned hashes, but because they asked how I would design a certain kind of system, and to me the best answer was to use hashes. Then they probed how deeply I understood hashes by asking about the properties of a good hash function for this hypothetical system. I would love to divulge the exact line of questioning, but I want to respect the confidentiality of the interview questions, and I'm afraid it wouldn't help you anyways because they were not all planned questions. The interviewer was firing from the hip in response to my answers. So the more knowledgeable you are on a subject, the deeper technical questions you will get and the more bonus points you get for knowing the answers.
What surprised me more than anything was the first question I got, because it was not technical. They asked about the first job on my resume: when I used to sell Cutco knives during college. I wasn't just a successful salesman in the drect-sales organization, but during the summer of 2007 I opened my own branch office in Grand Rapids, MI. I used my late grandmother's inheritance to pay for everything myself, including office rent, furniture, utilities, advertisements for new candidates, etc... I interviewed hundreds of candidates and personally trained more than 50. After the initial 3-day pembinaan seminars I ran each week, my reps came to ongoing pembinaan meetings twice a week in which I gave recognition to those making sales, and gave mini-lessons on topics like how to increase your average order size or closing ratio, or whatever I felt the team was struggling with. It was a great undertaking but also incredibly risky, and in the end for me it was not incredibly profitable. But the experience was once in a lifetime; you don't get that kind of experience any other way and it looks incredible on a resume, especially if you're an engineer.
So the first question I answered was (paraphrased), "Tell me in your own words about your Cutco sales/management experience, and how it has made you a better engineer." That was the perfect question for me, it was like they were setting the ball for me to spike it. I got to explain how I used to be very quiet, introverted and lacked confidence, but when I started selling Cutco I made it a personal challenge to improve my communication skills and get better at working with people, and that is what broke me out of my shell. Now I'm an expert communicator and orator, soft-skills which are invaluable in an engineer.
Apparently those types of soft-skills are what Google is looking for in their engineers. If you can find a way to highlight that on your resume, so much the better. It impressed me that they even noticed that part of my resume, because it was direct sales experience buried under 4 other technical jobs that I've had. Most companies (including the one I work for now) do not even notice it until I point it out and explain it, but even then it doesn't resonate with them the extent to which I actually started and ran my own profitable business.
After the first question broke the ice, they went right into a simple coding problem. Without telling you what it was, it went something like this: Write a function in your favorite language (it must be a real language, no pseudo-code) that has the given signature and does something interesting. It was super-simple, with the purpose only to make sure that I know the basics of the language I chose. But then they constrained the persoalan by saying that this will run on an embedded device where runtime is precious, so how would you change the algorithm? Okay and now the input value is 16 times wider than the original, how would you accommodate that? What about if memory was not an issue? Again, these are things that should occur to you intrinsically if you have the right software experience.
The next coding persoalan involved writing a class (I told them I was good at object-oriented programming, so OOP questions I got). The class has to contain a collection of items and have two functions that change the collection in some interesting way. The naive implementations were very easy, and gave me a chance to show how well I know C++ by using templates and some STL containers. Then they asked how I could improve it, and every time I came up with something they said, "Very good. Now make it better." up until the point where both functions were O(1), and even then they wanted me to think of another way to do it. It really pushed me to the limits, and that was the apparent purpose of the question. They wanted to see how well I really understood the asymptotic complexity of functions and to see what kinds of things occur to me to improve it. One of the solutions I came up with improved one function at the expense of the other, which I was quick to point out and earned even more points for saying it before they did. Even though the simplest and most obvious implementation eluded me at the time, I still impressed them by coming up with some creative methods, and demonstrated that I have a thorough understanding of the consequences of my code.
The last question I got was a real curve-ball, but I knew I was doing well because they told me to expect 2-3 questions and I had already gotten 3, or more if you count all the follow-up questions. So the fourth question I got had role-playing, with me in the role of project manager. They wanted to know how I would measure and prioritize a certain metric of development progress - WHAT?? I thought I was applying for a software engineer position, and they're asking me questions about managing a project?! Combining my soft-skills and engineering skills and applying it in a management role has been a long-time career goal for me, and at Google no less! So when they asked that last question I just about died. I can't even remember what I said anymore because I was so unprepared for the question, I gave one or two good responses but they wanted more and I kept thinking of different aspects of the same things. I can't feel too bad about my response, because just the fact that they asked that question makes me feel awesome.
Going into the interview I was nervous, because of some of the things I read online about how they ask really obscure Computer Science questions, even to senior engineers who don't generally care about that stuff because everything is already implemented in a library somewhere. I was happy to find that that was not the case; all the questions I got were incredibly relevant for software engineers and they stuck to the areas of my purported expertise. I was relieved they didn't make me implement an AVL-balanced binary search tree, or do a breadth-first search on a graph or find items in a trie (although they might if/when I do the onsite interview...who knows?) I think you can see that this is not something worth cramming for, because the questions can come from any direction, and they will easily be able to spot if you only have an ankle-deep understanding of the concepts. Again, this is only one account of an industry professional, so graduating students probably have a much different experience and I don't have any advice for them. But for all you other industry pros out there, I think the best way to do well is to relax, have a resume that speaks for itself and actually be what you say you are.
I'll update again after the on-site interview. I've never been to the bay area before and I'm sick of Michigan winter, so even if I don't get the job I'm excited about a free mini-vacation out west. I'm off to Mountain View!
