What's up everyone, Sam here from Byte-by-Byte.com. And today I want to tell you all about the 10 things you can do if you get stuck on an interview problem, so that you can still make it through, get the answer and succeed at your interview. So what do you do if you get stuck in your interview? This is I think one of the most common things that happens to people. It's not that people don't know how to solve a problem, it's just that they get stuck and they don't know what to do about it.

So in this video I'm gonna go over ten different ways that you can get unstuck, which is really the key to succeeding at your interviews. So the first thing that you can do is to find a brute force solution to the problem. And this may seem obvious but what people oftentimes don't do is that they focus on trying to get the perfect solution the first time, instead of just accepting that let's get a solution first, and then we can focus on optimizing that solution.

Secondly they don't fully understand the problem. If you fully understand the problem then what that means is that you can conceptualize what you're doing at a higher level. This means that you can actually understand the problem more deeply and work through it because you have a clear understanding of what you're trying to do. If you're confused about what you're trying to do in the first place, it's really really hard to solve the problem effectively.

The third thing you can do is work through the problem by hand. And I love this technique this is one out of Cracking the Coding Interview, which I think is a really great one. And what this looks like is you're literally going to try and solve the problem as if you didn't have a computer in front of you. And then translate that into an algorithm.

So for example let's say I wanted you to figure out whether a string is a palindrome or not. Obviously if it's a really short string then it's easy to do. You can sort of see it but if it was a really long string how would you do that? Maybe you'd like go in from the outside and compare the characters. Maybe you'd start in the middle and work your way out. Maybe you would reverse the string and then compare the two. Whatever you do these are all algorithms that you can then translate into an actual solution to the problem.

Number four is that you can brainstorm algorithms and data structures that you know and see if any of them might be helpful for this problem. There are a lot of different data structures and algorithms out there. And sometimes there's an obvious one where if you see it, it's clear that it will relate to that problem. So for example if you're trying to find a path through a maze, then if you've thought about using graphs all of a sudden it becomes a lot more clear. And you can apply those graph algorithms that you know to this problem because a maze is really just a graph.

And moving on number five, consider all of the information that you're given. And this is something that I see people miss a lot, but especially when you're trying to optimize the solution, considering all of the information that is included in the problem is really important. So for example let's let's assume that you had your input and it was sorted and you're not using that information anywhere in the problem in your solution. Then probably there's a reason why your interviewer told you that the input was sorted in the first place and that can give you a clue as to how you might start to optimize the solution and solve it more effectively.

Number six is to simplify the problem. And what I mean by this is one of two things. One you can potentially solve a simpler version of the problem, and two you can potentially break the problem down into smaller subproblems so in in terms of simplifying the problem that is really going to look like, let's say that there are some parameters that you can change or some things that you can strip out of the problem temporarily that will help you get to the solution or get to a solution. That's a really good way to clarify your thinking and work through everything first and then you can go back to the full problem.

And the second part of this is also stepping or option number seven which is to break the problem down into sub-problems. I really like when people do this because you can break things out into methods, you can create more modular code, and that makes it… first of all it's way easier to understand and two it means that you don't have to do everything all at once. So like let's take the example of printing a linked list in reverse order. Well that would be really easy to do if we had a method that would reverse a linked list for us right? So if we break that out into a separate method now our logic for the remainder of the code is super simple and all we have to do is then implement that reversal method.

So number eight is to state take a step back from the problem. This is something I see a lot with people, is that they get really stuck in the weeds on a problem. So you might notice this if you find yourself wondering, oh what if I just switch the order of these two statements… or oh what if I make it less than or equals instead of less than. If you're not doing that for a clear reason and you're just experimenting, that's probably a sign that you're losing the forest for the trees and you should take a step back. There are lots of other things that could happen here too, but generally make sure that you remember why you're doing this problem in the first place. What is it that you are attempting to actually accomplish here and take that step back and look at it as a bigger picture.

Our second to last thing is to collaborate with your interviewer. I love this one because I think that most people don't do this and it's a huge thing that you can do to be more successful in your interviews. What I mean by this is ask the interviewer questions. Tell them what you're thinking and ask them what they think of that idea. This allows your interviewer to help guide the conversation and even if they don't tell you yes or no, like you got the right answer or you didn't get the right answer. They can still guide you towards the solution that they want you to get and they understand where you're at so they can do that much more effectively.

And the final thing is to ask for help. If you really get stuck, asking for help is not the end of the world. You're way better off asking for help and getting a small hint then you are not getting the solution at all. In the same way, you're better off writing inefficient code and completing it, then you are writing efficient code that you're only half finishing. It's better to complete the whole thing even if it's not ideal. Because this gives your interviewer more to judge you on, and more to work with.

So those are the 10 things. I also wrote a blog post about this so if you want to review them in a little more depth I will include the link to the blog post in the description for this video. And if you have not already, go over to the site and download our free e-book on dynamic programming at DynamicProgrammingBook.com. And also if you haven't subscribed to this channel, so that you get all these videos, and I look forward to talking to you guys again soon.