Whiteboard Coding Interviews: 6 Steps to Solve Any Problem

(bright musical tones) - One thing I want to talk about today is how to ace that technical interview. And this is really one of the hazing processes of getting a job in tech: you have to walk into a room with another developer, someone you just met, they'll introduce you, they'll introduce themselves, and I'll give you a

problem

and you'll have to

solve

it in a slate, which is totally unnatural, I understand. It is usually not coded on a

whiteboard

. You usually work with people you know. So it's a pretty intimidating process for beginner developers; Actually, to be honest, it's intimidating for everyone.

It's one of those things that to this day, when I interview for technical jobs, I still get nervous, even though I've done hundreds of them, been on both sides of the table, and have also practiced a lot of

problem

solving.

coding

throughout my life and it still makes me nervous. So that's very natural. I wouldn't mind if you're nervous about it, it's just something to practice. So, at Fullstack we have invented a method we like to call REACTO approach to solving interview questions. So it's R-E-A-C-T-O, nothing to do with the REACT framework, it's just something that while I was coming up with an acronym, I wrote down the exact

steps

and REACTO was the acronym that came up.

So what does REACT mean? Repeat, give examples, describe your approach, implement the code, test the code, and then talk about optimization. Alright, let's start with R, repeat the question. You wouldn't believe how many times I'm in the interview room with a candidate and I'm excited about the candidate and we're having a good chat and then we get to the programming question and I say implement this and the first thing they do is take the cap off the pen and start writing on the board before you really understand the question and I can tell because the first step they say is something and I just know that they are going to take the wrong path. path.

Now, a secret is that when you interview someone people like to use the questions they are comfortable with, so there's a good chance they've asked this question 100 times and this is the first time they've seen it. So they already know all the paths you can follow that will be wrong. So you immediately go down the wrong path and that immediately puts the whole interview on a difficult footing. So the first thing you should do is just repeat the question and that will often help you A, understand it better and B, really make sure that the things that you don't understand you can work out with the interviewer as you do.

We are repeating the question. The second thing is to start writing several examples. So before you even write any code, write: here are the parameters that I will pass to my function and what I expected to get, right? So just create a little table, a two column table and say, given these parameters, what result do you expect, right? This is another way to really understand what exactly the question is because often you'll get a lot of understanding from just understanding input, output, input, output, right? You're trying, one way to think about this is that this problem is a black box.

How can you begin to understand what is inside the black box before you know what is inside the black box and what comes out the other side? So list examples. This is another great way to keep the conversation flowing and make sure you understand what the question is asking. Now the third step A, describe your approaches, right? So start talking about the approaches you're going to take. Will you look for a recursive solution, an iterative solution, a heuristic solution? So give the interviewer some insight into his logic and thought process and really help him understand the kind of path he's following so he knows he'll be able to do some reading too if he's on the right path, but how?

They answer your questions. So if you say you know what? I'm going to take a recursive approach and they'll look at you like you're sorry. So you know you're probably on the wrong path, right? So if you say, well, I'm going to take a recursive approach, I say, okay, that makes sense, then you're interpreting the interviewer a little bit in addition to interpreting the question. So take some time to talk about your approach. Again, a lot of times people give advice, they keep talking, they keep talking in your

interviews

and what they really want to say is these kinds of things, right?

You keep talking about your thinking, not what's happening in the code, and you realize you've done three things. You've probably gone about five minutes without taking the marker out of the case and starting to write on the board. Okay, so after you've talked about your approaches and you've confirmed an approach, you say this is what I'm going to take, usually the interviewer will give you the feeling that you're on the right track. Then you start writing in the code and follow the path of writing code. So C in REACTO is for code and you know there are so many things I can say about code we can go into more depth if you have questions leave a comment below.

I'd love to talk about how these different problems are actually coded. You have all kinds of different thoughts and ways to

solve

a problem. But one thing I really like is that I heard this advice from the author of Cracking the Coding Interview, Gayle McDowell herself, and she calls this

coding

