The article's title may sound like an epic fail, but it's not that straightforward. Overall, this story ended quite positively, albeit not with Google. But that's a topic for another article. In this article, I will discuss three things: how my preparation process went, how the interviews at Google were conducted, and why I believe things are not as clear-cut as they may seem.
How It All Started
One cold winter evening in Cyprus, it suddenly struck me that my knowledge of classical Computer Science was quite far from average, and I needed to do something about it. If, by the way, someone hasn't read why the evening was cold and Cypriot, you can find out about that. . After some contemplation, I decided to start with an online course on algorithms and data structures. I heard from a former colleague about Robert Sedgewick's course on Coursera. The course consists of two parts ( and ). If the links happen to change, you can always Google the author's name. Each part lasts 6 weeks. At the beginning of the week, lectures are released, and during the week, you also need to complete exercises. The first part covers basic data structures, major sorting types, and algorithm complexity. The second part is more advanced, starting with graphs and ending with topics like Linear Programming and Intractability. Having thought about everything above, I concluded that this was exactly what I needed. A curious reader might ask, what does Google have to do with this? And indeed, up until that moment, it was completely unrelated. But I needed a goal; working tirelessly for 12 weeks in the evenings without a goal is quite difficult. And what could be the goal of acquiring new knowledge? Of course, its practical application. In everyday life, this is quite challenging, but very achievable during an interview with a large company. A brief Google search revealed that Google (pardon the tautology) is one of the largest companies in Europe (which I was considering), where such interviews take place. Specifically, their office is located in Zurich, Switzerland. So it was decided — I would study and apply for a job at Google.
Preparation for the First Attempt
Twelve weeks flew by, and I completed both courses. My impressions of the courses are more than positive, and I can recommend them to anyone interested. I enjoyed the courses for the following reasons:
- The lecturer speaks in quite clear English.
- The material is well-structured.
- Impressive presentations that illustrate the inner workings of each algorithm.
- A well-curated selection of material.
- Interesting exercises.
- Exercises are automatically checked on the website, after which a report is generated.
My work on the courses usually went as follows. In 1-2 days, I would listen to the lectures. Then I would take a quick test on the material. The rest of the week, I would do the exercise in several iterations. After the first attempt, I received my 30-70%, and subsequent attempts brought the result up to 97-100%. The exercise usually involved implementing an algorithm, for example, or .
After completing the courses, I realized that many pieces of knowledge come with many sorrows. While I previously just knew that I knew nothing, I now began to realize what exactly I did not know.
Since it was still only May, and I had my interview planned for the fall, I decided to continue my education. After reviewing the job requirements, I decided to pursue two paths simultaneously: to continue studying algorithms and to take a basic course in machine learning. For the first goal, I decided to switch from courses to a book and chose the monumental work by Steven Skiena, "The Algorithm Design Manual." Not as monumental as Knuth's, but still significant. For the second goal, I went back to Coursera and enrolled in Andrew Ng's course. .
Three more months passed, and I completed the course and the book.
Let's start with the book. The reading turned out to be quite interesting, although not easy. Overall, I would recommend the book, but not just like that right away. In general, the book provides a deeper analysis of what I learned in the courses. Additionally, I discovered (from a formal perspective) concepts like heuristics and dynamic programming. Naturally, I had used them before, but I didn’t know their names. The book also contains several anecdotes from the author's life (War Story), which somewhat lighten the academic tone of the narrative. The second half of the book can actually be skipped; it mainly describes existing problems and methods for solving them. It's useful if applied regularly in practice; otherwise, it will be forgotten immediately.
I was more than pleased with the course. The author clearly knows his stuff and presents it engagingly. Plus, I remembered a significant portion, specifically linear algebra and the basics of neural networks, from university, so I didn’t face significant difficulties. The structure of the course is quite standard. It is divided into weeks. Each week starts with lectures mixed with short quizzes. After the lectures, an assignment is given that needs to be completed, submitted, and it will be graded automatically. In brief, the topics covered in the course are as follows:
— cost function
— linear regression
— gradient descent
— feature scaling
— normal equation
— logistic regression
— multiclass classification (one vs all)
— neural networks
— backpropagation
— regularization
— bias/variance
— learning curves
— error metrics (precision, recall, F1)
— Support Vector Machines (large margin classification)
— K-means
— Principal Components Analysis
— anomaly detection
— collaborative filtering (recommender system)
— stochastic, mini-batch, batch gradient descents
— online learning
— map reduce
— ceiling analysis
After completing the course, I understood all these topics. After 2 years, I had nearly forgotten everything. I recommend it to those who are unfamiliar with machine learning and want a solid understanding of the basics to move forward.
The first attempt
It was already September, and it was time to think about job interviews. Since applying through the website is quite tricky, I started looking for acquaintances working at Google. I chose , as he was the only one I knew directly (even if not personally). He agreed to pass my resume, and soon I received a letter from the recruiter offering to book a slot in his calendar for the first conversation. A couple of days later, we had a call. We tried to communicate via Hangouts, but the quality was terrible, so we switched to phone. Initially, we quickly discussed the standard hows, whys, and whats, and then moved on to the technical screening. It consisted of about a dozen questions like 'what's the complexity of inserting into a hash map', 'what balanced trees do you know'. It's not hard if you have basic knowledge of these things. The screening went well, and based on the results, we decided to organize the first interview in about a week.
The interview was also via Hangouts. We talked about myself for about 5 minutes, then moved on to the task. The task was about graphs. I quickly understood what needed to be done, but I chose the wrong algorithm. When I started writing the code, I realized this and switched to another option, which I completed. The interviewer asked several questions about the algorithm's complexity and whether it could be done faster. I kind of froze and couldn't respond. At that point, the time was up, and we said our goodbyes. About 10 minutes later, I realized that instead of Dijkstra's algorithm, which I used, in this particular task, it would have been faster to use breadth-first search. A little later, the recruiter called and said that the interview had gone well overall and that we should organize another one. We scheduled it for another week later.
This time things went worse. While the interviewer was friendly and sociable the first time, this time he seemed rather gloomy. I couldn't figure out the task right away, although the ideas I had could have led to a solution. Eventually, after a few hints from the interviewer, I arrived at the solution. It turned out to be a breadth-first search again, just from several points. I wrote down the solution and met the time limit, but I forgot about edge cases. After some time, the recruiter called and informed me that the interviewer was dissatisfied this time, as he thought I needed too many hints (3 or 4) and I kept changing the code during the writing. As a result of the two interviews, it was decided not to proceed further and to postpone the next interview for a year, if I wished to do so. And that was the end of it.
From this story, I drew a few conclusions:
- Theory is good, but you need to navigate it quickly.
- Theory without practice won't help. You need to solve tasks and automate code writing.
- Much depends on the interviewer. And there's nothing you can do about it.
Preparation for the second attempt
Reflecting on the situation, I decided to try again in a year. I slightly revised my goal. If earlier my main aim was learning, with the Google interview as a distant carrot, now passing the interview was the goal, and learning was the means.
So, a new plan was developed, which included the following points:
- Continue studying theory by reading books and articles.
- Solve algorithmic problems totaling 500 to 1000.
- Continue studying theory by watching videos.
- Continue studying theory through courses.
- Learn from the experiences of others regarding the Google interview process.
I completed the plan in a year. Next, I will describe what exactly I did for each point.
Books and articles
I can't even remember how many articles I read; I read them both in Russian and in English. The most useful website turned out to be probably . It compiles descriptions of a large number of interesting algorithms with code examples.
I've read 5 books: Algorithms, 4th edition (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4th edition (Gayle Laakmann), Programming Interviews Exposed 2nd edition (Mongan, Suojanen, Giguere), Elements of Programming Interviews (Aziz, Lee, Prakash). They can be divided into 2 categories. The first includes the books by Sedgewick and Cormen. These are theoretical. The others are for interview preparation. Sedgewick's book covers much of the same material as his courses but in written form. There’s not much point in reading it closely if you’ve taken the course, but it’s worth skimming either way. If you haven't watched the course, then reading it makes sense. I found Cormen to be overly dry and honestly had a hard time getting through it. I only took away , and a few rarely used data structures (Fibonacci heap, van Emde Boas tree, radix heap).
It’s worth reading at least one book for interview preparation. They are all structured similarly. They describe the interview process in large tech companies, provide basic concepts from Computer Science, problems based on these concepts, solutions to the problems, and discussions of the solutions. Among the three mentioned, I would probably recommend Cracking the Coding Interview as the primary one, with the others as optional.
Algorithmic problems
This was probably the most interesting part of the preparation. Of course, you can just sit down and solve problems mindlessly. There are many different sites for this. I mostly used three: , and . On CodeChef, the problems are categorized by difficulty but not by topic. On Hackerrank, they are categorized by both difficulty and topic.
But as I quickly found out, there is a more interesting way. And that is competitions (programming challenges or programming contests). All three sites provide them. However, there is a problem with LeetCode — the inconvenient time zone. That's why I didn’t participate on that site. Hackerrank and CodeChef offer a sizable number of various competitions, lasting from 1 hour to 10 days. Different formats have different rules, and one could talk about this for a long time. The main reason why competitions are good is that they introduce a competitive (and again tautology) element into the learning process.
I participated in a total of 37 competitions on Hackerrank. Of these, 32 were rated, and 5 were either sponsored (I even earned $25 in one of them) or just for fun. In the rated competitions, I made it into the top 4% ten times, the top 12% eleven times, and the top 25% five times. My best results were 27th out of 1459 in a three-hour contest and 22nd out of 9721 in a weekly one.
I switched to CodeChef when competitions on Hackerrank became less frequent. I managed to participate in 5 competitions there. My best result was 426th out of 5019 in a ten-day contest.
In total, I solved just over 1000 problems in competitions and otherwise, which fit into my plan. Unfortunately, I currently don't have free time to continue competitive activities, nor do I have a goal to justify taking up my limited time. But it was fun. I recommend that anyone interested find like-minded individuals. It's much more engaging in pairs or groups. I enjoyed this pastime with a friend, which might be why it went so well.
Watching videos
After reading a book by Skiena, I became generally interested in what he does. Like Sedgwick, he is a professor at a university. Because of this, you can find video recordings of his courses online. I decided to watch the course . I wouldn't say I liked it very much. Firstly, the video quality is not very good. Secondly, I didn't try to solve the problems discussed in the course myself. So, my engagement wasn't very high.
While solving problems and trying to find the right algorithm, I stumbled upon videos by Tushar Roy. He worked at Amazon and now works at Apple. As I later found out, he has , where he posts explanations of various algorithms. At the time of writing this article, the channel contains 103 videos. I must say, the explanations offered by him are quite well done. I tried watching other creators, but somehow they didn't resonate with me. So, I definitely recommend this channel.
Taking courses
I didn't do much here. I watched videos from the Android Developer Nanodegree by Google and completed a course from ITMO . The Nanodegree is quite good, although I didn't learn anything new from it. The course from ITMO is a bit disorganized in terms of theory, but the problems were interesting. I wouldn't recommend starting with it, but I certainly didn't waste my time on it.
Exploring the experiences of others
Naturally, many people tried to get into Google. Some succeeded, some did not. Some wrote articles about it. Among the interesting things, I'll probably highlight and . In the first case, a person prepared a list of what he needed to learn in order to become a Software Engineer and get into Google. Ultimately, he ended up at Amazon, but that’s not so important. The second manual was written by Google engineer Larisa Agarhkova (). In addition to this document, you can also read .
. It makes sense to read reviews of interviews on Glassdoor. They are all more or less similar, but you can extract some useful information.
I won't provide links to other minor articles; you can easily find them yourself on Google.
Second round
And a year has passed. It was quite a busy year in terms of studying. However, I approached the new autumn with much deeper theoretical knowledge and refined practical skills. Just a few weeks remained until the end of my allocated year for preparation, when suddenly I received an email from a recruiter at Google, asking if I still had the desire to work at Google and if I would be willing to chat with him. Naturally, I was open to that. We agreed to have a call in a week. They also requested an updated resume, to which I added a brief description of what I had accomplished over the year at work and in general.
After discussing life, it was decided that there would be a Hangouts interview in a week, just like last year. A week passed, interview time came, but the interviewer did not show up. Ten minutes passed, I was starting to get anxious when suddenly someone popped into the chat. It later turned out that my interviewer, for some reason, could not appear, and they urgently found a substitute for him. The person was somewhat unprepared both in terms of computer setup and conducting the interview. However, everything went well later on. I solved the task quickly, explaining where there might be pitfalls and how to circumvent them. We discussed several different variations of the task, algorithm complexity. Then we chatted for another 5 minutes; the engineer shared his impressions of working in Munich (apparently, they didn’t find an urgent substitute in Zurich), and that was it.
On the same day, a recruiter contacted me and informed me that the interview went excellently and they are ready to invite me for an in-person interview. The next day, we had a call via Hangouts to discuss the details. Since I needed to apply for a visa, we decided to schedule the interview for a month later.
While I was preparing the documents, I was also discussing the upcoming interview with the recruiter. A standard interview at Google consists of 4 algorithmic questions and one System Design question. However, since I was applying as an Android developer, I was told that part of the interview would focus on Android specifics. I couldn't get any specifics from the recruiter about what exactly that would involve. As far as I understood, this was introduced relatively recently, and he himself wasn't very informed about it either. I was also scheduled for two training sessions: one on algorithmic interviews and another on System Design interviews. The sessions were of medium usefulness. No one could tell me what exactly Android developers are asked about. Therefore, my preparation during this month boiled down to the following:
- Buying a whiteboard and writing down 2-3 dozen of the most popular algorithms from memory. 3-5 each day. In total, each one was written several times.
- Refreshing my memory on various Android information that I don't use every day.
- Watching several videos about Big Scale and such.
As I mentioned, in parallel, I was preparing documents for the trip. First, I was asked for information to create an invitation letter. Then, I spent a long time trying to find out who in Cyprus processes visas for Switzerland, as the Swiss embassy doesn't handle that. It turned out that the Austrian consulate takes care of this. I called and scheduled an appointment. They requested a stack of documents, but nothing particularly interesting. Photo, passport, residence permit, a bunch of different certificates, and of course the invitation letter. Meanwhile, the letter was still not arriving. In the end, I went with a regular printout, and it worked just fine. The letter actually arrived three days later, but the Cypriot FedEx couldn't find my address, and I had to go pick it up myself. While I was there, I also retrieved a package that they couldn't deliver to me because they couldn't find the address, which had been sitting there since June (5 months, can you believe it?). Since I wasn't aware of it, I obviously didn't expect they had it. I received the visa on time, after which my hotel was booked, and they offered me flight options. I adjusted the options to make it more convenient. There were no direct flights available, so I ended up flying there via Athens and back through Vienna.
Once all the travel formalities were settled, a few more days passed, and I actually flew to Zurich. I arrived without any incidents. From the airport to the city, I took a train — quick and convenient. After wandering a bit around the city, I found the hotel and checked in. Since the hotel was booked without meals, I had dinner next door and crashed for the night, as my flight was in the morning and I was already tired. The next day, I had breakfast at the hotel (for an extra charge) and headed to the Google office. Google has several offices in Zurich. My interview was not at the central one. The office looked quite ordinary, so I didn't get to see all the perks of a 'normal' Google office. I checked in with the administrator and sat down to wait. After a while, a recruiter came out and explained the plan for the day, after which he took me to the room where the interviews were supposed to take place. The plan included 3 interviews, lunch, and then 2 more interviews.
Interview number one
The first interview was specifically about Android. Moreover, it was completely unrelated to algorithms. Quite a surprise, however. Well, it’s even more familiar this way. They asked me to create a specific UI component. First, we discussed what and how to do it. I suggested a solution using RxJava, explaining what I would do and why. They acknowledged it was good, but suggested we use Android framework tools instead. And let's write the code on the board. Not just the component, but the whole Activity that uses it. I wasn’t prepared for that. Writing a 30-50 line algorithm on the board is one thing, but writing messy Android code, even with shortcuts and comments saying, "I won't write this part as it's obvious," is another. It turned into a chaotic mess on three boards. So, I solved the task, but it looked terrible.
Interview number two
This time, the interview focused on algorithms. There were two interviewers. One was the actual interviewer and the other a young padawan (shadow interviewer). I had to come up with a data structure with specific properties. As usual, we began discussing the problem. I asked various questions, and the interviewer responded. After a while, they asked me to write a few methods for the devised structure on the board. This time, I managed reasonably well, though with a few minor errors that I corrected with hints from the interviewer.
Interview number three
This time, it was System Design, which unexpectedly turned out to be about Android as well. I needed to develop an application with specific functionality. We discussed the application requirements, the server, and the communication protocol. I began describing which components or libraries I would use to build the application. Then, when I mentioned Job Scheduler, I hit a snag. The thing is, I had never used it in practice because when it was released, I had just switched to working on applications where there was no need for it. The same was true for subsequent projects. So, theoretically, I know what it is, when and how it is used, but I lack practical experience. The interviewer didn't seem to like that much. Then they asked me to write code. Yes, when developing the application, you need to start coding right away. Again, it was Android code on the board. It turned out to be another scary situation.
Lunch
Another person was supposed to come, but they didn't. Even Google makes mistakes. In the end, I had lunch with the previous interviewer and her colleague, and the next interviewer joined us a little later. The lunch was quite decent. Again, since this is not the main office in Zurich, the cafeteria looked fairly ordinary, though very pleasant.
Interview number four
Finally, pure algorithms. I solved the first task fairly quickly and efficiently, although I missed one edge case, but with the interviewer's hint (he provided that very edge case), I discovered the problem and fixed it. Obviously, I had to write the code on the board. Then a similar but more complex problem was given. For it, I found a couple of suboptimal solutions and almost arrived at the optimal one, just needed 5-10 more minutes to finalize my thoughts. Unfortunately, I didn't have enough time to write the code for it.
Interview number five
And once again, an Android interview. I wonder why I studied algorithms all year?
First, there were a few simple questions. Then the interviewer wrote code on the board and asked me to find problems in it. I found them, explained, and corrected them. We discussed. Then came some unexpected questions like 'what does method Y do in class X?', 'what is inside method Y?', 'what does class Z do?'. I answered some of them, but then I mentioned that I haven't encountered this in my recent work, so I naturally don't remember the details of who does what. After that, the interviewer asked me about what I'm currently doing. The questions shifted to that topic. Here, I answered much better.
After the last interview, they took my pass, wished me good luck, and sent me on my way. I wandered around the city a bit, had dinner, and returned to the hotel, where I crashed into bed since my flight was early in the morning again. The next day, I made it to Cyprus safely. At the recruiter's request, I wrote feedback on the interview and filled out a form in a special service for reimbursement of expenses. Out of all expenses, Google directly pays for the tickets. The hotel, food, and transportation are covered by the candidate. Then we fill out the form, attach the receipts, and send them to a specific office. They process it and usually transfer the money to the account quite quickly.
It took a week and a half to process the interview results. Afterwards, I was informed that I was "a bit below the bar." In other words, I fell a little short. Specifically, 2 interviews went well, 2 were somewhat less successful, and the System Design interview did not go well at all. If at least 3 had gone well, I might have had a chance, but as it stands, there was none. They suggested I try again in a year.
At first, I was quite disappointed since a lot of effort went into preparation, and by the time of the interview, I was already contemplating leaving Cyprus. Getting a position at Google and moving to Switzerland seemed like a great option.
Conclusion
And so we come to the concluding part of the article. Yes, I failed the interview at Google twice. That's unfortunate. It would probably have been interesting to work there. However, we can also look at the situation from another perspective.
- In a year and a half, I learned a tremendous amount about software development.
- I gained a lot of enjoyment while participating in programming competitions.
- I took a trip to Zurich for a couple of days. When will I get to go there again?
- I gained interesting interview experience at one of the largest IT companies in the world.
Thus, everything that happened during these eighteen months can simply be considered learning or training. And the results of this training have become evident. My decision to leave Cyprus matured (due to some family circumstances), I successfully passed several interviews at another well-known company, and after 8 months, I moved. But that's a completely different story. Nevertheless, I think I should thank Google for these eighteen months that I worked on myself and for the 2 interesting days in Zurich.
What can I say in closing? If you work in IT, prepare yourself for interviews at Google (Amazon, Microsoft, Apple, etc.). Perhaps one day you will manage to get in there. Even if you don't want to, believe me, you won't regret such preparation. The moment you realize that you could (even if only due to fortunate circumstances) pass an interview at one of these companies, many more paths will open up for you than at the beginning of your preparation. All you need on this journey is a goal, perseverance, and time. I wish you success 🙂
Source: habr.com
