Some Thoughts on Code Interview

Some Thoughts on Code Interview

In the last two months, I interviewed with Google for summer internship. I did three phone code interviews with engineers from Google. Recently I received a reject email from Google. At first glance, the result is disappointed and surprising to me. Because I thought I solved all the questions in the code interviews. I have good skills in problem solving and programming. I have solved more than 900 problems in Leetcode. Among all 7 Leetcode weekly contests that I attended, my top three rankings are 10th, 49th, 52th. In Bloomberg’s Wisconsin 2018 Qualifier code contest, I ranked 1st out of 67 contestants. This forced me to rethink about code interview and what I can learn from this lesson. Here are some of my thoughts.

  1. Code interview is about communicating ideas not writing code.
  2. DO NOT code without having a clear picture of the whole algorithm.
  3. Give a naïve solution first then the real solution.
  4. Do the test and complexity analysis before the interviewer ask you do.
  5. From my perspective, a good problem solving procedure is
    • Describe the essence of the problem
    • Show the big picture of your solution (strategy, e.g. this is a graph problem)
    • Describe the details (tactics, e.g. store the graph using adjacent list)
    • Briefly discuss the correctness of the algorithm, why this can work
    • Code as clear as possible (pay attention to design and details)
    • Discuss possible edge cases (e.g. empty array) and how you handle them
    • Conduct time and space complexity analysis, use big-O notation
    • Write some tests to demonstrate the usage and correct behavior of the function you wrote
    • Ask for possible follow up questions, think about more general question
  6. During the interview, consistently communicate with the interviewer and make sure you are on the same page.
  7. Treat the interviewer as a competent but skeptical programmer who is NOT as clever as you are.

Some thoughts list above could be applied to general problem solving. I think the most important lesson for me is think the problem as clear as possible before trying to solve it.