, breath first. So I'll give you a link to the talk she gave at Fullstack on breath coding first. And you'll hear it's a little trick, right? Because you know that in programming we can, we like to decompose our work into functions, right? And exactly the same here, break down your focus into high-level functions rather than what I'm actually saying, more the imperative things you're doing.

So, for example, instead of writing a for loop to iterate over some part of an array or to iterate over some data structure, you just write iterate data structure between parentheses and the comma of the data structure, right? And then the idea here is that you're breaking down your approach from a high level into smaller

steps

, right? So we call this idea "breath first" coding and I'll tell you a little bit about why I think this is actually an amazing trick: A lot of times, you can get caught up in something that's trivial but is quite complex in the minutiae right?

And those can be things like a regx, right? You can really spend a lot of time debugging a regx. A lot of times when I'm working on a regular expression, I spend a lot of time before I get it right and you can really get caught up in that stuff. You can really get caught in the boundaries of loops. You can really get caught up in the different variable names and these are things that are simply not worth wasting time on when you are still thinking about the problem from a high level to a low level.

And a lot of times, if your approach is right, your core algorithm is right, and the fact that you wrote, hey, this step is to check the regx of this string, the interviewer won't even ask you to implement it because they assume that, as long as When Since they understood that this is what they should do right now, I agree with that. The underlying details are not that important. Alright, having coded some additional tips, right? So leave space between each line for editing, right? Writing on a

whiteboard

is not coding in VS Code or coding in Sublime Text, it's very difficult to edit, right?

You can't really move things, so write big and with plenty of space between each one because you'll most likely go back and delete, you'll insert a few lines and once you start writing, insert the arrow here. and one small thing, a small code everywhere that is difficult for you and the interviewer to understand. It really starts to become a mess, a jumble to work through. The second thing I really like is the star things that you're not sure about, right? So as you go, there will be some things that you'll be very confident in and others that will tickle in the back of your mind that you know I should go back and check this.

I'll say it here and you know, leave a star and say, you know what? I'm pretty sure this is how this function works or I'm pretty sure these are the array reduction parameters or I'm pretty sure, anything you're pretty sure to leave a star in there, you can return. This shows that your level of confidence matches the interviewer's understanding of your level of confidence in what you're saying because a lot of times, if you're semi-sure about something and you don't convey that you're only semi-sure about it, it could happen. Okay, this person doesn't know what he's talking about.

Therefore, always try to indicate to the interviewer the level of confidence you have in what he is saying. And actually many times it is okay to use pseudocode in the interview. Most good companies or most good interviewers are not there to make sure you know JavaScript syntax. They are not there to see that you have memorized most of the developer network. They want to see how you think. They want to see how a problem is solved and that's why it's okay to use pseudocode. And so, for example, if there's something where you're just one section of code or maybe you've split the code into these three main things and this function, you can't really understand the syntax for it, feel free to pseudocode it.

Just write it in English and you will get back to them about it. Okay, so the fifth step is testing, right? So after you have written your code, you will feel relieved. You're like okay. I have something on the board. Now it's very important to show diligence and go back and say, well, let's take some of those examples that I wrote earlier and run them through my code, right? So choose a set of parameters and just run it. And one thing I like to do is get another color marker and just mark up your variables as you go through the process, right?

So you're saying it's okay. A here's one, this loop is zero as I go through the initial one and then I go through the initial loop, here are the different steps that I think it's taking and then here are what's changing, etcetera, etcetera, right? So review and test your code. Run the examples and see if they really work. This is a really important step because if you take this step, chances are that unless your algorithm is perfect from the start, chances are the interviewer is seeing some problems that they want to see if you can see those problems too. .

Alright, the final step, and this is the most important one, okay, this may be one of those that should really set you apart from the rest of the pack, right? You have repeated the question, you have given your examples, you have described your approach, you have written the code, you have at least tested on the whiteboard, you have written your variables, the last thing is the O and This is what I call optimization and runtime . Optimization, right? This is often something that is a bit confusing especially to beginners, but this is really the idea: how will this work for large data sets?

