This is the 8th chapter of our The Complete Guide to Google Interview Preparation series.
Following our <previous discussion> about phone screens, I’ll talk about on-site interviews in this chapter. For most companies, this is the “final test” you’ll have and once you pass it, you’ll get the offer.
At the same time, the on-site interview is also the most exhausting step where you’ll have multiple sessions within a single day. There’s no doubt that on-site interviews are more challenging in general and many people are really afraid of this. I’ll address all those concerns in this chapter and provide very practical tips as before.
On-site Interview Process
You can never win a game without fully understanding the rules. Take Google as an example. On that particular day, you will have four technical interviews in total (usually two in the morning and two in the afternoon). There’s a “lunch interview” during lunch time, but it’s not really an interview because you are not evaluated and it’s just a chance to hangout with a Googler.
Among these four coding interviews, at least one of them will be system design interviews. You will definitely write a lot of code on a whiteboard and have an intense discussion with interviewers. The interview format is more or less the same as phone screens. Normally two questions will be asked within 45min and solid code is required. So be prepared for a very tiring day.
Many people are also curious about the evaluation process. At the end of the interview, each interviewer will write down a report that contains all the details and discussion in that 45min session including your code. The report can be extremely detailed that how much time you spend in each part and what your reaction is after a hint will all be included. A hiring committee will make the hiring decision based on all these reports.
It’s worth nothing that this process is unique to Google and most top companies like Facebook, Airbnb, Uber have very similar processes.
Phone Screens VS On-site Interviews
The whole process is more or less the same so that you are unlikely to be surprised by anything. Some major differences include:
- Having face-to-face communication means the whole process can be more smooth, but at the same time many people are more likely to be nervous. If you can have some in-person mock interview with your friends, it can be very helpful.
- Questions are slightly harder. You’ll still have the same type of coding questions, however, the most common misunderstanding is that it’ll be significantly harder than phone screen questions. I’ll discuss this in detail soon.
- At least one system design interview is required.
In terms of what questions I should practice for an on-site interview, I would say just practice in the same way as phone interviews (except system design interview). You don’t really need to find questions that are specific to on-site interviews and in fact, many questions are asked in both cases.
“Questions Are Much Easier Than I Expected”
This is the most common comment from on-site interviews. However, it’s also why most people failed the interview. Let me explain this in detail.
One of the biggest misunderstanding is that Google on-site interviews are much harder than phone screens. Of course, sometimes there can be some hard questions. But in general, it’s only slightly harder. Many interviewers will still ask questions like 2-sum to get an initial idea of candidates.
At Gainlo, many users are complaining that the mock interview is too simple, though they didn’t pass it. They can’t believe that the questions are that “easy”. But in fact, interviewers are using similar questions as real interviews.
Let me tell you something. The most difficult part of Google interview (same as other companies) is not coming up with a solution. Many people can solve the problem to some extent. But to get a good score, you need to:
- Come up with the optimal solution
- Write clean and bug-free code
- Accomplish these two things with time limit
Point 2 and 3 are the most challenging parts and most candidates failed for these two reasons. Many people claimed that questions were much easier than they expected, but they still didn’t provide bug-free code quickly.
From the interviewers’ perspective, it makes no sense to ask questions that nobody can solve. To evaluate a candidate, we need to see the analysis process, the code and how quickly he/she can solve the problem.
- Focus more on “basic” questions instead of super hard problems. Just do a little bit search on Glassdoor and Uber Interview Questions to get an idea of what kind of questions are popular. You’ll soon realize they are not as hard as what most people think.
- Pay extreme attention to coding when practicing. Write down solid code for every question and track the time.
For most companies, you’ll need to write code on a whiteboard in on-site interviews. Personally, I find this uncomfortable, even compared to writing on a code sharing tool.
One problem is that it’s very hard to do insertion. More often than not, you notice that you’re missing one simple check in the beginning and you need to insert a small if-block. However, you can never do this nicely on a whiteboard. Similarly, if your code is redundant, you can’t save time by doing copy and paste.
If you haven’t done this before, just try to write code on a piece of paper and you’ll soon find it terrible. Therefore, the rule of thumb is to practice this in advance. Yes, you need to practice coding on a whiteboard before an on-site interview.
You can buy a very cheap one on Amazon or at least you should practice coding on papers. Again, the philosophy is do everything as close to the interview as possible because you don’t want to be surprised on that day.
Here’re several tips:
- Think thoroughly before writing. It’s hard to undo your code and it’s important to make sure every line of code is what you want. This is actually a very good practice. Many people tend to code while thinking, which never works. You need to have a clear thought beforehand.
- Clean writing. I would not recommend joined-up writing. As an interviewer, I’ve frequently found it unrecognizable. Some people may think that it can save some time. However, you’ll spend way more time to explain the code. The best strategy to speed up is to have a clear thought and make sure you can implement smoothly.
I’ve covered this point multiple times in previous posts and I only want to emphasize few points here.
- The whole interview is a discussion process and this is more true in an on-site interview. It’s completely different from taking exam because you are expected to have constant communication with interviewers. Think the process as a normal discussion with your colleagues where you guys are working on the same problem together.
- Think loudly. Talk about whatever in your mind and you don’t need to have any concrete idea before discussing. Be “less cautious” about your words but more cautious about the code. Most people failed the interview by doing the opposite.
- Feel free to talk about what you are stuck with. Interviewers are really willing to help you out by giving you hints or telling you that you’re not in the right direction. Don’t worry about disclosing your weakness, it’s quite obvious when you are not making any progress even if you don’t admit. Instead, be open about it and the interview process will be a whole lot more pleasant.
Again, do not expect yourself to be able to do all of these tips immediately. You certainly need a lot of practice before the interview. In other words, knowing these advice means nothing unless you can actually work on them.
I do not cover much about non-technical questions and tips, I’ll have a complete chapter to address all those concerns soon. Stay tuned!
Also, If you want to have more guidance from experienced interviewers, you can check Gainlo that allows you to have mock interviews with engineers from Google, Facebook etc..