What this article is:

So this is going to be an article detailing how I got my offer at Google / Meta + a lot more companies that I cannot bother to mention here, and am still in the process of getting (though so far this season has hit a 100% success rate with any company that I can get an interview with).

Also to note that these were for L3 positions, so I thankfully did not have a system design. So just know this is an article aimed at those who are in mainly algorithm preparation.

Basic Preparation:

Okay so first let’s talk about the basic preparation. First I recommend if not already I have a video all about the preparation phase, timeline, etc. So I would give that a watch as just basic background.

Second, let’s go through what I think really made me successful in this interview season, which ultimately came down to fundamental understanding and consistency in how I break questions down. It is no secret, if you read my Written Guide, that I love Grokking the Coding interview. This is b/c it really creates a solid foundation for approaching problems. Especially for me, for this last 1.5 years or so, I had taken on the responsibility of teaching 20+ people into FAANG level equivalent companies, and b/c of that, I taught them over and over Grokking.

And this is really where a lot of my understanding of algorithms came from. B/c I constantly had to teach people over and over again the same material, I really began to understand how problems broke down, why were we approaching this way, and trying to simplify the material for other people. So I highly recommend, that if your coding ability is already high enough, then your main focus should be on the analysis of why you approach things, and how to break it down.

Master the Coding Interview Big Tech on Udemy.com, their Question #2 and Question #3, (though the whole course is at that quality), I think is most exemplary of the analysis you need. You need to be able to break questions down at a fundamental level.

I then also did questions like Blind 75, to further practice against harder variations of questions, and just cover my basis. B/c at a certain point it is also just being exposed to different types of questions, and ways to approach. And through it, all were able to solidify across almost every question type.

How did this Translate?

So once I had my foundations and ability to analyze, I then organized everything into a coding template. The interview is rated along 3 main axes: communication, problem-solving, and coding, with a (1-4 score) with the objective being to get all 3s or more.

So to maximize my chances of scoring 3s or 4s, by using my coding template, I could break things down into:

1. Questions

• Where I ask questions about the problem in hopes to cover edge cases, confirming my understanding, and showing that I am not just blindly diving into the question with technical solutions and answers. This is where I find most people mess up, they just immediately dive in trying to solve the question.

2. Test Cases:

• Where I give test case examples to come back to later to confirm against, but also to confirm my own understanding. You never want to start a question without full understanding, only to finish the interview realizing you didn’t understand the questions and were coding the wrong thing every time.

3. Observations / Thoughts:

• Where I break the question down into what are my thoughts, initial observations, potential patterns, why I am discarding certain trains of thoughts, and just diagraming on the shared IDE some of what I think.
• This is so that the interviewer is able to understand my thoughts and help confirm if I am right or wrong at any time throughout the interview. Again, this is a huge thing ppl make a mistake in, they do not go and verify with the interviewer throughout the interview if they are on the right track, and make sure the interviewer is able to succinctly follow along.

4. Coding:

• Finally, you obviously need to code. And I think while this may seem straightforward, a lot of people do not take into considerations things like you can have pseudohelper functions. In my real interviews for Google / Meta, if something was annoying to write, let’s say converting an array into a frequency hashmap, and this is just a setup to the main crux of the problem, I literally just said, I’m going to assume I have a countFreq() pseudofunction I can call, let’s call it here, and move onto the main crux of the problem. And I can always come back to this if you want me to show how I would code it later.