That’s me 4 years ago when I was getting rejected
in every job interview I took. For the last 1 year before that, I had dedicated every single evening
of my life trying to learn programming and preparing for coding interviews. Even after working so hard,
it seemed like I was stuck in time and my life was going nowhere. No matter how much I prepared
and how well I thought the interview went, the answer was always the same. “We have decided
not to move forward at this time”. It took me more than 100 interviews before I got my
first big job at Amazon and another 2 years before I got into Google. Though my confidence was completely shattered by getting rejected again and again. In hindsight, there were 2
major benefits of going through this tough experience. One, I got to travel all around the US. In
those days, the companies used to fly you in for on-site interviews and I got
to visit SF, New York, Seattle and many other cities for free. Two, I learnt all the
ways you can fail a Coding interview. Today, I will tell you why so many people fail coding
interviews. Towards the end of the video, I will also tell you how you can use your
interviewer to help you solve the coding problem. The first reason why people fail coding interviews
is because they don’t practice like they are giving an actual interview. Let me explain what I
mean by that. Most people will go to a platform like Leetcode, pick a question randomly and
start solving it. What they don’t know is that the problems asked in the actual interviews
follow this very famous probability distribution. For those who are seeing it for the first time, this distribution is
called Normal Distribution or Bell curve. What this distribution tells us is that most interview
problems lie somewhere in the medium difficulty range and getting a very easy or a very hard
problem is relatively rare. Just to be clear, I am saying all this from my own experience
and I have not done any Math for this. Anyway, I have met so many people who spend their
entire time solving easy problems just to boost their confidence. And then there are
others who spend all their time worrying about the hard problems on Leetcode. In reality, it
is more beneficial to solve as many medium problems as possible. If you look at the distribution
of problems that I have solved on Leetcode, I have done roughly the same number of easy and
hard problems. And easy and hard problems combined make 37% of the total problems I have solved.
Rest of the 63% are all medium problems. Now, it’s true that you can not directly
start solving medium problems. That’s why I recommended starting with easy and slowly
building towards Medium problems in my last video. Talking about practice sessions being
very different from actual interviews, many people use the test cases to cheat
during practice. Let me show you how. Many people write the first thing that comes to their head and then hit the submit button. And then they use the failing test case to debug their code.
They fix their solution for this test case and submit again. Fail again, Submit again and this keeps going. You might be able to eventually submit your solution by doing this but remember, there will be
no multiple submits during the interview. Don’t get me wrong. You can always write your own test cases
in the interview and debug the issues if there are any. But most people would not have
any time left to do that. So, a Submit failure in practice might be equal to a Rejection in the
actual interview. I know that I am being too harsh here but the point I am trying to make is that
you should treat your submitted solution as the final solution in the interview. Once you start
seeing it that way, you will be more diligent and might develop the skill of picking those small
errors by yourself rather than by submission. Talking about submitting your solution, many
people give themselves hours to solve problems in practice. As you might already know, an interview lasts somewhere between 45 minutes to an hour. And that includes the introductions in the beginning and some time for
your questions for the end. So, giving yourself unlimited time during practice doesn’t prepare
you well for actual interviews. As I mentioned in my last video, it’s ok to take more time in
the beginning but once you become comfortable with interview style questions, take a stopwatch
and start timeboxing your practice sessions. Give yourself 45 minutes to solve medium problems at
first and try to get to 30 minutes if you can. So far, we have discussed all the things
you can do before the interview. Now, we will move on to the things you can
do during the interview to help you not to fail. This is where we will use the
interviewer to help us solve the problem. But before that, this video is not sponsored. So, if you want to support us, Subscribe to the
channel. When it comes to actual interviews, the first
mistake people make is that they don’t give themselves enough time to read the problem.
They get so distracted by the ticking of the time clock that they miss some important details.
You might think that it can’t happen to you but trust me, one small detail can cost you
really big in the interview. Let’s take this very popular question on Leetcode as an example.
In the 2Sum problem, you are given an array of numbers and a target number. You need to find 2
numbers in the array that sum up to this target number. You can assume that all the numbers in
the array are unique and the solution exists. You can pause the video if you want to solve it
yourself. The optimal solution of this problem uses a Hashmap. This solution has O(n) time
complexity and takes Order(n) extra space. Now, let me change this question a little
bit. Instead of giving you just an array, I give you a sorted array and the rest of
the problem remains the same. What will be the worst time and space complexity now?
The optimal solution of this problem uses two pointers and doesn't need a Hashmap. The worst case time complexity remains the same but the solution uses no
extra space. Now, you would think that you will never miss an important detail like the given
array is sorted. But, when you have already seen the more popular non-sorted version
of this problem in your practice time and the interviewer asks you the sorted version,
your brain can easily skip the sorted part to reach the solution faster. It has happened
to me many times and it can happen to you too. Another reason why people fail coding
interviews is because they violate the basic design principles of programming in the interview. This is how most people’s interview solution looks like. Everything that comes in the mind just gets dumped
in this one place and that is the final solution. In reality, if you want to make your life easier, you should break your code into helper functions if possible. This is especially important if you are using the same code again and
again. There are 3 major advantages of doing this. One, you don’t look like a newbie who doesn’t
really know how to write code at an actual job. Two, If the interviewer wants you to run the
code and you need to debug the solution, having well defined helper functions makes it very easy to debug.
That’s because you can test your helper functions separately if needed. Lastly, when you don’t have
enough time to code the full solution, you can just tell the interviewer that you will write this
helper function that has this particular behavior at the end. If you have some time left in the end, you
can obviously write the helper function. But if you don’t, the interviewer might be able to see that writing
the helper function is actually easier than the actual code you wrote during the interview. That
way, they will be willing to let it go if you complete the rest of the solution. This only works if helper function is not really the core part of the solution. So, make your life easier by using helper functions. Another reason people fail coding interviews
is because they don’t use the interviewer enough. Most people think that the
interviewer is just there to judge you and there’s some sort of adversarial relationship
between them and the interviewer. In reality, your interviewer is just another
person who, like most people, wants to have a good conversation. They are
there to unblock you if you get stuck. So, you have to use them wisely. First way you
can use your interviewer is by clearly explaining your solution to them. That’s because most humans
can not resist the urge to correct you if you are saying something wrong. And when they correct
you, listen to them carefully because they will drop some very useful hints. By doing this,
you can avoid the situation where you end up coding the wrong algorithm and it’s already
too late to correct your mistake. Second way you can use your interviewer is by paying
attention to clarifying questions they ask you when you are coding your solution. Most
of the time, interviewers do this when they have spotted something wrong in your code.
So, always pay attention to your interviewer. And this leaves us with the most common reason
why people fail. And that is, they focus too much on the things that are outside their circle
of control. Let me explain. This is the circle of concern. It contains all the things that you
can care about for your interview. These things include whether your interviewer is a junior or a
senior engineer. Whether the name of your college or having no degree will automatically get you
rejected. Or if your interviewer will show up on time or not. All these things impact the outcome of your interview. And within this circle of concern is a smaller circle that is your circle of control. This circle contains things like whether you have
good foundational knowledge of Data Structures and Algorithms. Whether you have practiced enough
questions on Leetcode. Or whether you will show up on time for the interview. These are all the things
that you can control. So, stay inside your circle of control and keep improving yourself. Once you
start doing that, nobody will be able to stop you. All the tips I gave you today are useless if
you don’t practice enough problems for your coding interviews. And Leetcode is the best resource to do that. If you want to know which exact questions to practice
on Leetcode and how to practice them, watch this video. My name is Sahil
and I will see you in the next one.
