Google | L4 | Zurich | Sept-Nov 2020 [Reject] - Discuss - LeetCode

Hi all,

I wanted to write this a bit of a long read to share my experience of interviewing at Google which happened this year. I was rejected for the second time yesterday, and I thought that maybe some of you will find my failure experience valuable in any way. I will share both the interview process details as well as my preparation - so that you could have the full picture.

My profile summary:

Status: 6 years of experience
University: far from top ones
LeetCode problems solved: 998 - 254/544/200 Easy/Medium/Hard, contest ranking: 2168

Interviewing:

Location: Google Zurich
Position: L4
Dates: September - November 2020

This has been my second attempt to get into Google. The first one was in September 2019, I got to the hiring committee where I got a reject. My performance that year was quite average, since I’ve only started learning algorithms and data structures in spring 2019, so not much to tell.

After last time I got to know that I will be able to make my second attempt in September 2020, so I started preparing somewhat in April 2020:

solving all the daily LeetCode challenges since April till today
started participating in LeetCode contests
just randomly solving problems whenever I had the time.

Some things that really made me feel that I am more prepared than last year were the LeetCode contests. In the beginning - in April - it was really challenging for me to solve all 4 problems, usually solving 3 of them would take most of the 1.5 hours. Now sometimes I still am not able to solve the 4th one, but the first 3 together usually take about 30-40 minutes - which seems to be a nice speed if the same problems occurred during an interview.

So in August, I scheduled my onsites for September, I kept doing contests and started more intensive preparation. By that time, I’ve read quite some nice ideas here regarding the preparation (thanks so much to the community!) and I’ve implemented some of them in mine:

I used the repetitive pattern, where you find problems which you struggle to solve, and then solve them on each 1st, 2nd, 4th, 8th, 15th and 30th day. I called it “tasks dojo”. I had in total 24 different dojo problems, which I categorized to “touch” most of the important areas - they covered DP, trees/graphs/grids, geometry, recursion, binary search, linked lists, sliding window, design and a few other topics. I've shared the list here.
I was doing mock interviews almost every day.
I had 4 mock interviews (one system design, three algo+ds) on another resource- with either current or past googlers - to have the real experience with people from there.
I was writing most of the code in google doc - because LeetCode editor is much nicer than the one they have at Google onsite .
I took 2 weeks off work to completely dive into coding exercises.
I have regular meetings with my psychotherapist, so these interviews have also been quite a topic. I wanted to decrease the nervousness during the sessions and to treat the whole situation in a nice manner.
I used the coding interview meditation - to concentrate before the interviews.

By the time of onsites, I felt quite confident as I was solving most of the easy/medium problems in under 15 minutes, and I was getting exceptional scores on another resource all the time.

So the onsites came. I’m not going to tell exact problems - I respect the NDA, and moreover, if Google suspects that a problem has been leaked, they blacklist it so that engineers wouldn’t ask it any more. So sharing exact problems doesn't really help, but sharing the ideas overall can.

Onsite 1: coding
Problem: requiring some experience with heaps and linked lists. This one required a combination of those two. Not very hard, but made me think a bit. I would say LC medium/hard. I solved and coded it in about 25 minutes, then spent the rest of the time testing and speaking about the complexity.
Interviewer: quite a nice guy, we really hit it off both in communication and in problem solving.

Onsite 2: coding
Problem: completely design-related. Moreover, it even required a bit of knowledge I got from system design preparation despite it being a coding interview. Kind of a cache, with some eviction boundaries. Not hard. Solved and coded it in about 30 minutes, tested it and answered the followup questions.
Interviewer: completely neutral and with a poker face. I couldn’t tell what on earth he was thinking.

