How you talk about your code is as important as the code you write. You need to learn to think aloud while coding. And you need to learn what you should be saying. The first mistake that a lot of candidates make is they simply read out there code the writing, they say, like variable A equals 15. This is pointless and counterproductive. The interviewer can see the code you're writing, you do not need to read it out.

What the interviewer cannot see, is the reason why you were writing it. They want to see your thought process. They want to know what high level problem you're solving. Talk about your ideas, say, Well, I'm doing this because I believe I need to sort these items to get the one I want to find, or I'm doing it in this order, because I think this is how the requirements are to be interpreted. Repeat the requirements as you're coding. For the statements you write, tie them back to requirements, say this line code is due to this requirement, you said I am solving this one particular item.

And this is why I am doing this. By talking about the requirements and why you are compiling your code. It gives the interviewer a chance to say something that's wrong. It lets them remind you the requirements say Actually, that's not what he said. And let's then add clear clarification unless you give me details before you tend time coding it. If you're not telling them the things you're reasoning about, if you're not thinking aloud, they have to wait in read your code.

And then they have to come up with a response. And this waste time again. How you talk about your code is as important as the code itself. During an interview, you'll be talking a lot. This is the purpose of an interview. It's not just about the code.

By talking about your code. It gives the interviewer a chance to give you tips to help you out. think out loud, always. And don't just be reading what code you're writing. Don't just be reading the Variable assignments, don't be reading the forum's talk about the reasonings behind it. And if you get stumped, be sure to talk about what's actually blocking you don't just stand there and make noises like, Huh, that doesn't help anybody say specifically what's blocking you say?

I'm not sure what to do here. I think I had to do a search, or I'm not familiar, this syntax here. Don't be afraid to not know Just be sure to vocalize that you don't know and what it is that you're actually thinking of. While talking, talk about the why the reasons why you're writing the code, I just mentioned not to say the code explicitly because the interviewer doesn't need that they can read that. But they need to know why you're writing it. You don't want to wait for them to have to read the code, parse it, and try to rebuild a picture what you're doing.

No state specifically the reasons why you're doing anything. Why are you doing this? Loop? Is it to find some value? Are you trying to search for something? Is it the part of an algorithm?

Does it match some requirements, seeing what requirements you're working on at any given time are really helpful, specifically which conditions you're checking. This gives you a chance to chime in to tell you a way that's not what I meant. Or maybe you should try this instead, by talking about the reasons behind what you're doing, you have the best chance of involving the interviewer making sure they understand it'll high level and giving them a chance to help you. Silence is absolutely awful. During an interview, it gives the interviewer no idea what you're working on. chances are they're going to give you a few moments of silence like you think.

But if you're thinking in block, that's not going to help anything. So just avoid the silence. Make sure you see what you're thinking. Don't be afraid to ask for help. This is the part of thinking out loud. I think some people end up not saying anything because they're afraid to ask for help.

But it's okay. You can. You can ask for help. Or Cody, you can say, I'm not sure what I'm doing here. I'm going to be trying this. But can you tell me if this is right or not?

And keep coding in any case. So ask for help pause. But continue to work on your question. Give the interviewer a chance to help. But if they think you're doing all right, they may not say anything. So don't always wait for that feedback.

So ask for help but keep coding anyways. But don't just keep talking. This is also a problem. I see. Sometimes people talk and they have no pauses whatsoever. This doesn't give the interviewer any chance at all to say anything, they're not likely to interrupt you.

So make a thought, pause, make another thought make some code. It's sort of a stepwise process. Get back and forth, get the communication going both directions. Make sure everybody has a chance. To speak. Be aware that some interviewers deduct points for asking questions.

I don't agree with this, but it happens. And there's an important point to be made here though. It's far better to have a few points deducted, then not be able to solve the problem. Because I can guarantee you, those same interviewers, if you don't solve the problem, you're going to lead a very bad impression. But solving the problem with a few points, Doc is better than not solving it at all. If you're asked something about your code, if the interviewer says online, eight, why are you doing this if statement, or where does this number come from?

Or What is this string? The first thing you should do is answer the question directly. Specifically, what have they asked? answer that? The second step, try to understand why they've asked that question. Sometimes just because they don't understand and you're simple explanation should be not.

But sometimes they be asking a leading question and me asking like, why did you do it this way? Because I think there's a better way. Try to answer that question as well. Or at least ask them if they meant something more. But don't jump right into that extended reasoning. This frustrates me sometimes, too, when there's simply a bit of code that I just don't understand what it means maybe there's a syntax error, something goes wrong and ask, Well, what did you mean to do there?

And they jump into an advanced explanation of what they're thinking and how they can change the code. It's like, That's not what I meant. So first off, answer the questions asked, don't avoid the question answered, and then work on an extended question. If it seems like that's what they want. Don't go off into war stories either. Often, an interviewer will point out certain bugs or you'll notice certain bugs yourself, and it'll trigger memories of a project you worked on last week, last year, however many years ago and you'll want to divert Just say, you know, I encountered this in a project once.

Often the swamps of our graphic rendering code I had bla bla bla bla bla. The issue here is it's good to show experience, but you don't want to waste time. When coding you're focusing on the code, the interviewer wants to see how you use experience from the past to solve this current problem. If you have experience that directly relates to the problem you're solving, you can use it as your reasoning to code. I am attempting to solve it this way, because I worked on a similar problem. We solve it a similar way on this previous project.

And so I'm going to see if it works here again, but do not divert into long winded stories from the past that are not relevant to the interview. It cost you time. And time is something you don't have a lot of during these coding questions. Ask for clarification about the requirements. Many questions posed are left intentionally vague Or they're just vague because they're not well worded. Either way, it's important you understand what was really being asked.

Sometimes these questions will come up during the coding. So you may have taken a few minutes to design beforehand. A lot of the specific questions won't come to actually coding, don't be afraid to ask. You need to figure it out. And a lot of interviewers will looking for Oh, how do they respond? If they've intentionally given the ambiguity, they want to see how you deal with ambiguity while talking about your code, only talk in a way you feel comfortable in only reference technologies that you actually know.

Don't use this as an opportunity to play buzzword Bingo. You're not here to spout off the many names and the patterns, analogies, libraries and things you might know. You just don't know what the interviewer knows and if you use a term incorrectly, that plays against you. So only ever use words and phrases and terminal that you actually understand if you're confident using in a sentence