Or how does this algorithm that you created work under different types of data sets, different data sizes? This is where we hear a lot about the big O, this is the big O of N, the big O of N squared, the big O of M multiplied by N and maybe you went with a brute force approach and maybe you went with the Christopher's approach, so this is more, you know, approaching the big O is a little more detailed than I want to get to in this talk, but you really want to, as you know more about the big O, just specify this is what I'm thinking about optimization and this is what I think this loop and this inner loop will give me an N squared.

It just shows the maturity that you're willing to, or are able to think about at a level of if I put this code into production, what will happen to our codebase? So, you know why we thought of the REACTO framework or why I came up with this REACTO framework, right? And I think the first, most important thing is not to start writing well when you have the correct code. Because this is my picture: your brain is working on multiple levels and as soon as you start writing, you start engaging in paths that could be wrong, right?

But the more time you get, the more time your brain will have to load everything you've practiced and trained, so give your brain some time to think, right? Give your subconscious brain some time to load things into memory before you start writing, because in writing, once you start writing, I feel like you start to commit. Two, you really want to start the conversation because once the conversation is flowing between you and the interviewer, it's much easier to continue the conversation once you're coding, right? Because then you can say things like well, I'm a little stuck here, but if I think about the approach I described above, I think it would be something like I need to somehow find a base case or I need to figure out my recursion. passed.

So the conversation continues to flow once started. So, an additional tip is: keep thecalm down, right? You're not supposed to know the answer right away because these problems are supposed to take some time to think about and solve, right? So focus on analyzing the problem and I think these problems are a little bit unfair because, for example, one of my favorite examples is Find me a loop in a list of links, right? So you have a list of links, see if there is a loop in it. And the algorithm is named after someone because I think they wrote about it in their PhD or some kind of thesis paper, right?

So if you don't know the answer or if you don't know that trick, it's unlikely that in a situation where you're nervous you'd think to do it on the spot, right? So it's kind of a test, not because you're a genius and can figure out all of computer science in a 30-minute interview, but because you've been exposed to this information, right? Because even after you've been exposed, you still have to remember it, implement it, execute it, so the reality is, don't stress because you have to figure these things out. If you don't know the answer sometimes that's okay, right?

You can still get a job, you can still get a job even if you don't get the answer and turn it into a conversation. Ask questions when you get stuck. I think this is just a matter of human nature. It's very uncomfortable to be in a room with someone and no one talks. If you ever want to do a social experiment, just go out on the street, someone asks you something, and you just look at them, and as you look at them, you'll see that they're continually uncomfortable. They start moving, they will start looking in different directions because the silence is very uncomfortable and this is not for you because many times it is you, you are lost in your thoughts, right?

But your interviewer is sitting there like, wow, I don't want to work with this person because every time she's stuck, she just sits there, which makes me very uncomfortable, right? Whether this is fair or not, your job is also to make the interviewer feel comfortable and just keep talking, keep trying to verbalize what's going on in your mind, right? Even if what you have in mind feels like it's totally out of place, right? You have to let the conversation flow and learn to read the interviewer a little and how he responds to your thoughts. And the last thing I want to repeat is don't start writing right away, right?

It's a reflex, you want to know, maybe you want to buy time or I don't know why people start writing right away, but the first thing you have to remember is not to let your hands touch the marker. Repeat, give examples, describe your approach before you even touch the marker. And really this is something that our Fullstack students practice a lot and those who practice a lot do it well. They come back and tell me it works like a clock. You're in an interview, you're thinking REACT, REACT, REACT, REACT, react oh, right? I hope this helps and as you always know, the most important thing is to practice too.

So there's a lot of

interviews

, there's a lot of practice interview platforms, meeting up with a friend and just walking through the REACTO framework. Practice it, and as a warning, don't come in and say: Hello interviewer, I'm using the REACTO framework. I'm going to repeat the question. Make it natural. Nobody wants to feel like they're part of a script, right? So make it feel natural, but this is what you should think inside your head, these are the things I'm going to go through. So one last time, repeat the question, list your examples, describe your approach, code, test your examples, and then talk about optimization.

Very good I hope that helps. (bright musical tones)