Google | L3 | Tokyo | Apr 2020 [Reject]
12659

Status: New grad, a local top uni in Hong Kong
Position: L3 at Google
Location: Tokyo
Date: mid-April, 2020

Preparation

  • ~2 months of revision and leetcode
  • ~4 hours/day on LeetCode (3 weeks before the on-site)
  • ~10 Mock Interviews on a shared document

Interview Timeline

  • Jan 2020 - Applied through referral
  • Feb 2020 - Completed Online Quiz
  • March 2020 - Completed Phone Interview (1 round of coding, 45 mins)
  • April 2020 - Completed Virtual Onsite (4 rounds of coding, 45 mins each)
  • April 2020 - Rejection

Feedback
My recruiter said my communication skills are highly rated, especially in articulating complicated logic, defining inputs, outputs, and corner cases. However, the speed of problem solving, as well as optimality of solutions have not passed the bar yet.

Insights
Since my strengths are about communications, I would like to share some unique insights about coding communication (especially for some companies that require you to code on a shared document), that I have learnt from the interviews, instead of directly posting the questions here due to NDA.

1. Expect differnet styles of interviewers

High-frequency leetcode solvers may be confident enough to solve a question given a well-defined statement, with inputs and outputs clearly stated. However, not all interviewers will give you such a well-formatted setting. In fact, most are intentionally giving vague instructions. From my experiences, there are these few types of interviewers and you would apply different frameworks for each of them.

  • Type 1: The interviewer pasted the detailed question with inputs and outputs on the doc.
    This is your best luck. Just solve it as if you were solving a leetcode question.

  • Type 2: Throwing you a story and expect you to ask more.
    For example, a story could be like "A company follows certain hierachy. There are employees with different levels. A higher level can send message to a lower level. How much time is needed for all employees to receive the message from the top manager?" You need to translate the problem to "finding the maximum depth of the N-ary tree from root to leaf" and solve it.

  • Type 3: Mention the problems verbally without typing anything
    This happen more than 50% of my interviews. You must type the requirements or story to prevent forgetting any, and go on with clarification questions and approaches.

2. Clarification on Inputs, Outputs and Data formats

Often we implicitly assumed the inputs, outputs and other data formats. However, interviewers expect you to mention them clearly. Using the "1057. Campus Bikes" question as an example, the question asked in actual interview could be as simple as "Can you design an algorithm that matches every bike and person such that each individual distance is minimized?" You need to ask the following questions.

  • How are the bikes and people represented? Are they lists, tuples or graphs (e.g. 2D matrix)?
  • How are locations represented? Are they coordinates, latitude and longitude, or something else?
  • How is the data coming from? Are they in main memory? file? or streaming data? (need different DS/approach to handle each of them)
  • Are they sorted? Any range of locations? Are they floating points or integers?

Your goal is to get as much information as possible such that the final question looks like a solvable leetcode question.

3. Prepare elementary math concepts

Sometimes some elementary math comes into play. You may need them in certain questions. The examples are but not limited to:

  • Geometry (Slope, Areas, Perimeters, Vectors, Matrices, Orthogonality)
  • Characters Encoding (ASCII, bit representations)
  • Common distance formula (L1 norm, L2 norm)
  • Distributions (Uniform Distribution, Random Sampling)

4. Be ready to discuss scalability/distributed system-related quetions

If you are very good to be reaching this stage, you will probably need these mindsets to further increase your chance of passing.

Common questions regarding these topics are:

Some strategies to address the above questions are but not limited to:

  • Time-space trade off (Use alternative DS such that more memory is taken but less time cost for each run)
  • Pre-processing tactics (A higher time complexity for pre-processing is fine as you only need to pre-process once, but then later on have much better time cost for each run)
  • Concurrency optimization (Map Reduce, Multi-threads, etc)

Feeling
A bit of a bummer knowing that I have failed. One failure has higher opportunity cost for me (and other Hong Kong students) as there are not much SWE posts available. However, I think I am on the right track. I just need more time to solve more questions with speed and accuracy, which is a time game.

Comments (34)