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.<ol><li> 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.</li><li>issue with starting to code right off the bat is that it can lock you into a specific way of thinking about the problem. </li></ol>

Plan out the full solution before you code

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:<ol><li>It gives you a fallback plan. </li><li>It helps you clarify the problem. </li></ol>

Start with the brute force solution

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?

Test your code

The key here is simply to get more practice coding, and ideally do so in an environment where you are getting good feedback on your code. One of the best ways to do this is by contributing to open source projects. Not only is this a great way to show off your experience, but you will get the benefit of thorough code reviews and learning how to work in a production environment. If you’re new to working with open source, <a href="http://www.firsttimersonly.com/">First Timers Only</a> is a great resource for those looking to get started.

Get more coding experience

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.

Get good feedback

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.

Keep the big picture in mind

The first step of the FAST Method is to find an initial brute force recursive solution. This is something that you need to be able to do on your own for the FAST Method to be of any use to you. If you don’t know how to implement a linked list, then it doesn’t matter how many tricks you learn for solving linked list problems. your first step should be to dedicate yourself to learning all of the fundamental data structures and algorithms.either the <a href="https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-006-introduction-to-algorithms-fall-2011/index.htm">MIT</a> (Python) or <a href="https://www.youtube.com/watch?v=8mYfZeHtdNc&list=PLxc4gS-_A5VDXUIOPkJkwQKYiT2T1t0I8">Princeton</a>

Develop a strong foundation

[0:00–0:05] Get settled & fully understand the problem. Work through example inputs.[0:05–0:10] Find a <a href="https://www.byte-by-byte.com/brute-force/">brute force solution</a>.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.

Strategically approach each interview question

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.

Consider different possible solutions

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.

Use abstraction to your advantage

These list down great points on how to approach a coding interview

by Sam Gavis-Hughson How to make progress while studying for coding interviews Getting stuck is never fun. Especially when you’re working really hard. And yet, I find that this happens to people preparing for coding interviews all the time. You put in consistent work. You’ve gone through hundreds of practice