Do you truly understand the question you've been asked in an interview? It goes beyond the specific requirements. I mean, you have a specific algorithm, right? So the simple API you have to design the code you have to write. But you need to understand as well what the interviewer is expecting you to do, how they're expecting you to solve it. Do they want you to stand on a whiteboard and comb through solutions, draw diagrams?

Do they want to see specific running code on a laptop? Are they happy with a bunch of hand waving and chitchat type discussion where you collaboratively come up with a solution to the problem? Maybe jotting down some notes and writing some pseudocode Do you know what type of interview is being expected? This is something you can do as part of your research into a company. Some companies have specific formats, and you should figure out what that is. But you can always figure out in advance and every interview is going to be unique.

Regardless of what you read, be prepared to understand what each interviewer wants. watch their cues, watch their prompts, try to see whether they want you to work through solutions specifically, or they just want to talk about the solution. When being given requirements, write them down either write them on the whiteboard, write them on paper, type them in a text editor. Learn how to write this down quickly jot down the primary points. You can ask if they have a printout, but they often won't. I often get this in my interviews, but part of my interview is to actually make sure you can understand the requirements to give you and to see that you can ask questions for clarification.

And don't be afraid to ask for clarification. until you start coding and even after you start coding requirements aren't always clear. You have to work on certain things, but you have to understand what the interviewer is looking for. When we talk about the code, we said you have to wonder how much do they want error checking to this what sort of hand wavy They want specific bounced checks how the syntax here? What are they looking for? Don't jump to coding immediately, unless they say it's okay to do.

So you should always have some sort of design some sort of ideas. This doesn't mean go through four or five minutes coming up with design. Maybe it only takes like 1020 seconds, ask the interviewer you can even tell the interviewers like, all right, I think I got enough design, but I'm going to continue working on this while going through the code. if that's okay with you always give this sort of leading cues to let the interviewer jump in and tell you what they're looking for. Get in the habit of stating your assumptions about the code. Or even asking about it if you're uncertain how many people will be using, what limitations you have, what file format might you be supporting?

How long can that string be? state them and talk about them. It's good to bring up some of these during the design case, because it's very difficult to design algorithms for an input of 100 items as it is for 100 million items. Try to know this in advance and you can only knows in advance whether it's stated you've listened to requirements clearly you've written it down, or you've asked the interviewer don't automatically assume that you have to come up with a super scalable solution. Once you understand those requirements, only write for them don't make your code support all future requirements only support the ones you have to solve now, you don't have these to work on this you have maybe an hour actually even as generous an hour interview may only have a half hour to work on the actual code. So focus specifically and solve the requirements that's why it's vital you understand them during the design when you're talking about what your assumptions are also state these assumptions state the limitations what you will and will not be able to do look at the interviewer and check what the reaction is.

Do they seem okay with that? They may not always say something but if they have like that grimace on their face and maybe you're wrong. Ask them specifically your feedback. And when you talk, talk with pauses, give them a chance to correct your understanding. Not all code interviews are focused on algorithms. Now, I often get this question with some of my candidates because I don't tend to ask algorithmic complex questions, I asked things that are more in line with day to day coding, and not all interviews are going to be focused on the algorithm.

Many interviews are going to see Do you know how to combine modules together? Do you know how to come up with a program? Do you know how to solve an issue that deals with the database with a file with configuration? Make sure you know what type of question you're answering algorithm questions have a different expectation of the code you write, then do API questions. And knowing this difference will help you out while writing that code. If you're uncertain, ask and I repeat this a lot.

Ask about the expectations. If there's a big whiteboard behind you, they probably expect you to write in a board but doesn't hurt to ask because again, some of might just want to chit chat. They might want the board to be used for diagrams or some abstract thought process and not actual code. If there's a laptop, he might have to write the code, but it might just be there for them taking notes. You don't know make sure you ask anything you're uncertain of. Make sure you ask.

And anytime you do something makes that you're doing some even if you pick up that whiteboard marker, start writing say, I'm gonna write some code Now assuming this is what you want. Don't be afraid to ask, wait for their answer, see what they say look at their body language and see how they judge it. You have to learn what the interviewer is expecting. A pretty important reminder here though, write code. And I'm going to say this again, just to drive it home write code. This is a coding interview.

So even if it isn't abstract, even if you're doing diagrams, make sure you're doing something, not just sitting there wondering what you should be doing. If there's any questions, start writing code. Don't design forever, don't start talking about your code and never actually get to the code. If you're drawing diagrams to explain it, make sure you say, and this is going to lead to this code, and then actually do that code. I get a lot of people that actually sit there and design land for way too long. And this is why you have to be able to read the interviewer.

You have to know when you have to get into the coding. And don't worry about being perfect. You can refine this as you go along. This the other sections of this class, talk about how to think and how to listen, use that so you know how to move along. Use that to get the progress going. But make sure you're always doing something.

And that's what I embody, when I say write code, even if they're not looking for code. Do something, make sure there's progress going on all the time. Don't get stuck in a quagmire of perfection and design or anything. Make sure you're making progress, show them what you know. Understanding what the interviewer wants can be challenging, but it's really important if you intend to doing well in the interview. You have to tweak your performance.

You have to know what type of code they're looking for, if any, whether they want to chit chat, how they want you to write it, what you want to do, following the cues of the interviewer waiting for prompts listening for them, understanding the requirements, understanding a load, all of this works together to give you a better chance of making a positive impression and that limited time you have