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.
- Code interview is about communicating ideas not writing code.
- DO NOT code without having a clear picture of the whole algorithm.
- Give a naïve solution first then the real solution.
- Do the test and complexity analysis before the interviewer ask you do.
- 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
- During the interview, consistently communicate with the interviewer and make sure you are on the same page.
- 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.