Let’s Discuss Coding Interviews

Li Yin
Algorithms and Coding Interviews
6 min readAug 23, 2019
Image credit to dashbouquet

Did you ever get frustrated reading bunch of books and blogs revealing you the interview process, the mostly asked questions in interviews, the hiring statistics, and how the interviewers evaluate their candidates. Glassdor, Reddit, …, websites like these never end to keep putting pressure on interviewees.

In my humble opinion, it is a waste of our precious time to go through all these readings, unless you are a hiring manager or a recruiter which makes these tedious statistics and researching part of your job and you are surely paid for it! REMEMBER everybody’s time is important, spend it wisely. Albeit English is my second language and as raw writer as possible, I know that Cracking the Coding Interviews does not live up to its fame, the writing itself is not enjoyable at all! Personally, I would rather read a book that amuses me or work on my personal project that has some meanings or just enjoy it with my friends and families. Plus, it forms a vicious cycle between interviewers and interviewees; interviewers are expecting skills more than needed for a position because they are assuming you have studied their questions well so that they raise the bar and ask more difficult questions, and in return, it forces interviewees to study the exact questions used in interviewers from a specific company right before the interviews.

What really matters is the fundamental algorithmic problem solving skills, communication, and coding skills. You do not need to spend a month practicing or memorizing all possible solutions to the revealed coding problem database of the company you found online or given at a interview training camp before the interview.

If I’m telling you this, you would argue with me, “Then how do I prepare my interviews and do I need to?”

My answer is YES! You need to prepare for your interviews, but you do not need to go through those painful materials. Instead, knowing a general hiring process is enough. Most interviews for roles of software engineers consist of testing two parts of your knowledge: algorithmic problem solving skills and role-related knowledge such as machine learning or web-development. The information of the general hiring process for interns and full-time positions, in a specific area, is usually given by recruiters or you can get by asking them directly, “what to expect in the interview”. This kind of preparation should be done in less than a day!

When you are fresh in the college or just get started in the field, especially when English is your second language and you are not quite fluent yet, interviews are intimidating. Here are a few tips I can give:

Do not be afraid of applying

First and of the most important tip: Do not be afraid of applying! Apply any company that you want to join and try your best to make it in the interviews. Also, make sure the positions that you are applying to fits into your true passion. No need to check out statistics about their hiring ratio and be terrified of trying. You have nothing to lose and it would be a good chance to get first-hand interview experience with them, which might help you next time. So, be bold, and just do it!

Schedule your interviews with companies in a descending order of your favoritism.

This way you get as much practice as possible before you go on with your dream company.

Mocking Interviews

Before doing real interviews, do mocking interviews; either ask your friends for help or find online mocking websites. I found that interviewing.io is a good choice. PRACTICE is the key!!! I had four periods of attending coding interviews:

  1. First round in the early of 2017, when I had no clue about coding interviews. I used Cracking the Coding Interview and Introduction to Algorithms as my main materials to prepare. The first interview I had was Google, and I failed miserably. I prepared for a month or two.
  2. Second round was one year later at 2018. This time I got to know LeetCode, and did way more practice. I still failed Google, Facebook, but made it into a few companies such as NVIDIA, INTEL, JD.COM, and VIP.COM. This time I was still not that great and confident in coding interviews.
  3. Third round was from Sep, 2018 to the Jan, 2019. This time I practiced a few coding interviews on interviewing.io. I did a lot of coding interviews, and a lot of onsite interviews too. I passed the coding interviews for companies such as Apple, Walmart Labs, Facebook, Amazon, and so on.
  4. It was only until my recent round of interviews that I realized how important the mocking of interview is. I was overconfident, blinded by the triumph of the last round of interviews. I went to Google coding interview without much preparation and practice. I performed terribly during the interview: First, I overworked due to preparing the dynamic programming just in two days within the interview and went to it with a tiring and cloudy brain. Second, I did not full comprehend the problem and analyze the examples. I went straight ahead just grasping it as a related problem. I gave out the complexity analysis, wrote the code, and only until I was about to test the code I realized that I was not solving the exactly same problem. What was even worse was that I cant solve the right problem, maybe due to the lack of time, being too nervous, or being lack of preparation, and I panicked. I started to mope how I messed up my interview right in front of the interviewer and I did not even ask the interviewer any question at the end. I was too sucked into my own failure. Later, after all the moping, I reserved a few mocking interviews, and decided to overcome my feeling of failure with more and more practice. And the effort gradually shows. Here I draw a few conclusions from another round of experience.

It takes a series of struggles before you get the karma of passing

The last time I can almost pass any coding interview was because I practiced a lot, struggled a lot, and eventually got a comfortable point where the outcome was nearly all passing. We need to make sure we are not nervous so that our brain would shut down itself.

Ask a lot of questions to get a well-defined question

Before we start to work on the problem, ask a lot of questions to check with the interviewer: Did I understand it right? Do I need to care this or that special case? What if there are duplicates, should I care? This is an extremely important mindset: We show that we wont waste effort by getting the problem right. We show that we can work efficiently and productively as an engineer. So do not start to work on the problem before asking questions.

Work with examples and do not worry about code

We need to work around a small examples, even if we first just come up with naive solutions. First, work on it, and show it to the interviewer your analysis: time and space complexity. Then, work around it and try different approaches to improve. Do not care too much that you might fail at the first few tries. In this process, the interviewer will see your experience in problem-solving and how that you are trying and trying, and will never give up! They might even point you to the right direction. Then give the time and space complexity analysis proactively. Interviewers actually don’t enjoy poking you for the answer.

Before we straight up the detailed logic in the algorithm, working with pseudocode and examples. After everything is done, you can check with the interviewer if it is a good timing for you to start to write the code. And let them know that what you are going to use to implement, and how that you did not do some implementation due to the time limits but better implementation does exist. After the coding, run some examples with the code to make sure everything is in place.

Now, what’s left is to brush up your knowledge in computer science, which goes to learn, practice, practice, and PRACTICE!

This maybe just my editorializing opinion, but purely facts. What do you think? Tell me either at the end of the blog or shot me an email!

I’m working on Introduction to Coding Interview, a section in my book focusing on practice algorithmic problem solving skills and problem-patterns.

--

--