How to Crack The Coding Interview With Practicing Only 30 Questions

As we always suggested in our previous posts, it’s extremely helpful to practice with coding questions when preparing an interview. Basically you can start with some very general questions from books like “Cracking the Coding Interview” or Website LeetCode. And then when it gets close to your interview date, questions from past interviews of your target company will be more helpful.

But people may wonder how many questions do I need to prepare? What is the most efficient way to practice with each question? Obviously memorizing answers to those questions will never work and over the past I saw many people practicing in highly inefficient ways that could only make them feel as if they were improving.

Quality is always better than quantity. If you can take full advantages of each question you prepared, you don’t need to practice with hundreds of questions in order to crack the coding interview. In that spirit, I’ll give you the most practical tips and hacks now:


1. Don’t check the answer first

It’ll be totally meaningless if you go directly to the answer without trying to solve the problem first. Most of the time answers look quite natural and straightforward, which gives you the illusion that you could easily come up with the same solution. However it’s not always the case. Without trying to solve the problem by yourself, you won’t be able to know whether you are having trouble with this question, which helps you to check knowledge and concepts you are not familiar with.

Also by cracking the problem by yourself, you’ll have the similar experience as an interview, which is exactly what you are trying to practice.

2. Emulate the intense environment as much as possible

Lying in your bed with your Facebook/Twitter open, you won’t be able to take full advantage of this practice. On the contrary, if you have done a lot of practice in an environment that is as intense and nervous as a real interview, I won’t be surprised when you get your job. The philosophy is extremely simple, just practice with exactly what you’re gonna face.

To emulate the intense environment as a real interview, here are some tips:

  • Remove all distractions. Close all unrelated websites, turn off music and your cellphone and find a quiet place as you don’t want to be disturbed. If possible, you can also find a meeting room in your current company or a library, which is even better.
  • Set a timer. You won’t have 2 hours to solve a simple coding question apparently. Normally within 45min session, you’ll be asked 1-2 questions depending on the difficulty and 2 questions are more common. So set a timer to have an idea of your speed and I’m pretty sure you’ll realize how slow you are in the beginning. Also with a timer besides, you are very likely to be more nervous.
  • Talk while thinking. I can’t emphasize enough the importance of this point. By keep talking while thinking about the solution, you are actively communicating with the interviewer, which shows both your analysis and communication skills. Also it gives the interviewer a chance to hint you when he notices that you are not on the right track or get stuck. However it’s harder than it seems to be and you really need to practice a lot before getting adapt to it.

3. Code the solution 

Having a solution in your mind is far from really solving the problem. You won’t be able to understand this unless you try to code your solution and you’ll realize how important it is. There are several things you’d better keep in mind.

First of all, don’t start coding without a complete solution in your mind. Many people start writing down their solutions one minute after knowing the question. It seems as if they were faster, but in fact this is the worst thing in an interview. Without a complete solution, it’s almost for sure that you will get stuck while writing and if somehow you notice that you are not on the right track, you’ll have to clear everything on the whiteboard and restart. Also some people tend to keep writing meaningless codes when they get stuck, which can only waste their time.

Secondly, write on whiteboard or at least paper (I assume you are preparing for an on-site interview, please use some online code sharing tool for phone screen). Again the point is that always practice with whatever you’re gonna face in a real interview. If you will be asked to write on whiteboard, there’s no point to be proficient in your Emacs text editor. Also many people felt quite uncomfortable the first time they wrote on a whiteboard, so it’s better to get adapt to it in your daily practice.

Lastly, forget about pseudo code. I’ve interviewed so many candidates who can elaborate ideas clearly and have put down few lines of pseudo codes to better explain ideas, but eventually failed to write a correct and complete solution, not even close. Once you try to write solid code for every question you’ve practiced, you’ll definitely understand how different it is. If you can compile your code as examination, it’s even better but not necessary I would say.

4. Optimization

It’s hard to come up with the optimal answer in the beginning and you should always try to optimize your existing solution in every way. In a real interview, you will be asked to improve your solution with whatever approaches, which is exactly what we are practicing here.

In order to optimize your solution, the first thing is always analyze both time and space complexity. In other words, you should analyze the efficiency for every coding question you’ve practiced. This concept is extremely important in both interviews and real life projects and without a comprehensive understanding of it, you won’t be able to optimize your solution and you don’t even know how much you can optimize and what to optimize.

Sometimes optimization doesn’t necessarily mean improving the complexity from O(n^2) to O(n). Even the complexity is still the same, if somehow you can remove some unnecessary calculation, it’s still better.

The last step of this is to compare with the correct answer.  Remember that having a correct solution is not done yet, you need to know the optimal solution. Compare your code with the standard answer and make sure you fully understand the optimal one.

5. Stretch

Even for majority of the good candidates, they can at most finish the above four steps. To further take advantage of the interview question, you can ask yourself several follow-up questions to practice. Remember that this approach is not practicing with questions from nowhere, in fact I always ask a lot of follow-up questions if the candidate solved the problem correctly. What’s more, not all follow-up questions I have answers, what I really care is how each candidate analyze the issue step by step rather than the answer he provides.

To give you an idea of what kind of follow-up questions you can practice with, here are some great examples:

  • How do you test your solution? Testing is also an important area in interview and you can treat the interview question as a real life project and how can you guarantee the system works as intended?
  • What if the input size is too large to put in memory? How do you refine your solution and analyze the efficiency?
  • What if the input size is too large to put in disk? How do you solve the scalability issue?
  • What if you have infinite amount of memory? Any way to make the solution faster?
  • You can also try to change some restriction of the question, like what if it’s a normal tree instead of binary tree? What if you can store the dictionary in any data structure you like?

It’s extremely helpful to think about these follow-up questions and sometimes it’s also a great practice to come up with good follow-up questions.

6. Compare with other questions

As I always emphasized in the previous posts, it’s important to recognize common patterns in interview questions. Try to think all of the questions you’ve practiced as a huge network instead of separate dots, in fact there are so many correlations in between and many questions are exactly the same in essence.

A good example is for dynamic programming questions, majority of the solutions are of the same pattern (for interview questions). Once you can recognize and summarize this kind of pattern, it’ll be much easier to think in the right direction. You can check A Step by Step Guide to Dynamic Programming to know more about this.

Try to compare with questions of the same category like trees, linked list, arrays etc. and I’m pretty sure you’ll benefit a lot from this.


Of course it’s important to have enough amount of coding questions to practice, but I believe that it’s more important to prepare smartly. I’ve heard so many complaints like I’ve finished all the question on website X but I still failed the interview. Again quality is always better than quantity, only when you are preparing in an efficient and smart way, can you really improve your interview skills.

The post is written by Gainlo - a platform that allows you to have mock interviews with employees from Google, Amazon etc..

I'd like to learn more

Share on Facebook0Tweet about this on TwitterShare on LinkedIn0Share on Reddit0

4 thoughts on “How to Crack The Coding Interview With Practicing Only 30 Questions

Leave a Reply

Your email address will not be published. Required fields are marked *