Algorithm questions. These come up a lot. I know they're not your most favorite question. Some people they are some people will valance. But even if you don't, you have to know how to code algorithms during a coding interview because they come up so often. So make sure you study your algorithms, and learn a lot of basic algorithms.

Go take coding challenges online. There's many of these places and push yourself push yourself in the boundaries of what you don't know and things you thought you already knew and you need to refresh on. Make sure you know how things like lists and trees and tries and rate axes work. Make sure you know how to search make sure you know how to sort know the basics of all these algorithms, so that you can use them effectively in an interview. Keep in mind that most algorithms can be reduced from existing algorithms, or by applying those algorithms in practice the types of new questions you're getting are going to be geared around this, they're not going to be based on totally unique knowledge. They're going to be based on knowledge of algorithms that you should already know, at least in the interviewers mind.

Refresh yourself on some of the basic approaches to how we're going to solve things such as dynamic programming, how you reduce one form to another is splitting up into smaller ones divide and conquer. There are numerous ways that you can approach them and they're generic, instead of just knowing outcomes, know how you actually solve a new algorithm problems and how you reduce them to existing ones. For every algorithm you write while practicing state, it's big O complexity in both time and space. You need this knowledge because it's going to be asked, somebody is going to ask you, okay, what's the time complexity algorithm? They're probably just going to say complexity or they're probably just going to say big O generally, I think You can get away with big time complexity. But you should know at least the differences between time space complexity.

And you should be able to state all the comic books. And you should know what linear time is what logarithmic time is and what exponential time is, is going to come up. Your best practice is just as you're writing our rhythms for the interview practice, just state them, come up with them and see if it is okay. Don't jump in and give an optimal solution. Start with a basic solution. Show that you've understood the problem and that you can solve it in the most straightforward way.

Sometimes candidates fail to produce any code because they're so worried about whether solutions efficient, they don't even come up with that basic code. But that's the place you want to start. You want to come up with the basic code showing you to do it, it may be horribly inefficient. Maybe it's an exponential algorithm. It's some brute force approach that solves a problem but as long as you get solved, it least you can demonstrate some problem solving ability. And your ability to work through algorithms.

From there, you can ask the interviewer, should you optimize this? Or they may have asked you already, well, what is an optimal form of this? Maybe they came up with an complexity and said, You know, this looks very inefficient. Tell me what it is, you're going to say what capacity is and and say, is there a better solution? Now's the time to actually work through that better solution, discuss it first. Not all interviewers are going to expect you to actually write down a new solution.

Sometimes the optimal solution is extremely complex, and there's no way you can solve it within the framework conditions you, but you can definitely talk about it. You can talk about how you'd solve it. And that may be enough for the interviewer. Even if they want you to code it, talking about it first, less than give you feedback to tell you for them to tell you how you might improve it lets you work through your mind because the optimal forms are often not straightforward. You want to have a clear picture of how it's done first. So ask whether they have issues and talk through it and then coded if necessary.

You're going to get stuck. It happens. It happens to all of us and happens to me, I sit in front of the whiteboard, and suddenly I'm like, I have no idea what I'm supposed to be doing now. I don't know how to move forward this problem. It's okay to get stuck. What you need to learn is how do you get unstuck?

What are the techniques for that? The first one is start drawing a diagram. start drawing little boxes, lines or whatever that helps you visualize the problem. This can often jog the memory into thinking about something new to sort of say, hey, look, I saw it a different way. Talk about what you're thinking. Don't stand there in silence.

Say what are your thinking? What are your what is actually blocking you let the interviewer understand where you are, and give them a chance to respond. pause between sentences, look at them, engage them, let them give you some tips and help and help you move along. If you're totally be stuck. Just ask them, ask them for specific aviation. I'm not sure how to do this or just admit that you don't know how to do and say, Look, I'm stuck.

And I don't know how to get into an interactive process and they can may help you get unstuck. You can solve a simpler problem. Maybe there's something in the album that's a little bit too complex. But you know, something that's slightly simpler, maybe if you're one of the requirements, can you solve that problem? You can solve that problem and then say, Well, this is the basic one. And now I had to figure out how to work in this advanced requirement that shows a decent level problem solving and may also lead you to the solution that unique attempt to pattern that seems to fit.

Perhaps you're not sure how the pattern is going to solve it. But you've seen it before. And you've seen it solve this type of problem before. So you know that search is useful here. Maybe you know that you have the storage. And you can just try and put these items together and see if a solution comes out of it.

Again, it's not perfectly elegant, but if you're stuck, it's better than standing there. Doing nothing you need to show the interview, that you can continually think that you're capable problem solving, you're going to keep performing in situations where you're not sure what you're doing. You may be reluctant to practice interviews because you don't think it's relevant to your work. And I kind of speak negatively towards them in interview situations. And I'm going to state one thing very clear. This is completely irrelevant.

Whether you need them in your day to day work or not, because they come up in the interview, it's something you actually have to be able to do to pass that interview process. If you don't know it, another candidate will, and that's going to give them the advantage over you. It's also not like it's wasted knowledge, though you may not use it in your day to day career. Lots of people do these algorithms do come up quite often a lot of people are in a position of doing algorithm development. So it's not like it's a completely foreign concept to programming. It is something programming should be able to do and therefore it's fair to come up with an interview.

So your opinion and whether it's relevant or not, doesn't matter here you have to learn this if you want to pass interviews with companies that give algorithm questions. Our this pose a particular challenge during coding interviews, you need to know how to work with algorithms derive them. You have to understand this as an interactive session. Don't jump into optimal solutions. Make sure you engage the interviewer. Make sure you let them help you when you're stuck.

And make sure it's a two way process when you're coming up with this interview, be confident talking about complexity, and be familiar with a lot of algorithms. You have to know algorithms to pass some coding interviews.