How To Pass Your Coding Interview

How To Pass Your Coding Interview

In this video i'm going to be going over my four-step strategy on how i approach technical interview problems and, in my opinion this has been the most effective strategy for me. So stay tuned because we got a good one for you coming up huge shout out to the sponsor of the video jetbrains academy. Technical interviews can be super stressful. However, with practice and the right tools, you put yourself in a good position to succeed. There'S even an article about how a developer solely used jetbrains academy to learn python and prepare for interviews and landed a job as a software tester at nokia. The thing i love about this product is that it takes all the scattered knowledge across the internet and consolidates it into one place. You just pick a track. You can pick python java, kotlin and more. The knowledge map shows you all the topics in that track and the connections between them jetbrains academy, is a project-based learning platform and you can pick the difficulty of the project depending on your proficiency level, as well as a personalized study plan which gives you things like Question of the day and topics to review, based on what you've learned and need to learn, there's also seamless, ide integration, so you can use the powerful features of jetbrains ides. Finally, you can upload your finished projects to github, which you can add to your resume, to showcase the various projects you've created so use this link right here to get your first month completely free and i'll also leave a link down in the description all right before We start we need a game plan. Most people think that coding takes up most of the time in a data structures, type question, but it's often not the case. So here are the four steps that i use. One is to understand the problem a lot of times. The interviewer will make the question vague on purpose, so you can't even answer it without asking questions step two is diagramming out the problem. This is where you actually without coding, you just figure out the steps needed to solve the problem. Step three is: writing out those steps. Basically, the algorithm and step four is just translating those steps into code all right. So, let's use an example problem for this demo. This problem is called twosum, i'm sure a lot of you have seen it it's kind of a classic, but basically you're, given an array of numbers and a target number and you need to figure out whether or not two numbers exist in the array that add up To the target number all right, so we have a couple of examples here on the top. We have an array of four elements with a target of ten. If we look here, we would see that two and eight would be our two elements that add up to ten. So this would return true. The second problem here uh. We can't just use 12 because we need to use two numbers that add up. So if we wanted to use 12, we would have to find a 0 somewhere. However, we do see that 6, as well as 6, add up to 12, so this would return true as well all right. So let's talk about the first step, which is really understanding the problem, because there's no point in trying to solve it. If you don't fully understand it now, obviously we don't have an interviewer to ask so we're just going to have to make some assumptions, but a few questions that you could ask are something like: will there be negative numbers? Will everything be an integer or could we have floating point numbers as well? Is the list sorted? How many elements can there be? Can there be zero elements? Can there be a million elements? Some of these questions might not even matter when you're solving the problem, but it's still good that you're thinking about them and you'll probably think of more questions as you go on, but that's totally fine. The next step is to diagram out the solution. Now this part will probably take the most amount of time - probably like 40 - to 50 percent of the interview all right. So let's take this first example here and kind of see how we can figure this out. So initially what we could do is we could just test every combination here and check if it adds up to 10

So initially, what we could do is have something like a double for loop, where we have one pointer pointing at the two and another loop that loops through the rest of the elements. So initially we would check two and seven that equals nine. So that's not true. We check two and fifteen again, that's not true. Here we see that we actually get to two and eight that equals ten. Then we return it true. So we found the solution pretty quickly, but we would potentially be having to go through every combination which would give us a time complexity of big o of n squared we're not using any extra memory. So this is going to be a space complexity of a constant. Now i did mention that this is like a brute force solution, so it's pretty slow. However, i still think, even if you initially think of something better, it's still good to start out with the brute force approach, because it's usually going to be the easiest solution and oftentimes. That'S kind of what companies are looking for like a lot of companies. They want to push out their product as soon as possible and a lot of times engineers try to over engineer certain things, but oftentimes it's important just to like get a solution out there, and then you can iterate and improve on it later on. So this is a good thing to mention to your interviewer. You know mention the brute force approach and then ask them is: is this acceptable or do you want me to optimize - and this is another reason why it's better to diagram your problem? First than to just jump into the code, because maybe your interviewer wasn't really looking for a solution like this, then you just wasted a bunch of time coding it up. So we'll assume that the interviewer wants something a little bit more optimized. So another strategy we can do is, we can say: okay, we're going to start at the two we're still going to loop through through the array when we get to 2. We know that we need to have an 8 somewhere in here in order to get to our target of 10

So we can use additional memory to keep track of what we've already seen. So what we could do here is we could use a set and say: okay, we have a 2 here. We know that we need to see an 8 at some point. So what we do is we could just save that here in this set, then we move to the next element. We get to 7, we say: ok, we know we need a 3 to get to a 10.. Is there a 3 anywhere in this set? No there's. Not but there might be later on so we want to just be able to save that. Then we go to the next element, we're at a 15. We know we'll have. We would have had to see a negative five at some point. Have we seen the negative negative five we check our set? No, we haven't so we go ahead and add that to our set we move our pointer to eight. We say: okay in our set, are we looking for an eight? Well? Yes, we are because we have one right here. That means that we have a pair that equals our target of 10, and then we would return true if we had gotten to the end of the array without finding anything. We know that there is no pair. That adds up to 10 and we would return a false. The reason we're using a set instead of a list is every time we would want to have checked this list here. We would have to iterate through every number and check to find our target number. However, since we are using a set, we're able to index directly into it and that saves us the time of iterating through the list, so what's the time and space complexity here well, we are only going through our list one time. So that's going to be big o of n and since indexing into the list is constant time that doesn't affect our time complexity. However, we do have to account that we are using this set here in memory, so our space complexity will be o of n because of the size of the set could be the size of our initial list. All right. So now that we have a diagrammed out solution, we want to write down the steps, and this is such an important step, because, if you just jump into the code at this point, your interviewer might not really know what you're doing and that's the last thing you Want to do is to lose your interviewer, because you're probably going to get docked for that, but showing the steps - and this could just be in clear english - ensures that you and their interviewer are on the same page alright. So what are the steps that we need here? We want to loop through every number in our array. If our set contains that number, we return true. Otherwise we add the complement to our set and the complement is just going to be the target minus the number. If we reach the end of our array, we know that we haven't found any two numbers that add up to our target and we return false all right, so we're almost there. The last step is just to take those steps that we wrote and just convert it to code, so i'm going to be doing this in java, but it should not look too different in other languages. So here we have a function that returns a boolean, we're going to call it two sum: we have our input, which is an array of numbers, and then we have our target, which is an integer. So the first thing we want to do is create our set. Next, we want to loop through every number in our array. Now, if our set contains that number we return true. If it doesn't, then we want to add the complement to our set. Finally, if we've broken out of our for loop and we haven't found anything, we return false alright. So at this point we have a working solution in code now, at this point, it's up to the interviewer and what direction they want to go but often they'll talk about testing. What kind of input can we put in that could potentially break this algorithm, so you're going to want to be thinking of things like okay? What, if does it work with an empty list or a list of one element? Is this going to work with negative numbers? Is it going to work with a list of duplicate numbers? Let'S try it with a list that returns false unless that returns true, just any type of like edge cases that you can think of all right. So there you have it my four-step strategy to ace your next technical interview and, as you can see, the coding aspect of it was really just a small portion. Once we diagrammed out our solution, wrote down the steps that we needed. It was really just a matter of translating those steps into code, so hopefully you guys learned a lot from the video. If you did make sure you hit the like button, make sure you you subscribe. If you want to talk more about this feel free to join the keep on coding discord server where you can connect with other developers, it's totally free link to that down in the description. Thank you guys so much for watching and as always, keep on coding, [. Music ] so stay tuned because we got a good one for you. Bye