How you write your code is as important as the problem you're solving. One of the main things I get is that you should be writing clean code. This helps communicate to the interviewer that you know what you're doing. And it also helps them read the code. That is use correct naming, use correct structure. write this as though you're writing proper code and communicating to a future programmer.

Your code is communicating with that interviewer, the better they can follow what you're doing, the better. They'll understand where you're stumbling, what your blocks are, and the better they can interact with you. This is not the time to use short names, it's not the time to use clever tricks. use proper coding, it may seem like it's taking a bit longer, but trust me from my experience, those people that try and do it quick and keep it short and dirty, actually end up causing themselves more problems as they lose track of what their code is doing. So keep it clean, and make sure everybody knows what the code is doing. I recommend working top down in your program to work on the important parts first.

And that is start with the most important aspect of the question the algorithm or whatever it is you're supposed to be doing. Many times I see candidates start from the ground up, they start with the basic classes, they start with the functions they think they'll need. They build features that may have not been used. It's a big distraction from solving the main problem. Focus on the top down, show how you're going to solve the problem and then expand each of the parts as necessary. You'll find that in some interviews, the interviewer won't even want to see these individual parts once they see the main code.

Also for you. It keeps you very focused, know exactly what you've done and where you have to go. The top down approach is the best way to utilize your time in this interview situation so that you don't lose track and you don't write code that you're not going to end up needing. Think about the corner cases. Next Your code is going to have to deal with. You don't always have to code them, but at least mentioned them to the interviewer mentioned how the inputs have to be within a certain range of what the limitations are.

Ask them if you have to handle them explicitly if they want the handle explicitly, then handle the code if they don't, and just keep mentioning what they are. Be attentive to any off by one errors or boundary issues that your code may have. Though you are working on like a high level problem, and solving the core question is important. It's also important to show that you know how to deal with these day to day limitations of coding. You know what you should be watching out for, and you know how to write robust and stable code. Ask the interviewer if they'd like to have test cases for the code.

I've not seen it often, but I have seen it come up, where if you're going to run the actual code, you'll have test cases and at the bottom showing that it actually works. These may be just a simple one showing the positive case works or to test some of those boundary conditions. But before you do this, ask your interviewer, not all of them will want them a lot. I'm just going to walk through the code visually and decide whether it works or not, or asking questions that way. Ask about cleaning up your code before you do it. Not all interviewers want you to spend the time going through to make the code perfect.

Sometimes you're using an editor that doesn't allow it in the online interview, you may be using a mic board where it doesn't make sense. Sometimes you can just hand your wave away to make sure that the code works. But definitely before you start cleaning up your code, make sure you ask the interviewer whether it's important. Sometimes it's just enough to point out the things I like, I'd like to change this variable name, this function is of a correct name. Oops, I've made a mistake here. I'm gonna have to change this here.

But making these corrections can actually take a long time. And if you just jump into it without asking the interviewer, you're again wasting valuable time. You need to have this interaction with the interviewer to understand what they want because time is not on your side. As always The limited commodity here and you don't want to be wasting it. Make sure you practice coding and I don't mean the various algorithms here. I mean, practice coding in the environment you will be given.

If you think you'll have a whiteboard, then get up and code on a whiteboard, find somewhere, paste a piece of paper the wall if you don't have a whiteboard, and actually code on them, you need to get this experience to not be off balance. Once you're in interview and you're facing with a whiteboard. Also, try doing it on paper, writing the code on paper, I've actually done this before internet, you load up a few different editors, ones you're unfamiliar with and try coding in them. Everything, everything is going to be more difficult than the editor you're normally used to. That's why it's imperative that you get practice in these different setups and make sure that you can write code in a variety different ways without Stumbling on how you're actually going to do it or worried that it's not going to turn out right. Learning how to hand wave an interview will save you lots of time.

As I mentioned, with all Changing your weight. If you can just kind of with your hands say, well look at this, look at that I can fix this and fix that. You can save yourself a lot of time. Body language is a very important part of the interview process. And you can use it to save the amount of time you do uncoding. You don't want to stand there stiff without doing anything.

Because that means you have to commit 100% of the code near and your voice was instead with a little bit of motion pointing things out and understanding how to weave things away magically, you can save yourself a lot of time coding. Learn to type. This is one of the very frustrating things I get with candidates. They sit down and they start coding and they type the keys at a snail's pace. Now I know it's not a game of how fast you can code and I don't expect you to be a fast typist, but I expect some baseline ability. If you're slowed down simply because you're looking at the keyboard hunting for keys.

You're just not going to Finishing interviews is going to look very negatively on you. Even if you do finish the interview them watching your code slowly is going to reflect badly on you. So learn how to type. discover whether syntax is highly relevant or only lowly relevant for the coding interview. When I conduct an interview, I'm not so concerned about minor syntax errors and missing brace missing semi colon, perhaps there's some annotation or you got something wrong in the function call. But other interviewers are like, very strict in this regard, and will penalize you for every little missing bits and piece.

Now, you should be able to review the code and try to make it as clean as possible. But you can actually ask the interviewer how relevant syntax is, will you be running the code? If you're in an interactive ID you might be which case is highly relevant, or will they be reviewing it? Or will they just be going through in their head and how relevant is the syntax you have to adapt to the interviewer here, obviously, getting a cindex correct takes longer. So you Don't want to be spending time on it unless the interview is going to be placing value on it. If the interviewer mentioned something that you're unsure of, don't be afraid to say you don't know.

But don't stand there and stop coding, attempt to code something and explain why you think this is the right thing to do. Maybe you don't know the right ribery call, maybe you forgot something. Don't stop coding, keep coding, make an assumption, state that assumption, say this function is supposed to do this. I believe this index does this. And keep going see how the interviewer reacts if they just let it go, and they correct it or what happens there but never stand there and not do anything. Once you're coding, keep coding and it's important to keep coding but also admit that you don't know how to do something, the making a guess or you're making an assumption.

And just keep going. These are many things to look out for while coding. Remember your code is a communication with the interviewer. This is an interactive session. You have code you have your body language, you have many things communicate. Every interview is different.

They have different expectations of what that code wants. It's not a bad idea to ask them how relevant is this syntax? What are they looking for? How will this be evaluated? Be sure to practice on a whiteboard or real paper in the real environment. The code is important.

Make sure you do it well.