Onsite 3: coding
Problem: sliding window (exactly this problem is on LC - medium), with a follow-up question which requires DP. I started solving the first question using DP, and after writing the code I understood that it can be solved with a sliding window. I wrote another solution with a sliding window, and when I was asked for a followup with DP, solution was already there - I had only to change it a bit. Anyways, I’ve solved and coded both of them in about 35 minutes, tested and spoke about complexities.
Interviewer: very, very un-understandable. Starting from her accent - I had to ask to repeat sometimes. Continuing with the manner of interviewing - I didn’t understand if she follows my thoughts as she didn’t say anything, so I kind of pinged her with phrases like “does it sound reasonable?” or “do you see what I mean” and I was always getting something like “yeah”, “ok”, “sure” and so on. I really, really was not sure that she was following whatever I had been doing, and also I kind of felt her being nervous about the whole process.

Onsite 4: system design
A system design round. None of the classic questions, but more a one where you build something from scratch, and the interviewer adds complexities to see how you are going to solve them.
The round mostly went fine, with the exception that I bombed the back-of-the-envelope calculations (I’ve always skipped it during preparation as I was somehow sure it’s not going to be asked, haha!).
Interviewer: a very nice and experienced guy. He was strongly into our conversation and wanted to understand everything I was saying.

Onsite 5: behavioral
Nothing interesting here. Pretty much standard behavioral questions. An interviewer constantly writing my responses.

The feedback from the recruiter came in a week:

the coding rounds went really well - there was absolutely no negative feedback. She was quoting the interviewers and there were words like “solid”, “amazing” and “strong” performance;
the system design round went okay - mostly positive, with a drawback that the back-of-the-envelope calculations were not so great;
the behavioral round went fine, they said all is good there and I have the necessary “googliness”.

At the end, she said: congratulations with your successful interviews at Google!

Then came the project match process. In 3 weeks, I had 2 project match interviews, 1 of which was a bi-directional match (we really hit it off with the manager), and I was moved to the hiring committee.

1st hiring committee result: 2 additional coding interviews required.

My recruiter didn’t explain much - I think maybe she herself didn’t have access to all the information. She also said something like “ok, if I dive deeper, the feedback from the third interview is mostly positive, but there were minor flaws”. But basically, there was not enough signal for a hire, and they wanted to collect more data. Later I kept asking different googlers what that can mean - and the opinions vary. Some say that some topics may not have been covered (e.g. graphs or whatever), others say that topics don’t matter at all, and maybe the feedback was not obvious. I personally think that it is a combination of several things:

Maybe the third interview feedback was either not good or they couldn’t really trust it in a way - since in my opinion, the interviewer didn’t seem to be experienced or confident in interviewing
I don’t have a fancy university or education
I am not in top of any coding competitions
I don’t have an internal referral who really worked with me and could recommend me

So overall, I am a complete stranger for Google, and they want some really strong signal to take that risk. Again, that’s my opinion based on informal speaking with googlers.

Anyways, now I had to prepare for those 2 additional interviews. It has been 1.5 months since first onsites, so I had to get back in shape. Here’s what I did this time:

again, took 2 weeks off work (bye bye, my whole yearly vacation :D )
used the repetitive pattern again, but changed the days to be each 4 days, e.g. 1st, 5th, 9th and 13th
I had 8 mock interviews with real googlers. I got a green light from all 8 of them, 4 of whom gave me a “strong hire”. One of them told me he had no idea why I was sent to additional interviews
I solved both lists of most popular google questions for 1st and 2nd half of 2020 - taken here
continued regular meetings with my psychotherapist to discuss the stakes, possible nervousness and so on.

So now came the day of my additional interviews.

Additional onsite 1:
Problem: a tree one, easy starter question with an interesting follow-up. I solved the starter one quickly and then spent about 5-10 minutes testing it - that was my bad, I was not really confident that in-order traversal would give the necessary output, and kept returning to this insecurity. The interviewer kept asking me “are you sure” and “is that your final answer”, and lately it turned out that the solution was fine, he just wanted more confidence. The follow-up question was a bit tricky at first, and I spent quite some time trying to figure out the way to code it. I managed to code it while getting 5 minutes out of time and thus not having the time to test my code.
Interviewer: a nice guy, he kept smiling and following my thought process, but his questions were not helping, rather pushing me back - like the ones I’ve described above.
I felt that this interview didn’t go quite well because I spent too much time testing the first question and thinking on how to code the follow-up.

