“One thousand five hundred eighty two”
- That’s the total number of Leetcode problems it took for someone to crack Meta. For most normal people like you and me, solving
so many problems on Leetcode is not possible. Infact, in a recent survey that I conducted
on my Linkedin, only x% of people who responded have solved more than 500 problems. This brings me to one good news and one bad
news that I have for y’all. The good news is that “Leetcode is not enough”. You can easily do better than someone who
has solved more Leetcode problems than you. The bad news is that “Leetcode is not enough”. If you were thinking that solving a few Leetcode
problems is all you need to crack coding interviews. Well, this video is for you. There are so many other things that are equally,
if not more important than practicing leetcode problems. Let’s do this. The path itself is the goal. A coding interview is not just about solving
the problem, it’s also important how you get there. Take this example of a very famous problem
called “FizzBuzz'' which most of you can easily solve. You are given a number n. For all numbers less than or equal to n, print
“Fizz” if the number is divisible by 3, print “Buzz” if the number is divisible
by “5” and print “FizzBuzz” if the number is divisible by both 3 and 5. If none of these conditions are true, just
print the number itself. Here is a very simple solution for this. Go through all the numbers from 1 to n. Check if a number is divisible by both 3 and
5, and print “FizzBuzz” if it is. Otherwise, check if the number is divisible
by 3 or 5 and print “Fizz” and “Buzz” respectively. If none of this holds, just print the number. To most people, this code would look perfectly
fine. But, can you spot the problem with this code? Pause to give yourself a moment. If you look closely, the condition if the
number is divisible by 3 or 5 is being checked 2 times. Now, let’s say I change the problem from
multiples of 3 and 5 to multiples of 3 and 7, you will have to change 5 to 7 at 2 different
places. For a simple piece of code like this, it might
be ok. But when you are working in big codebases,
this is not a good practice. So, by asking a question as simple as FizzBuzz,
the interviewer can easily see if you will be polluting their codebase. A better way to write the same code would
be this. Start with an empty output string. If the number is divisible by 3, append “Fizz”
to it. If the number is divisible by 5, append “Buzz”. If the output is empty, set it to the number
itself. And print the output. In your quest to solve problems using Prim’s
algorithm, do not forget to write clean code in the interview. Always think about readability and maintainability
of your code and stay away from one liner solutions. Clarity of thinking and communication is another
thing that is very hard to learn from Leetcode. I have kept clarity of communication along
with clarity of thinking because I believe that you can not communicate effectively if
you can not think clearly. The great American writer Mark Twain in a
letter to his friend wrote: "Sorry for writing such a long letter. I didn't have time to write a short one.". Effective communication is always short and
simple. Let’s take an example to understand what
strong communication skills look like in a coding interview. You are given a list of intervals that might
be overlapping. You need to merge all the overlapping intervals
and return a list of non-overlapping intervals. So, if you are given 2 overlapping intervals
like this, you need to return a list with only one interval that has both the intervals
merged. Let me give you a moment to pause the video
and think how you would communicate your solution. Here’s what I would say: “I will sort
the intervals. Then, I will start at the first interval and
keep merging it with the next interval until I see an overlap. When there’s no overlap, I will add the
merged interval to my answers. And then I would do the same thing with the
next unmerged interval in the list.”. By saying this, you have done 2 things: One,
you have painted a picture for the interviewer. He knows what to expect when you start writing
the code. Two, You have already made the code you are
about to write very clean. You have said things like “I will merge
intervals”. So, you will need a helper function to merge
intervals. You also said that you will merge only if
you see an overlap. So, you know that you will have a helper function
that will be called “can_merge” which you would use to check the overlap of the
intervals. Now, all you need to do is to put your code
where your mouth is. Sort the intervals. Start at the first one. And if you can merge it, merge it. If not, add it to the answer and do the same
thing with the next interval. Clarity of thinking plus Clarity of communication
with Clarity of code, it’s a deadly combination and no number of Leetcode questions can teach
you all three. When I told you how I would communicate my
solution, there’s a minor detail that I skipped. I assumed that your interviewer can understand
and speak English as well as you expect. Well, that’s not always possible. Imagine that you get an interviewer with a
strong accent like me. On youtube, you can just skip my video which
I do not recommend because there’s a good chance your interviewer might have a similar
accent as me. So, I recommend that you subscribe to the
channel. Anyway, in such cases, you will have to find
other aids beyond verbal communication. One of these can be Math as Math sort of is
a universal language. You can also communicate via writing if needed. Walk through some test cases in writing before
starting on the code. Remember that in an interview, the onus is
on you to clearly communicate what you are thinking. I see so many people blaming interviewer’s
to further pump their already bloated egos. Don’t do that, it will not help you in the
long run. “Being present” is another thing Leetcode
can not help you with. Imagine that you are working through your
solution to the problem. And your interviewer thinks that there is
something wrong with the code you wrote. But, you are fairly confident about what you
have done. What would you do at this moment? Well, interviewing is a collaborative exercise. And you need to be present in the moment. Don’t just go with your train of thought
and keep writing code. Take pauses and address any questions the
interviewer might have for you. Many times, the interviewers actually want
to help you when they ask you questions. So, pay attention to your interviewer. Another time you need to be fully present
in the interview is when your code fails to compile or gives the wrong answer. Pay attention to the error rather than just
copy pasting it on google. Or doing some random changes hoping it would
fix the problem. This is a sign of an inexperienced programmer
and it leaves a bad impression on the interviewer. Use this as an opportunity to show your interviewer
how good you are at debugging. If the interviewer likes your debugging process,
she would rank you as well as, if not better than, someone who compiled and solved on the
first go. Another thing Leetcode can not teach you is
how to talk about your past projects. There are 3 key questions we want to answer
when talking about your projects. What did you do, How did you do it and What
was the impact? What you did is going to be a quick summary
of the project and why you did it in the first place. How you did it is where most beginners make
mistakes. When explaining the how part, we want the
interviewer to feel 2 things. One, they should be able to see that the project
was challenging. Two, they should feel that the project had
a big scope. It’s not always possible to achieve this
with every project but that’s the goal. After establishing how you achieved the final
outcome, we want to make a strong statement for the impact. Many people completely miss this step. Ideally, we want to talk about some key metrics
here. These metrics are called by different names
like Key Performance Indicators or KPIs. Or Objectives and Key Results or OKRs. I will leave a link for you to learn more
about them in the description. Having said all that, practicing interview
style problems on Leetcode is still the most important step to crack coding interviews. If you want to know the Leetcode strategy
I used to crack Google, Meta and Amazon, watch this video. My name is Sahil and I will see you in the
next one.
