3. What Qualifies As Proficient | Welcome to the Coding Interview: You Suck

So we have another edition of Welcome To The Coding Interview, You Suck

I will be going over the standards for what it means to be gud, what it takes to be good, and why we set the standard for what it is.

We want to aim to get to some point of proficiency with our studying and we want to know where to aim. That way, we know how to tailor our practice. The purpose is to give yourself a benchmark to really know when you are sufficiently ready.

Let’s codify this concretely. There are 3 criteria we should meet.

1) If you can think of 2-3 solutions where 1 of them is the naive solution.
2) You know what questions to ask to get to the optimal solution and if those questions are answered, you can give an optimal solution.
3) You can do achieve a 80% success rate on the first try of a leetcode attempt.

Everyone can master #1 with little to no thought if they throw in a thousand mindless hours. But this is the least efficient method of actually doing well on the coding interviews. Because unless you have a photographic memory, no human can possibly memorize every single pattern and every single problem.

The caveat is that if there is a problem that doesn’t test a pattern you know or remember, then you just freeze.

And remember, as we proved in our last video, you just need to make a little more progress in your interview to double your chances of getting an offer. Imagine what failing a question would do to your chances.

This is where #2 comes in. And this is where the real skill comes in.

In my opinion, #2 is how we separate the best candidates from the mediocre ones. This means knowing what you need to know, what the right questions to ask are, and how to take the best path of thinking to get to your solution.

You begin to recognize common situations that you find yourself in, irrespective to the problem on the board. By actually thinking about how to unstick yourself in situations, you will begin to develop pillars and systems.

A mediocre candidate can be given a problem with a relatively simple path to a solution and solve it. A strong candidate can be given an unclear problem and make it look simple. That complex and nuanced problem suddenly turns into jelly when given in the hands of a strong candidate.

This is where we get to #3.

Is fairly reasonable to solve 80% of the Leetcode medium problems without thrashing with the compiler or needing hint in 15-20 minutes for an easy problem, 20-25 minutes for a medium problem, and 25-30 min for a hard problem

In fact, I might even err on the side of caution and aim for 20 minutes for the medium problems. As of this recording, the rumor mill seems to be giving 2 medium level problems.

► Full Coding Interview Guide Playlist:

► Social!

► Donate

► Want to get coached? Sign up here

As an ex-Apple Engineer, I interviewed dozens of candidates from entry to senior level.

I focus primarily on the thought process and strategy that goes into approaching technical interview questions, how a candidate can be more efficient with their time, and how a candidate can avoid a lot of the non-obvious cues that makes them appear weaker than they really are.

► Music

[stantonviaduc]

I appreciate your content. It's different. Confident you will get a much larger following.

[alexnyikaomuyonga]

Edbert great Job! I really appreciate the effort that you have put into breaking down everything.

[abhishekmulay]

As usual great job! Eagerly waiting for the next one.

[mrodriguezglobe]

Love the Kobe reference, thanks for the video bro

[myosubug]

I actually asked the same question to who's from my school got the job at google, "how do you know when you are ready?" he couldn't answer and I finally found the answer here after 3months lol

[waynegreen]

Great content! One suggestion I have is to talk slower.