Preparing for coding interviews can be very overwhelming. There's so much to study... where to even begin?

The mistake many people make is that they study all of the data structures and algorithms in the world, but they don't study how to interview. It's not all about solving hundreds of Leetcode questions until your brain melts.

These are the 6 steps I use in every single interview. It's drastically changed my success ratio. I hope this helps you!

Step 1: Restate the Problem

I don't care if you've done the problem before. I don't care if you're the best engineer in the world. I don't care if you already solved the problem in your head as it's being explained. The very first thing you need to do is restate the problem.

But... why? The problem is easy! You just need to...

There are so many benefits to such a trivial thing.

  • It instantly starts your interview with mutual understanding. Communication is one of the most important things that you're being evaluated on. This shows your interviewer that you care about properly understanding problems without rushing into them.
  • If you're blanking out and have no idea where to start, it helps calm your nerves and gets you thinking in the right track. No really - it does.
  • Quite simply, it makes sure you understood the question right!

I have a really easy framework that I use. It takes ~10 seconds.

So, we want a function that takes in X and returns Y based on Z

For example, if the question is to find if a pair in an array of numbers sums to 0,

So, we want a function that takes in an array of numbers and returns true or false based on whether or not there's a pair that sums to 0

That's it. Yup. That's it.

Step 1: ✅

Step 2: Ask Questions

Another extremely important step that can be very easy to forget. Before you code, you have to ask questions. Think about:

  • Edge cases (really big and really small numbers)
  • Special cases (like empty strings/arrays, null params, repetition, etc)
  • What you should optimize for (time, space, readability)

Continuing the last example, I would ask:

  • Can there be positive/negative numbers in the array?
  • Is the array sorted?
  • Can numbers repeat?
  • Can I assume that adding two numbers together won't overflow a standard int?

I cannot tell you how many times I have had interviewers withhold important information to a question which I only uncovered by asking about it. Had I not, I would have done the question much differently.

If you get good at this step, it can save you a world of problems and definitely gives you bonus points for good communication.

Step 2: ✅

Now we can FINALLY start coding, right? Right?


Step 3: State Brute Force

Still no coding. The next thing you should do is state the brute force solution (and ideally it's complexity). This is the most basic solution, often acheived by just trying every possible outcome (hence "brute force"). You should only state this solution - do not code it!

But why? The brute force solution sucks! It'll make me look bad!

Glad you asked!

It won't make you look bad - you're not saying "this is the best solution!", you're just stating the first solution that comes to mind.

If you take nothing else away from this section, remember this: you're being judged on your problem solving skills. Not how quickly you can come up with the best solution.

By stating the brute force solution, you give yourself a starting point. Often times, the most optimal answer can come by directly improving inefficiencies in the brute force.

For our array example, the brute force approach would be to just check every single pair in the array for one that sums to 0. We have O(n2) pairs, so this would run in O(n2).

Psst! If you want to learn more about Big O, or just refresh your knowledge, check out The Complete Guide to Big O Notation.

Once you've stated the brute force solution, you're done this step. Not so bad so far, right?

Step 3: ✅

Step 4: Optimize

Welcome to the hardest step! Now that we have a starting point (the brute force), we want to find the most optimal solution.

This is the hardest step because there's no step-by-step guaranteed way to get the most optimal solution. There are only strategies to help you along the way. And quite frankly, that's all you need!

If you're looking for some interview prep, you can check out my online courses.

I've passed many interviews in which I did not get the most optimal answer. If you show your interviewer that you have good problem solving skills, and you get a reasonable answer with justification, you'll be golden. ⭐ Here's my process:

  1. Identify the type of problem - is this question about strings, graphs, dynamic programming?
  2. Recall strategies used to solve these kinds of problems. For example, if I have a graph problem, can I use BFS or DFS in any way to help me? For dynamic programming, can I use a memoization table?
  3. Refer to the details of the question for hints - does the data given to you have a particular order or property that can help you make assumptions?
  4. If that doesn't work, can I transform this into a different kind of problem?Honestly, this comes with practice. You need to solve questions yourself to get a sense of what strategies work and when.

Tip 💡: ask your interviewer as you're thinking out loud if you're on the right track. If you are, they'll tell you, and if you're not, you might get a hint out of it. Remember - an interview is supposed to be collaborative.

Once you find an algorithm you like, quickly check with your interviewer before starting to code.

I think this solution works and is optimal, how does it sound to you? Should I go ahead and start coding?

If you get the green light, you're good to go.

Step 4: ✅

Step 5: Code

Now we can finally start coding! Some tips:

  1. Keep it clean - it goes a long way. Print neatly if you're on a whiteboard and leave a line or two of space inbetween just in case you need to add something. And please, use good variable names.
  2. Don't worry about being perfect the first time. No one does this on the job, it's an iterative process.
  3. Make sure you know how to use common data structures in the language of your choice. This includes hash maps, hash sets, stacks, and others. You should also know the runtime of the common operations on these structures.

Once you're confident, you can move on to the last step.

Step 5: ✅

Step 6: Test

You've written your code - all that's left is to test.

The biggest piece of advice I can give you here is to test your code, not your algorithm. Go through the exact code you wrote down. This is especially important in whiteboard interviews where you can't run your code.

Run through some good test cases. What makes a good test case?

For starters, you don't need to test the same thing twice. Each test case should serve a specific purpose. Use your best judgment and make sure you've got your edge cases covered!

Step 6: ✅

General Tips

Some general tips to help you,

  • Talk out loud. Your interviewer is looking to evaluate your problem solving skills. If you don't talk, it shows very little about your process. Also, if you're talking through your thoughts while you're stuck, they can nudge you in the right direction.
  • Slow down. It's better to take your time than furiously rewrite your code.
  • Be honest when you don't know. In one of my Google interviews, I got stuck very early on in a question. Being honest when I was stuck rather than pretending I knew exactly what to do was the reason I was able to pass that interview (and eventually get the offer).
  • Draw diagrams. Graphs, linked lists, and stacks all pose great opportunities to let your inner artist shine.
  • Be confident! You got this 😃 Worst case, you don't get the job, and that's okay!