[0:00–0:05] Get settled & fully understand the problem. Work through example inputs.

[0:05–0:10] Find a brute force solution.No coding, just talk & draw pictures. If stuck, try by hand and translate process into an algorithm.

[0:10–0:15] Optimize your solution. Take these 5 minutes to figure out the absolute best solution you can in this period of time.

[0:15–0:35] Code up your solution. Even if it’s not optimal, it is better.

[0:35–0:50] Test your code and fix any issues.

[0:50–1:00] Questions for your interviewer.

The key here is that while in some cases there may be one “best” solution, there are way more problems where you can make different trade-offs and you have to decide which ones to make. As an interviewer, I love to see candidates who weigh the different possibilities.

You should always consider the space and time complexity of every solution you come up with. This gives you an objective way to evaluate which solutions are better than others and helps make a way more informed decision.

I’ll tell you that finding a brute force solution is 1000% better than not finding a solution at all. And if you start by immediately trying to find the optimal solution, it is easy to get stuck and end up without a complete solution by the end of the interview.

This accomplishes two important things:

1. It gives you a fallback plan. 
2. It helps you clarify the problem. 

Often, people dive right into writing code as soon, until you’ve fully worked out the solution. Writing any more code than just for thinking is a critical mistake for two reasons.

1.  if you want to move lines of code around, you have to either erase and rewrite them or draw arrows going all over the place.
2. issue with starting to code right off the bat is that it can lock you into a specific way of thinking about the problem. 

Your thought process is non-linear when you’re solving problems, so you may have thought you needed a HashMap because of some other line of thinking that you have since abandoned.

This is why it is so critical to stop every so often, especially if you start doing something that seems challenging, and look back at the big picture of what you’re trying to do. Whenever you’re doing something that seems unnecessarily complicated, look at your end goal and see if you can simplify your approach.

I love asking complicated interview problems. If a problem involves several different components, you as the interviewer get such great insights into how a candidate manages their thinking when there is so much to deal with all at once. The key to successfully solving these problems is to use abstraction. At its core, this means breaking out your code into smaller functions with more specific purposes.

I find that many students forget to apply the best practices they know from real-world coding to their interviews. They assume that coding interviews are totally different, so the things they’d do normally don’t apply. One of the things people forget all of the time is to test their interview solution. But would you ever commit code in the real world without testing it thoroughly first?

While test interviews has merits, there is one fatal flaw: Companies are notoriously bad at giving you any meaningful feedback. “So,” you might say, “Who cares? I can just judge my own performance.” Well yes, that’s true, but it can be really hard to judge yourself. You don’t know what criteria your interviewer is looking for (just getting an optimal solution to one problem may not cut it). And if you’re struggling to succeed, chances are there’s something that you’re not seeing.