Back in January, I applied to Google for the first time. I didn't hear anything. Not even an email saying no, just radio silence. 6 months went by, and I finally decided to apply again, but this time I reached out to a friend I had on the inside. She was awesome and gave me a referral. 2 days later I got an email from a recruiter saying that they would not be looking to continue with my application at this time. I had begun to do some problems on Leetcode but once I got the email I decided to stop and move on. Then about 2 months later, half way through September, I got an email from a recruiter asking if I was still interested in interviewing. Of course I said yes. We had a quick 30 minute chat on the phone about my resume and some of the projects I had worked on. After that (phew, passed the "do you have 2 heads" part), he sent me some preparation materials, and I told him the next week that I felt I would be ready by the beginning of December.
The studying begins
I immediately dove in. I knew I had a lot to cover, as my EE degree (not the actual fault of the degree obviously) failed to teach me about data structures and algorithms (DSA) that all CS majors learn early on. At this point, I had 3 CS internships, all of my side projects, and about 1.5 years of experience in the real world aiding me, but none of that compares to DSA. I started with data structures, as a lot of them end up being used in the algorithms you will write for solving questions. This was probably the easier part out of all that I studied. I had a small insight into Maps already, so I started there. That was fairly easy, and I quickly moved to Sets. (Keep in mind, since JS is my strongest language, I did all of this in JS, which had its own issues since most of the data structures are not natively in JS). I spent time writing the implementations of some data structures, including Sets, Queues, Stacks, Linked Lists (singly and doubly linked), Binary Trees, and Maps (which was weird because JS does have a Map object).
For algorithms I don't think I studied more than the absolute basics. I went over the concepts of Djikstra's and A*, but never could quite understand them enough to implement them. I did implement and fully understand binary search. I did a little bit of Divide and Conquer, and quite a bit of backtracking. I attempted a couple Dynamic Programming problems, but they proved pretty difficult and I know I should spend more time here in the future. I looked at tree traversal, but did not spend much time trying to implement them. Algorithms are really the hard part, because that's essentially what I was doing when attempting the problems.
Well, this was undoubtedly the longest part, and where I spent most of my time studying. I spent the money to get Leetcode premium so that I could unlock the Google specific questions, and see what has been asked a lot recently (none of the problems I solved ended up being in my interview). Truthfully, it's hard to offer what to study, because none of what I did study (other than the use of data structures) helped me. But really it's not about the content of the problems, it's about how you attack the problems that I took away from this part. About halfway through, I began to Pomodoro Technique the whole process, which I felt helped me a lot. I broke into 30 minute work periods, with 10 minute breaks between. If I did not complete a problem in 2 working periods, I looked at the discussion for some help. It's hard to not get discouraged at this point. I had good days and bad days. Some really good, and some really bad. Don't look at how many other people solve. It's the one thing I kept having to tell myself to forget. I saw plenty of people completing 200-400 problems in the same time-span I had. I completed 85 total problems, with 46-36-3 of easy-medium-hard. At the end I was happy with the amount of problems I completed, because it really was a lot of time spent practicing problems.
I attempted to white-board as many of the problems I could. I forced myself to write out what I was thinking, as most of the time I got stuck in my head and couldn't figure it out. Once I wrote it out though, most of the time I found a solution.
Other than practicing for solving problems, I also practiced some system design. I've worked a lot with building applications from the ground up, so I mostly just ran through problems so that I could practice white-boarding/talking out loud and going through from the basics of the system all the way to the advanced details. Along with that, I prepped some behavioral questions. Of course, I couldn't really prep for this, but I got together some typical situations that I would be able to recall easily. This made it easier instead of having to do it on the spot, which I am terrible at when it comes to "Tell us a time when..." questions.
My scheduled interview day came, and I flew down the night before to Austin for the onsite interviews. I got there rather late, and I wish I had a little more time to sleep then I did, as I knew I would have to be up early the next day. I woke up at 7 to go for a run, which helped calm my nerves as I got out the excess energy and started my brain up for the day. I ended up cutting it a lot closer than I would have liked, but after breakfast and showering I still had to go check out. I had 20 minutes to get to the Google office, but luckily it was 5 minutes down the road, and I got there with plenty of time. I was directed to the elevators that would take me up to the Google reception, where my first interviewer found me and checked me in. After that, we went to a conference room and dove right into my first interview. The first 2 were technical, and I felt confident about both of them. I was then met by the person who would take me to lunch, and we headed to the cafeteria. I was told quite a bit that this was just a lunch, and not an interview. We had a pretty good conversation, and I asked a few questions about Google and how the work/life balance is. After this, we headed to my next interview, which was another technical, and more of a class design question, instead of an algorithm question. The following interview was also technical and I felt both of these went pretty well also, although I did have some trouble with the asynchronous aspect of the second interview, but that was part of optimizing it. I had a solution that worked, but we were working on doing some of the requests in parallel, instead of series like I had written. The last interview was my behavioral (of course I spent time doing system design and I didn't get any, but still be sure to study it) and I felt this went as well as it could have. We wrapped up a little early, so I asked this interviewer some questions about Google. After that, he gave me a tour of some of the office, and then sent me on my way.
I walked out feeling great. I felt I was really able to dive into the questions, and even work with the interviewers to discover some things about JS that I didn't know before. But, even with how well I felt it went, I unfortunately did not get the job. It took a little longer because of the holiday for me to hear back, but really it was about a week and a half before I did hear. Now having the feedback that I do, when I go back and look at everything I did that day, I can see where I need to improve. I of course have to wait the standard amount of time before reapplying, but this will give me time to study what I need to and refine what I already know. Even though it wasn't good news, it only got me one step closer to getting it. I have a plan, and I know moving forward what to expect. Until next time, Google.
What I learned
- POINTERS - Huge learning opportunity here with singly and doubly linked lists. I always struggled with pointers in C, but here, they finally clicked (yes, I know JS doesn't have pointers, but references are similar, and I did pointers in Go just to make sure I understood them)
- All the data structures - Well, most of them anyways. This was huge, as I do actually use a lot of what I learned in data structures in the code I write now.
- Verbalize your solution early - Based on the feedback I got, this is one thing I will definitely do next time. I didn't necessarily voice that I had a solution (and it's respective time complexity) until after I had started writing code. Of course, the first thing to do is ask clarifying questions, but then from there, voice what ideas you have for a solution.
- Write your code - Every interview I started on the board, and then moved to the Chromebook. When I go back, I will only whiteboard clarifying information down from the questions I ask, and then go right to writing code. The 45 minutes goes a lot quicker than you think it will, so you really do have to use your time wisely.
- Be quick - I know this may seem obvious, but looking back I took my time going through everything I possibly could, and while you should definitely voice everything going through your head, I will definitely be quicker with my whole process