Additional onsite 2:
Problem: a design problem with heavy usage of bitmasks. I understood how to design it almost immediately since by a great coincidence I’ve done almost the same thing this year at my current job. Interviewer kept adding additional constraints, I kept modifying my solution. Looked good from my point of view.
Interviewer: to be honest, I didn’t quite like this interviewer. Firstly, he forgot to open the document where I was supposed to write code, and did it only when I asked (I can’t open it myself before he does). Secondly, he didn’t understand some parts of my code, e.g. my way of checking if there is only one bit set in a number (num & (num-1) == 0), asked me what that was and kind of paused me to prove that the code really does it. Thirdly, he asked me a couple of times on one piece of code “does it really do what you think” and when I explained, said “yeah, nevermind”, but as it turned out later from the feedback, he was not ok.

Then came the feedback. Overall: not so good first interview, reasonably good second interview.

Interview 1: I showed solid algo and ds knowledge, code design was nice, as was communication and code readability. What was not so good was the coding efficiency, pace and it took me a long time to test the solution. Nothing to add here - I completely agree myself.
Interview 2: pretty much the same feedback, but a bit better. However it turned out that my solution, including the final one, had a bug. Which was: when I was designing code, I created an enum class as an example and said - ok, each of the enum fields are going to have bitmasks - and wrote something like

enum Color {
	RED(1),
	BLUE(10),
	YELLOW(100);
}

So the bug - and the thing the interviewer kept asking me if it worked as I was supposing it to - was that my bitmask was not in binary, but in decimal format, since in Java I should write it as e.g. 0b10 to work as binary. Hell, I know that, I was just giving an example of how enum class would look like and not really implementing it… It won’t work anyway without a declared constructor, so I never even thought of checking the enum declaration. However, this was considered a bug.

So, then came another hiring committee. They’ve reviewed my whole package including additional interviews and decided not to proceed. Nor with L4, not even with L3.

The final feedback from the recruiter - after 2nd hiring committee - was as follows:

I showed myself as a quite strong candidate with my system design (I thought like - what?? this was my weakest thing after first on-sites)
However, what needs improvement is the algo and data structures knowledge, the coding progress - pace and efficiency, the quality of the code, and more testing - because we at Google like engineers who test their code. I was like - what#2, some of these things were earlier given as my strong sides, and this resulting feedback kind of contradicts the initial ones.

Anyways, that’s my story. Thank you if you’ve read so far, I really appreciate your patience!

Below are some of my final thoughts, which I derived from my journey:

Life is random. Very, very random. Yes, good preparation definitely increases your chances. No, it doesn’t guarantee anything. You can put a lot into preparation, really commit like I did - 4 weeks of vacation, 1500 euros worth mock interviews, lots and lots of practice hours, and even seem to be ready for a job (8 googlers said to me that I am quite good) and still not get it - because I had a slight temperature the day before interview, because I was preparing without video and real interviews had one and it distracted me, because I stumbled over some pretty easy tree question or because some interviewer thinks 0b prefix before a mask is important in a sketch-class. I will never know the exact reason, but random shit can impact.
I’ve seen some people who have about 200 questions on LC solved and get into Google from the first attempt. However, some people like me have 1000 questions solved and don’t make it. We all have different backgrounds, so let’s not compare ourselves to each other. And again - random shit can impact a lot.
Finally: I’ve had a lot of fun during my journey! I’ve been so depressed after the second rejection, but then my wife reminded me how I like solving the coding problems themselves - hell, I wake up every Sunday at 3:30am to participate in a weekly contest as I live in Europe. Now the future seems bright again :) I like solving the problems, and I am going to try and progress with competitive programming - and hopefully make it up to the end next time.

Thanks so much for bearing with me. I wish for all those working to get your dream job - to nail it as soon as possible, and if it doesn’t happen from the first attempts - the show must go on!

Update from April 2021: thank you all so much for your support! I've written a follow-up article about my successful Apple interviews here.