Late post. This was my long journey of interviewing for a Software Engineer, Backend role at Google. Solved 425 questions (135, 242, 48) on LeetCode. Initial contact with the recruiter happened in late February. All rounds had 45 minutes strict time-bound. After a month 1st telephonic round was set up.
Telephonic Rounds
Round 1(Late March):
Was asked a string stack-based question equivalent to LC upper medium. Similar to Decode String and Encode String with Shortest Length.
Feedback (came after longggg 2 weeks): Correct code and algorithm, but I was uncertain at times and needed a couple of hints for corner cases. So, another phone screen after a week.
Round 2(Mid April):
The question was around finding some stats from a stream of data. The optimal solution needed the use of self-balancing BST, TreeMap in Java.
Feedback: "Outstanding" :) After 3 weeks onsite were scheduled 3 technical and 1 behavioral spanning over a week each on a different day.
Virtual Onsites
Round 1(Mid May):
The question eventually was Parallel Courses which is topological sorting and its follow-up.
Feedback: All Positive, could have done a little bit better on the design part. Google terms "Hire" maybe even leaning towards Strong Hire.
Round 2(Mid May):
The question was very long(the first 12-15 minutes went into understanding the problem), was required to code a bunch of methods. It was related to the stock market. I started off by using Binary Indexed Tree(BIT), which works but was not optimal for one of the APIs. After hints from the interviewer, I suggested PriorityQueue. Later, was asked to optimize space but then no time was left so we ended on that.
Feedback: Negative. Needed hints and stumbled as well while coding. Google terms "Leaning no hire"
Round 3(Mid May):
You are given a list of players and their preferred positions of playing in baseball. You have to form a maximum number of teams keeping in mind the preference of the players. If at any point in time no player is left to play a certain position then you can pick any player for that position. I gave solution using HashMap<Player, PriorityQueue<Position, PlayersPreferringThatPosition>>. Each team has 5 players, positions are 1 to 5 (mapped to index 0 to 4 in result for convenience).
[1,3,2,5,1,4,1,5,2,2,3,1], where i is the player id and players[i] is his preferred position.
Team 1: [0,2,1,5,3], i is the position that player will play and team[i] the id of the player
Team 2: [4,8,10,9,7]
Player 6 and 11 won't be chosen, you can't form a team with two players
Feedback: Mostly Positive, could have decided on input and output beforehand. Google terms "Hire".
Round 4(Mid May): Behavioral
Typical round with scenario-based questions and others were on my past experiences. I have varied experience and have many different stories (all true) so I did extremely well. The interviewer was very humble and very much satisfied with my answers. Google terms "Strong Hire".
After 2 weeks, the recruiter told me that my 2nd round wasn't that good. I need to appear for one more technical round. So, a week after this one more interview was scheduled. At this point, I was 100 days into the process and was very much mentally exhausted.
Round 5(Early June):
Not your typical DS/Algo round. It revolved around calculating the user retention for a website that runs on a single-threaded server. I was asked to design a few methods and write supporting classes. The question was very open, initially, I was only given one line of information. I kept on clearing out constraints, ambiguity, different cases while coding. Later I provided the correct solution and he was satisfied. Then he moved on to something which I didn't expect at all, Unit Testing. This threw me off, but I tried as best as I could. In between writing test cases, there came a tricky one in which I needed a hint. The solution for which was to use dependency injection. Followup: what if the server is multi-threaded?
Feedback: Leaning towards hire, not good enough
Rejected :(
Here are my 3 biggest learnings
- First and foremost, clear out ambiguity and constraints and decide on input and output of your methods at the very start before coding. This is a very important factor, it shows how well you can plan/design. Don't keep on grinding leetcode, because here everything is given to you to the point but during the interview, nothing is defined except a vague problem statement.
- Google has so many factors apart from coding the correct solution to judge you. Like dry running the code, coming up with different corner cases, if you needed hints along the way and how well you communicate your thoughts.
- Prepare to get surprised
That's all folks, hope this helps.