The Interview Framework that Got Me Offers from Google / Meta / Amazon + more

I've used this framework to get offers at Google / Meta / Amazon / Palantir / Bloomberg, and a ton more companies.

🟢 Join the Paid Discord

To get access to the Paid Discord section, DO NOT JOIN THROUGH SUBSTACK. Please join through: this payment portal

After you purchase, will ask you to connect your Discord account which will automatically add you to the server and give you the role.

Paid Discord comes with:

• Group calls

• Recruiter emails during recruiting season

• Access to old livestream

• Priority support on your situation

Overview

I write a free notion page guide (now have migrated it over to this substack) on how to get into FAANG. But one of the things I always have trouble communicating is this idea of using a coding template during the interview. Why?

B/c too many people in their pursuit of Leetcode become locked into when they go through an interview, to just begin solving the problem by writing code, and maybe at most have been told “oh, walk through the brute force solution before you begin”, which if that is you, that is the absolutely wrong way to go about it.

So this is going to be an article about how I consistently use what I call a “coding template” to get an offer at Amazon, Google, Meta, and many more companies (Palantir, Bloomberg, Intuit, so on).

How are interviews graded?

There are three major categories when you do an interview that gets evaluated:
Communication:

• Can the candidate understand the question / and get clarity when necessary

• Can they describe their ideas to a problem in an understandable way

Problem Solving:

• How good is a candidate in coming up with the solution to a problem?

• How good is a candidate at breaking down a problem to it’s core components?

• Do they properly talk about edge conditions, understand data structures, talk about time / space complexity?

Coding:

• Is their code well organized?

• Can they convert their thought to code?

• Is it properly validated / are they able to fix bugs etc.

The problem?

Well the problem is that even with these conditions, most people only focus on the coding aspect. They don’t focus on the other two. Even during studying.

Solution?

When you study act as if you are going through the interview, and during the interview also follow this pattern: Coding Template Google Doc Link with a lot more details

1. Questions:
   a. Confirm what the input and output is. It seems silly, but it just makes sure that you really understand the question and the fundamental assumptions behind it.
   b. If the problem is complex, can you rephrase the question into your own words? Again, this is about a fundamental understanding b/c there are often misunderstandings
   c. Can you apply any additional constraints? For example, are the inputs all positive? Integers? So on.

2. Test Cases:
   a. Come up with proper test cases or walk through the test cases given. Figure out why does changing one part of the input change the output.

3. Human Analysis!
   a. Do not jump into the question, or try to “brute force it”. Rather, try to think why do you as a human, are able to walk through the input / output so fast? (This is less effective on graph based questions), but otherwise this generally works.
   b. For example, let’s say that you are doing the popular two sum quesiton on leetcode, where you find two numbers that add up to a target in an array. The “brute force” is a double for loop, but we as humans don’t think like that. We instead, look at a number, remember in our heads the target_num - the current number, and as we progress through the array we keep a mental note of this. And if the array was really large, maybe we write it down on a notepad. But that already gives you a strong indicator how to approach this question.

   c. You can then afterwards, or if needbe begin to FORMALIZE IT. Eventually during the human intuition, you probably do need to refer to data structure or formalize your logic more rigorously. [Refer to the Meta question video to see an example of this “formalization” from human intuition into a structure to follow]

4. When you start coding, use comments to structure out your code, and with the human analysis done, you should already have a really solid structure.

5. If the question is a graph question, I would say this is an example, where I do just jump to skipping to saying “oh, it’s a graph”, but still even with that, I focus on the logic of how to go through the graph such as BFS vs DFS + the logic of the traversal.

Thus, your objective when studying should be, even if you have to read the solution first, is what in the question would lead you to reanalyze and rediscover the solution. B/c the hardest thing in interviewing is coming across questions we don’t know, and then having to synthesize a solution.

This is honestly the biggest gap between someone who consistently succeeds and those who consistently struggle, what level of understanding and analysis do they have of the problems that they study.

I’ve seen 2 people study 200 leetcode question, where one person he constantly grinded and analyzed and redid and taught the problems to other. This person ended up getting Amazon and Meta. While the other, just did the questions, read the solution, coded it, and moved on, but struggled with remembering the information. That’s the difference between the approaches, and I hope people can feel the difference too if you’ve been studying for any amount of time.

Why Does this make a Difference?

Many things contributes to why this coding template helps you pass:

1. Focusing just on coding, the interviewer has no way to validate your approach is correct till your code is written. And often, once you start coding if you are wrong, you now have a weird task of trying to forcefully fit your code to the solution, when you could be completely wrong. Going through the human intuition, lets you first build up in words what are you going to do, adjust it if needbe, walk through the example with the interviewer, then start coding.

2. It lets yourself stay more organized too. Trying to keep everything in your head is extremely difficult. Writing it all down is easier.

3. The interviewer often needs to copy what you wrote in the code editor into a separate document. You will just look more organized, more prepared, and look better having a structure than messy code.

4. The interviewer you want to make their job as easy as possible and make it easy for them to check the boxes. After the interview, they can more easily look back at your document, and remember what happened and write feedback why they believe you did well.

Common Mistakes:

1. Keep things moving. Your questions should be defined ahead of time. input, output, constraints, and then you can on the spot see if you can spot edge cases and come back to it.

2. During test cases, walk through variations so that you can figure out those edge cases.

3. Step #1 and #2, should only take 5 mins, and then by then you should be thinking about your “human intuition” to then eventually finalize to coding. You still need to get your conciseness and speed moving.

4. The human analysis should give you a way to “think before you code”, and not have to try to balance explaining every line of code and thought as you write. A big mistake I find is someone just jumps straight to coding, and tries to awkwardly verbalize every line of code they write. But if you had human analysis already, then there is already context to follow.

5. You still need to be fast. I’d say for Google, for example, you need to answer the first question they give you in 20-25 mins. Once you exceed that, it begins to look like you are slow. For Meta, it’s around 15-20 mins.

Video Walk Through Examples

Meta Phone Interview Question example:

Given an array of "tasks", where tasks are taking out the trash, doing dishes, etc.

and they are represented as numbers.

[0, 0, 1, 1]

Example this is taking out the trash at 0:00, taking trash out at 1:00, doing dishes at 2:00, doing dishes at 3:00.

Return how long it will take if you need to do at least K hours in between the **same** tasks. You may not rearrange the tasks

Example:

Input:

tasks: [0, 0, 1, 1]

k = 3

Then the output should be:

[0, _, _, 0, 1, _, _, 1] -> return 8 hours

Input:

[0, 1, 0, 1]

k = 3

Then the output should be:

[0, 1, _, 0, 1] -> return 5 hours

Google Interview Mock Question:

Google Mock #1:

Given X, Y, Z find all the possible combinations of: A, B where the following holds true:

A^X + B^Y = Z

Through asking about constraints of the problem you'll learn (otherwise the following is not given):
a. X, Y, Z are all positive integers > 1
b. There always exists at least one solution

Below is are the actual videos!

These videos are meant to be watched in order.

Meta Interview Question:

(FYI - I wrote the slightly corrected question above. Meant to write in the video the same tasks need to be k-spaces away from each other. So could be a tad-bit confusing in the video without that nuance.)

Google Interview Question: