00:00:00
The magic of technical interviewing comes down to prep. Parameters, returns, examples, pseudocode. But there's a few things that we have to do before we even get to the point where we're using prep and we're solving a technical coding challenge. When you're in the interview process, No part of that process should ever be a mystery. You should know everything that's coming up in that interview. If you ever sit down in an interview or you log in to the call with your interviewer and you don't know what's about to happen, you have fucked up. Say that one more time. You should never ever go into an interview having no idea about what's about to happen. So how do we know what's about to happen? We

00:01:00
ask. We ask the recruiter. We ask any person that we've been put in contact with. We say, hey, I have an interview scheduled for Friday. What should I expect in that interview? You should expect some behavioral questions and a technical question. Great. When you say behavioral questions, do you mean kind of just like the normal, Hey, tell me about a time you had this experience type question. Okay. And for the technical question, what should I prepare to be successful in that technical interview? Well, actually, we don't want to tell you what to be prepared for it. Well, that I don't want to waste your time and I don't want you to waste my time either. Right? Like I want to make sure that if you're going to test a very specific thing that I'm up to date on, that's a very specific thing. that way we're able to get right into the interview and I'm able to save y'all some time and make it better on my end as well. So are there any topics I should cover? Are there any specific things that I should know about for that technical interview? And if you don't, if you can't

00:02:00
share the topic, will it be like a coding challenge? Will I be doing something that's more like a leak code style question or will it be more of a code along? What should I be expecting in that interview? interview, right? And nine times out of 10, not only will they tell you what to expect, they'll give you like hints for that interview. And what you have to realize is that if you just ask, if you just ask, they're going to tell you most of the time. And sometimes, sometimes they give you way more than they should. Sometimes they give you way more than they should. I've had recruiters tell my students the exact questions they were gonna be asked during the interview, like the exact question. So you ask first. Then, once you've asked and you

00:03:00
have a rough idea of what you're getting into. The next thing you should do is Google the company, like someone's going to give you a lot of money. If you find something out about them, right? This is the one time in your life where a Google search can net you. High five, six figures, even because a lot of times the interview process is clearly online. A lot of times the companies will have blog posts on what it's like to interview at that company Like what the actual questions? And so if you haven't done your research with like what you should be like if you haven't looked up the company You haven't googled what their process is like They're gonna hold that against you. We had a blog post on Exactly what this interview was going to be heck we even put one of the questions in that blog post So not only were you not prepared you didn't do any research on the company, right? So you want to make sure that you google

00:04:00
the crap out of them because a lot of times they'll share details About the interview process directly from them Then you take it another level you will go ahead and look on glass door You will go ahead and look on GitHub and you're gonna try and find anything you can find about that company and what? the interview process is like so you not only have you asked and got it directly from the source but a lot of times on Glassdoor you can find not only like what the process is like but probably the actual questions same thing with github a lot of people push their solutions to github and so you can find sometimes the exact question you're gonna be asked on github now like I said I'm gonna show you how to play the game it's up to you if you want to play it But putting in that extra step helps you so that you're not going into these interviews. All right, going into these interviews

00:05:00
without knowing what you're going to get yourself into. That relieves some of the anxiety, it relieves some of the stress, and it makes sure that you are prepared. Yeah, like I showed you the Spotify ones before. I'm curious. Let's see. Let's do GitHub. We said SoundCloud, I don't even know what they like interview, like, is it one word? I don't want to do it inside of my, it just shows you my interview, right? Like, and this is not like a, like, this is not like a hard search. Like I didn't, I didn't really like go searching for it. I'm not using like the way back machine or anything like that. Like, I like there, we could. Right. Like these are older, but like, we didn't even try, right. We didn't even try. Right. We didn't even try.

00:06:00
So imagine if you gave it a good 15, 20 minutes of trying, like you're really getting in there. Right. Maybe you found like a type of question on Glassdoor and then you threw that and get like, you're, we're not even trying and we're already seeing stuff come up. Uh, you will also, you will also realize that a lot of companies don't change their interviews. I'll, I'll leave it at this. One of the top startups in Boston that pays the most has not changed their interview question in four years. And I bluntly asked them, why don't we throw those? I'm, I'm, I'm keeping it like, come on now, I'm keeping

00:07:00
it, I'm keeping it, uh, uh, keeping it on under wraps so that we don't put them on blast. And people are just like throwing company names in there, uh, hasn't changed it in four years. And so I, I asked them why, and I know one of the engineering managers that actually is in charge of hiring for one of their teams. And they said, the reason is why do we need to change it? The whole team knows how to look at that code. The whole team knows, um, how long it should take somebody to solve it. The whole team knows that intimately. and most candidates don't know how to solve it. It is an amazing filter for them, right? It is an amazing filter from them because it's not a trivial problem, but they actually, they say like, if you can't do the research, you can't look up the things that we do at the company. That's a huge, like, that's just like a huge misstep. Like they

00:08:00
haven't changed in four years. It's kind of easy to figure out what you're about to be asked. And then they don't actually care about the code at the end of the day. They care about your communication and collaboration during the coding challenge. They expect anybody that would work with them would already know how to solve the problem. So why does it matter if they know how to solve the problem? Like, because they look like it just doesn't matter. It's not what they're testing. Right. It's not what they're testing. And so it actually is an even better filter for them. If you can't solve it because they knew that you should have already seen it Yeah Seven minutes that I was asked the same interview question at a company out of New York City It was identical to what I found someone on Glassdoor had written three years ago I just did a test run of the question itself, figured it out, and was surprised to see the technical interview was the exact question

00:09:00
I had already solved when practice prepping for the company. That's it. Right? Because we have to realize that the technical coding challenge isn't like the make or break. If your company is hiring, and that's the make or break, and you're not looking at all these other things, that's your fault. So make sure you're doing the bare minimum to know what you're doing going into these interviews. Now, we've talked about PREP before. PREP stands for parameters, returns, examples, and pseudocode. It's a checklist of things that we're working through when we're interacting with our interviewer during a technical interview. And when I say technical interview, I mean a coding challenge. A lot of times these coding challenges were done on whiteboards and you're writing stuff out. More often than not nowadays, especially with the pandemic, everything is online and you're doing a coding challenge digitally either through a platform they share with you or you're sharing your screen during the interview.

00:10:00
And so this prep, this parameter returns example pseudocode which we're about to break down really does three key things for you. It helps you to better understand the problem that's being asked. It gives you about 15 minutes to figure out how you're gonna solve the problem. And it enables you to build a rapport with your interviewer. And this is the key thing. Technical interviews test two things. One, can you code? And two, do I wanna work with this person for the next two years? You're playing both games at the same time. And so by working through prep, Parameters, returns, example, pseudocode. You can take that time to build the rapport with your interviewer. So at the end they go, this was a great person. I really liked talking with them. I would definitely want to work with them for the

00:11:00
next two years. So I'm gonna vote that we hire them. Do we tell them that we've seen it or something similar when they give you the question? Uh, I wish I'm just going to copy and paste my notes. So I always have my notes on my side for my lecture notes here, here, here's my lecture notes, I'm just going to paste them right into chat so you can see that this is literally in, in the lit red. That was literally my notes. So the notes said, don't type out prep. Don't get excited. it, be cool, you want me to build a palindrome? What's a palindrome? Can you clarify what a palindrome is and don't snitch on yourself? We are lean mean interviewing machines. We've been prepping for months.

00:12:00
You've been doing a Code Wars every day for months. Now you're taking the interview process even more seriously, you're doing a challenge with me every day, you're doing leak codes now, you are prepping through each of these, you're adding them to your Anki, there is a really big chance that the question you get asked is a question that you have already seen. That's the motherfucking point of doing all this work. That's the point. That's why we do it all so that when we're in the interview, we've already done it or something at least very close to it. And so one of the things you have to do in that interview is, and I see it all the time When I interview, when

00:13:00
I interview folks, I can, I can pick it up. Right. But when somebody says, all right, tonight we're going to do a palindrome. I want you to tell me whether or not a word passed into a function is a palindrome. Some people, this is what they do. When I tell them a problem that I know they know how to solve, their eyes get real wide. They're like, Oh my gosh. Yeah. They're like punching the screen and stuff. Like, like I can see in their face that they know exactly how to solve the problem, that that's the code wars they did yesterday, that they just, they, they might as well, if I handed them the basketball, they'd be slam dunking over top of their monitor, right? Don't do that. Keep cool, be chill. Don't get excited. Repeat the question back to your interviewer, right? Make sure you understand, take

00:14:00
your time, and then walk through the challenge as though you've never heard a word of what they're saying. Take the dub, don't snitch on yourself. Cool, so what we're gonna do is we are going to use prep to solve a very simple coding challenge. I need you to use prep for every single coding challenge you use going forward, whether it's with me, whether it's on your own, whether it is a coding challenge that you are doing, I don't care. You will now use prep every day of your life, for the rest of your life, whenever you solve a coding challenge. You should be prepping at the mall at the studio at your mama's house Just be prepping

00:15:00
Okay now There are three types of questions that we're gonna run into. I Forgot wasn't on the slides There are slides for this Be prepping at the mall At the studio at your mama's out now anybody know where this comes from If people know where that comes from, I'll be impressed. I'll make you VIP if you know where that comes from No, we ain't hip. It was a reach. It was a reach. This is from Montana 300 Chirac remix. They strapped at the mall. They strapped at the studio. They strapped at your mama's house. So I keep that in my mind. We're going to be prepping at the mall, at the studio, at your mama's house, you do not solve a coding challenge for the rest of your life without doing prep.

00:16:00
Are we clear? Are we good? Can, can, can, can I just get a, just get a yes. We were signing this, this, this pact, this oath that we will be using prep for the rest of our days. Okay, cool. Now, there are three types of problems that you're gonna run into during an interview. There are gonna be methods problems, which are problems that you can probably knock out the park just with the methods that I've asked you to study. So for the past couple of weeks, I've asked you to study some very specific things. I asked you to study string methods and array methods specifically. I even gave you a list of the string methods. I wanted you to have memorized. I need you to have them memorized I need you to have them in your Anki because you will be surprised the number of interviews with just prep and Really knowing

00:17:00
your methods, right? You can get through a huge portion of interviews So I want people to realize, like, you can get through a huge portion of technical interviews without knowing any advanced data structures or algorithms, just if you know your methods really well and you know how to use prep. The reason why this can work is because a lot of these coding challenges, right, a lot these coding challenges will give you about 45 minutes to solve. You're going to take at least 15 minutes of the 45 to prep. Meaning you're walking through the parameters, the returns, the examples, the pseudocode. You burned at least 15 minutes doing the prep. The reason why we do that is because prep makes sure you build a rapport with your interviewer, but it also burns time.

00:18:00
because we're going to slam dunk solving the problem, but we might not get to the more optimal solution. Only you will know as you're going through prep, if you have a reasonable chance of making it to an optimal solution. What most of you will see very clearly is a way to solve it with methods and for problems that you can't solve with the methods, you're gonna do something called brute forcing. Brute forcing is where you just use the big four. You're using your variables, your conditionals, your loops, right, and your functions to solve a problem. You're not adding anything extra. It'll be ugly, it'll be bad code, but it would work.

00:19:00
Today I learned brute force is my default. It should be your default. You should always brute force your solutions first, and then as you have time, come up with the optimal solution, right? We brute force first, and then come up with the optimal solution. So you are going to look at the problem, and by the time you are done your prep, you will know how to solve it with the methods or by brute forcing it. That will be most of the problems that you encounter. The last step is having detailed knowledge on data structures and algorithms that help you come up with a more optimal solution than the brute force solution that you just came up with. But here's the thing that will work like 85% of the time. Remember you're gonna get got but you're gonna get yours more than you get got you got to keep Marshawn Lynch in our brains, right?

00:20:00
You spent 15 minutes on prep You spent the next 25 minutes 20 minutes. Let's say 20 minutes solving the problem with methods or Solving the problem just by brute forcing it nested for loops ugly code, right bad code But it solves the problem So you're 15 on prep, 20 on actually solving it. You got five to 10 minutes left. Hey, we got it working. I know this is not an optimal solution. We have about 10 minutes left. And unfortunately I do have a hard stop at 45 minutes. I do have another interview I have to get to. I would love to talk about how I might attempt this optimal solution. But if we don't have enough time, that's okay. What I can do is I can just follow up after this interview with the optimal solution. So I know we got something working. I feel like I can do it slightly better.

00:21:00
Do you agree? Okay, what I'll do is I will follow up after this interview with the optimal solution and I'll take a little bit more time to get it all the way across the line. As long as you're not interviewing at Fang, there's a good chance that that might work. Does it work all the time? No, but there's a good chance that it'll work. The best offer I ever got, the best offer I've ever had anywhere to work or learn, sorry, to work was an interview where I brute forced it. I did not come up with the optimal solution. I went into the parking lot. I pulled out my laptop. I Googled it. I figured out the optimal solution. I sent them an email saying, here's how I would do it optimally.

00:22:00
Best offer I've ever received in my life. All right. Now, the interesting thing about folks, So Lee and I do want to go to Fang. I do want to go to these super top tier tier companies. Here's the beautiful thing. I've literally gone to Google. I've met with the person in charge of interviewing like at Google Boston's campus. I met the people that like on the committee to decide whether or not you get hired directly from them. They gave my students a learning plan and they said directly in there, here's how I want your interviews to go. I want you to prep. I want you to brute force it, and then we expect our engineers from the brute force to get to a more optimal solution. So even if you want to do these super high echelon companies you still have to do the same freaking process. You just need a little bit more data structures and algorithms on top, right?

00:23:00
So it's still the same process depending on how far you want to go. But for most of us, we can get away with the methods. We can get away with the brute force and then. We're going to see both of those tonight and then on Thursday we're going to add data structures and algorithm so we can also do things optimally going to give you the full the full range here. But tonight we're going to start off with methods. So I'm going to go ahead and open up a replica. The most important thing I can tell you about going into a technical interview. is to have your environment already set up, right? If you know you're going into a technical interview, please, for the love of all that is holy, have your environment sent up. I don't wanna see you fumbling with VS code or opening some windows or trying to get stuff going.

00:24:00
I want you to be able to sit down and start coding right away. It's just something small that shows the interviewer that you're ready, that you're prepared. So I use Repl.it for anytime I'm allowed to use my own editor or I'm allowed to like type my own code somewhere. I just use Repl.it. It's really easy to have either like templates already set up, to have node environments already set up, to have JavaScript already set up. And it's just easy to have it up and running. I don't have to worry about like having windows where it runs or anything like that. So I use Repl.it if I can use my own environment. And then a lot of companies will give you their own, like they'll be giving you like a coder pad or something like that. Anything that you're used to using will work inside of Repl.it as well. But if you already have, right, if you already have some other system that just works well for you, and your VS code is already suited out, you're a Vimasaurus, it doesn't

00:25:00
matter. It's just whatever, you know, you're going to use, become really good at it, have it already set up and use it for whenever you are practicing. Right? So I use Repl.it for interviews. That means all my code wars, all my leak code, everything is done inside of this Repl.it. So whenever you're doing your coding challenges going forward, you're going to use the same thing to make sure that you're doing it well. So, I am now going to pretend that I am going through a technical coding challenge, right? I am going to pretend that someone is interviewing me, and for every single coding challenge going forward, you need to do the same thing. Get yourself a duck, get yourself a bob, whoever you're going to talk to throughout your entire interview

00:26:00
you need to have someone it could be your your Gatorade bottle I don't care but when you're practicing your technical interviews right when you're practicing your technical interviews you should always always imagine yourself in the interview talking to an actual interviewer no more just quiet typing to yourself. You want to be verbalizing everything that you are doing. What you are going to notice is the entire time that I am doing this coding challenge, I will not stop talking. your technical challenges are testing two things. Can you code? And do I want to work with you for the next two years? The communication and

00:27:00
collaboration is key. So Bob, my interviewer has just given me a problem and their problem is Leon, I would like for you to create a function for me that takes in a word and the function should tell us whether or not that word is a palindrome. Thank you, Bob. I appreciate the question. Just to make sure I heard it correctly. And do you mind if I take a few notes as we go through the process? No, go ahead and take some notes. Wonderful, thank you. So, what I heard you just say is that you want me to go ahead and create a function and that function should take in a word and that word should be taken in and we should say whether or not, whether or not that that word is a palindrome. Cool. What I will do now is not freak out. I've

00:28:00
done this palindrome question a bazillion times. It's been on Code Wars, it's been on LeetCode. When you do HuntTober, we're gonna do it together too. So when you see this and you say, Oh my gosh, I know how to solve it. We don't, we don't do the bugging out and like, Oh, like no, no, like fist pumping. The very first question would be say, great. Thank you so much for the question. Now, just to make sure a palindrome, and I'm just going to clarify with you here. A palindrome is a word that is spelled the same forwards and backwards. Correct. and Bob will go yes a palindrome is the word that is spelled the same forwards and backwards wonderful thank you so much always clarify even if you think you know what they are talking about right clarify because they might be talking nonsense so now we're on the same page we both

00:29:00
know what a palindrome is. We both know that we're going to create a function that is taking in a word and we're going to say whether or not it's a palindrome. Great. The next step is I'm going to start walking through my prep. And where a lot of folks make a mistake is they do this. I see this all the time, please don't type out prep. Let this be the internal system that you're using that makes you look like a bad-ass, but you don't need to let them know that you're like using a system, right? So I even see people do it, they'll like type the P and the type, no, no, no, no. We're just gonna say, all right. So I would love just to ask you a series of questions just to make sure I understand the problem. Is that okay, Bob? Yes. Now notice what I'm doing here. I am asking a lot of questions to Bob and I am getting

00:30:00
them talking immediately and one of the oldest sales tricks in the book is to get your person saying yes as early and as often as possible. So I am I'm giving questions that I know Bob is going to say yes to. All right, Bob, just to confirm, a palindrome is a word that is the same forwards and backwards, is that correct? Yes, wonderful. I'm gonna ask a series of questions just to make sure I understand the problem. We are taking in a word. So this is gonna be my parameters. Parameters are the things that are coming into the problem. All right, Bob, so I know I'm gonna be taking in a word. Now, for this word, there is a few things I want to clarify. Will a word always be passed in? Like will I always have, will it be a string? And will it always be a string? Yes, I can always assume that I will be getting a string passed

00:31:00
in, great. Will this string ever be empty? No, so no empty strings, okay. So no empty strings, beautiful. Wonderful. Will this string ever have any special characters, like a period, a bang, or anything in it that would be not just a normal, like a normal string or like a normal word, sorry. Wonderful, all right. So I know that there'll be no special characters. I was gonna say no bang. And another thing here, will there ever be numbers mixed in with this word? No numbers. Cool, no nums. So it seems pretty straightforward. It'll be a string, it won't ever be an empty string, there'll be no special characters, there'll be no numbers, no funny business, right? No funny business, no extra things that would make the string not a word, okay? Nothing that would make the string, no funny business. And the last thing that I wanna just clarify

00:32:00
here is, will this word be case sensitive? Will there ever be capital letters? Will there be ever anything that I have to keep in mind about this word? Okay. No, no, no funny business. And I spelled it funny. There you go. No funny business. And I don't have to worry about capitalization. Thank you. So no caps. And I guess when I think, will there ever be, will the string ever be multiple words or will always be a singular word? It would always be one word. All right, so one word. Great, so I feel pretty comfortable knowing that this function will be taking in a word. It'll be a string. It will not ever be empty. It won't have any special characters. It won't have any nums. Really no funny business about this string at all. There's no capital letters I have to worry about. So I won't ever have anything coming in that has a capital letter.

00:33:00
And it will only ever be one word, No spaces or anything funny like that. Is there anything I'm missing, Bob, about this word or this string that might cause me some headache down the line? No. All right, great. So now I have a good idea of the word that is coming in. What I'm returning to you, I just want to clarify what's, what I'm bringing back to you. You said that you want me to say whether or not it is a palindrome. So a couple points of clarifications here. Will this word, when you say it's a palindrome, do you want me to literally say palindrome or not a palindrome? Would you like it to be like a Boolean, like true or false? Would you like it to be something unique? Okay, just a Boolean true or false. So I'm gonna return to you a Boolean of true or false. So we're just gonna say true or false, wonderful. So

00:34:00
I don't need to do anything else other than from this function, just say true or false, and you want me to return that. Wonderful. Great. So I am taking in a word that's a string, empty, no funny business, no capitalizations, one singular word. I'm returning true or false. Do you mind if I give you some examples just to make sure we're on the same page? Yes? All right, thank you, Bob. So I'm going to write out some examples here and we're just going to make sure that we both are at the same agreement as to what this palindrome checker would do. So I'm going to say something like the word race car. That would return true, right? Race car is spelled the same forwards and backwards. That would be true. Does that work? Great. I'm going to do another string here. Let's go ahead and do Bob, like your name. And we'll go ahead and know that that returns true.

00:35:00
And then let's do one that would be false. So we can do like, I don't know, let's, I'm hungry right now, so I'll say tacos. Right, so tacos would be false. Beautiful. All right, do we agree that race car would be true, bar would be true, and tacos would be false? Is there any, is there any example that you're thinking of of that might trip me up with the current understanding I have of the problem. No, this seems straightforward. All right. So what I wanna do very briefly before we get into solving the problem is I actually wanna turn these into some test cases for the running of the problem. So I'm gonna go ahead and just create my function real quick and we're just gonna call this is palindrome because we just know it's gonna check to see if it's a palindrome. I know that I'm passing a word into this palindrome which will be the string that we talked about, but what I actually want to do is I want to call this isPalindrome, and I

00:36:00
want to pass in everything that we just clarified above in our examples. So I'm going to pass in race car, and I would expect that this would return true. And so I'm going to copy this real quick. I'm going to pass in our other two things that we agreed on, which was Bob, which would be true and tacos, which you know, would be false. And what I'm actually going to wind up doing is just console logging these. So I'm going to go ahead and create my, my REPL here and, um, see if a REPL is not, let me do it all at the same time. So I'm just going to do console dot log, and I'm going to wrap each of these in a console log, just so that I can see the, the result over here in the console. So each of these will be console logged. And the cool thing inside this console log, I'm going to actually put the result as well. So I'm going to do a comma here and we'll just say true, which

00:37:00
I know is a string here. I just want to be able to, when I run it, I want to be able to see like true, true in the console, false, false, just so I know that I got the right answer and that my code is actually working. So if this was to work, what would wind up happening is I would call my, I would call my function is palindrome, and I would pass in race car, and I would expect this function to return true. So this is working in my console. I should see true, true, true, true, and false, false. And then I would know everything is working. If all these cases worked, would you agree that I have solved the challenge that you've given me today? Yes, okay. So if these work, you would agree that I have solved, right, I will have solved the challenge. Now, let's take a pause here for a second. Why am I doing this?

00:38:00
Why am I building out these like test cases underneath my head? People keep using the word stalling. I am not stalling. This is part of the process. I am showing this engineer that I can think through a complicated problem. So many folks think that this is bad. Like I guess I get where it comes from, but folks think that I'm like trying to trick the interviewer. interviewers love this shit because I am thinking through the problem I am engaging with them nothing sucks more than on your fifth interview of the day having an interviewer that goes like this the five and do the two

00:39:00
and then I think I did the one and I think this might I don't know if it carries over and then I do the oh. Yep, and then I did that. Oh, okay, so maybe I'll get lunch tomorrow. And then like three hours later, they come back and they're like, I think I solved it. And you're like, no, you're not even close. Like this is, this is, this is not even, I didn't say, I didn't say Fibonacci, I said palindrome. You built the Fibonacci sequence, not a palindrome, right? Like I can't tell you, like when you're an interviewer, You're not doing one interview a day, you're often doing like five a day and they suck because it's just, it's just, it's just draining. But if you have someone that's like actually keeping you engaged, that's actually asking you questions that makes it so that you're not actually falling asleep, that you might actually get the chance to like them. You might actually get a chance to, to, to laugh, to share something, to, to, to, to like bring them into that process,

00:40:00
right? If you're just the way I just like wham right into it like no question like it It just it it's just not good Like you're not building that connection with the person and that person's gonna zone out. It's their fifth interview of the day They don't want to be there anyway, right? And so they want to see that you can think critically that you're engaging them. You're smiling. You're laughing with them You're asking them questions, right? You're making it worth their time and then last but not least. These are your receipts. I Can't tell you how many times a student has come to me and said Leon I solved the problem and then magically the problem changed like they decided to add some nonsense on at the end they decided to Tack on this extra bit that they didn't say was part of the problem. So I am very clearly saying hey if this works we're good, right? Like this is the solution,

00:41:00
right? Like we've got it, we've slam dunked, we've won. And so in 30 minutes, when they try to switch it up, you go, whoa, whoa, Bob, hold on now. We agreed 30 minutes ago that if these worked, we were good, right? So these are your receipts. you're getting that agreement, right? And you're, you're getting that buy-in to like the thing that you're trying to do is the correct thing, right? Is the correct thing. And if they try to add stuff, well now at least you have something to say about it, right? It's common that sometimes interviewers will try and do something more complex. We'll talk about that when we hit it. So the last thing here is we've done our parameters, right? We've clarified what's coming in. We've clarified our returns, the R in our prep. We know we're getting a Boolean, not some string or something coming out. We've walked through some examples.

00:42:00
We've walked through our test cases that are made from our examples. The last thing to do is our pseudocode. We're gonna talk high level about what we're about to do before we start coding. We wanna make sure that the thing we're about the code is correct. The pseudocode is the high level, plain language instructions. You're going to follow, right? Follow to solve this problem. But before we do that, we're going to take a break. I were at the top of the hour. I don't want these weird ads to run. Uh, so we'll, we'll run our ads, uh, during our break. When we come back, we'll look at our pseudocode. We'll finish this up and we'll talk about from the perspective of the interviewer, what just happened. But what I hope you're taking away from right now is that this is a conversation I'm having with Bob I'm trying to explain my thought process I'm showing how I'm thinking through everything and What this is enabling me to do is to build that rapport

00:43:00
of my interviewer It's giving me time to think about how I might actually solve this problem. I just took 15 minutes and I haven't actually solved the problem yet, but I could have been thinking about it the whole time Cool. Let's take our break. Come on back, come on back. All right, so we spent some time building this out. So far, we've walked through our prep. Our parameters coming in was the word. We clarified everything about that word. We know it's a string and all of these things we clarified about the string. We know what we're returning, which is a Boolean of true or false. We know that we have some examples that we work through. We built out our test cases for those examples. And now it's all left to do is to actually code this out. Now, the whole time we've been doing this, I have been talking to Bob, right? I have been talking to Bob. Every single question, every single time thing I do, I keep asking Bob. Bob has been saying, yes, yes, giving me feedback,

00:44:00
talking to me this whole time. The reason why I do this is we talked about the building the rapport, but there is another reason why I'm doing this. I am priming Bob to answer my questions. Let's think about that for a second. Bob has been straight up answering every question I've given them for the past 15 minutes. So when I get stuck and I ask a question, there is a non zero chance that they will just answer it for me. I can't tell you how powerful that is, right? Doesn't work all the time, but if they've been answering your questions this whole time, you've built up kind of like a collaborative process here, because most interviewers wanna see you win. Most interviewers wanna see you win. And

00:45:00
they want to help you because it means less work for them to do on the job, right? They want to help you, but they can't help you if they've been silent the whole time, because it just won't be natural for them to help you. But if they've been nonstop talking to you, answering your questions, and you finally throw out the ask because you're stuck, they're just going to keep, they don't know that, they're just going to answer it, right? And so this is also a bit of priming to get the help that you need. Now, most companies, like a lot of companies tell their interviewers to give hints. Literally the person in charge of interviewing at Google that I was in the room with talking about this said, we give, we tell our interviews to give a hint, right? At least for that campus to give a hint. So if somebody gets to the problem, they've brute forced it and they're kind of stuck, at least on the optimal solution, they're literally told to give them a hint. And a lot of interviewers, if you've built up the rapport, you've gotten them talking, you ask for

00:46:00
a hint, they'll give it to you. Or if you get stuck, they'll just straight up tell you how to get unstuck. Cool. So we've walked through our parameters, our returns, our examples, the P-R-E of prep. The last is the pseudocode. And so the beautiful chance of the pseudocode is to, is to, is to kind of say high level what you wanted to do. So you've taken like 10, 15 minutes to kind of get to this point. Hopefully by now I have been using some of that time to think about what you want to do. And so I would take this time to kind of confirm with Bob what's going to happen. So Bob, I know I'm going to take in a word and what I want to do is I want to reverse that word. So I know I'm going to take in a word and I'm going to reverse the word. Now I know in JavaScript that I can kind of easily reverse that word using a series of methods. and those methods I believe are split, reverse, and join.

00:47:00
I think for a first pass, reversing the word with split, reverse, join would be a good first pass. What do you think? Bob will say, yeah, that sounds good. So I'm gonna say split, reverse, join. Great. So the next thing I'm gonna do is once I've split, reverse, joined, I'm going to compare the reversed word to the original word, and if they are the same, then I can return true. If they are not the same, I can return false. So what I'm going to do is I'm going to take in that word, I'm going to reverse it, and then I'm going to compare the reversed word to the original word. Does that sound like a good plan of attack for this function? They're going to say, yeah, right. So like even, even this part of the process

00:48:00
where it should be me, right, it should be me kind of coming up totally with the solution by myself is I'm still asking Bob, what do you think about this approach? Is there anything that you're noticing that I'm not noticing about this approach that might cause me some headache? No, this seems like a good first pass. It seems like this will work, right? Like, you're literally asking your interviewer, are you seeing something that I'm not seeing? You could have even said, you know what, Bob, I know that it's split reverse. I always forget the last one here. Do you remember what that one is? Like, that would be a fair question, right? If you have been getting Bob to say yes over and over and over again, and you say split reverse, sometimes they can't even help themselves. Sometimes they'll be like, join. I'm like, thank you, Bob. All right, and you just keep moving. Cool. Should we at least, should we go for least amount of code of a readability? I'm gonna get to that, Dev. Give me a minute to get to that. I'm gonna get to that. It's a really important question. All right. So I know I'm gonna take in that word. So I'm gonna say let reverse

00:49:00
word equal, and I'm gonna do the word, and then I'm gonna split it. And this is where my studying of methods comes in. I'm gonna reverse it. and I'm gonna join it, right? And what that should do, because if you've done the methods work, split reverse join is in there. If you've done your code words, you've done this palindrome before, split reverse join, they should all be in your Anki decks, right? And this problem should definitely be in your Anki deck. So I am reversing the word by splitting it into an array, reverse is an array method, so I'm reversing that. and I'm going to join it back together into a string. I would say this out loud to Bob. All right, but I'm going to reverse the word. The way I'm going to reverse the word is, I know that the parameter word is holding my word. I'm going to split it, split turns it into an array. I'm going to reverse it, reverse is the array, reverse is specifically an array method. So I

00:50:00
have to split it because there's no native reverse method for a string. And then I'm going to join it to get my string back. I need it back as a string so that I can compare two strings together and so down here we're going to do a conditional and I'm going to say if word equals reverse word then I know that that is a palindrome right if the if the word reversed is the same as the original word then that word is a palindrome and I can return true and if it doesn't equal the same word reversed, right? Right? If it doesn't equal the same word reversed, I can go ahead and do it with an else and I can return false. Now, the way that you see this here, Bob,

00:51:00
is there anything that you see that I'm missing or things that you think I should do a slightly different? And Bob literally won't be able to help themselves I'll be like Leon you're missing the D. Ah, thank you. I appreciate that. Thanks for helping me out there Let me throw in the D here reversed word. Thank you so much. I Appreciate that. Thank you, Bob You really uh, give me a solid with that one great. So now we have reversed our word And we have a conditional to see whether or not it is equal. So we'll return true or return false. And let's go ahead and just run this real quick, Bob, and see if it works. And we can see our test cases all became true. True was true, true was true, and false was false. So our code work, our test cases passed. Is there anything here that you're seeing that does not lead to what you were expecting to see in terms of me

00:52:00
solving the problem? Let's leave the code quality off the table for a second. But in terms of what you want it to have accomplished, like determining whether or not a word was a palindrome, does this live up to your expectations? Yeah, well, thank you, Bob. Now, I do have a few questions about this solution. At your company, do you as a team value kind of like commented code? Is that something that you feel like is left up to how you label your variables. Would you leave these comments in? Would you use these types of variable names? Is there anything here that I did that might not be the same at your company? Okay, so you would get rid of the comments because the variable names are descriptive enough. Wonderful. And then do you value kind of the readability that you see here, or would a shorter number of lines of code be useful here?

00:53:00
Okay, so a shorter lines of code would be useful here. So maybe I can get rid of the conditional, right? Maybe I can get rid of the conditional here. And with the conditional, I can just return like word equals reversed word, right? So now we still get the readability of seeing that we reversed the word. we can see that we've done the comparison. We know that this will return true or false, right? But I do like the readability of this. Do you use like ES6? Like would you turn this into like an arrow function at your company? Oh, you do like to use arrow functions. So I actually think I could do this as an arrow function as well. So what I'm going to do is I'm going to

00:54:00
just make a simple arrow function here. I'm going to comment this out. And I'm just going to do const is palindrome. And I'm going to set it equal to our arrow function. We know we're passing in words, so I'll say word. And I'm just going to say, does word equal word.split. Reverse and join. Cool. So now, let's go get myself a little bit more room over here. We've used this lovely arrow syntax. It's all on one line. Maybe we lost a little bit of readability, but I feel that if your company is definitely one that uses kind of these arrow functions, this could be a good fit. Is there anything here that I'm not doing that you would do on the job? Is there anything here that you see that I should add or change? No, this looks

00:55:00
great, wonderful. Thank you, Bob. I really appreciate you taking the time to ask me this question, to work through it with me. Thank you for spotting the typo with the reverse D and for giving me some insight about how you would actually code this on the job. I think this type of coding style and collaboration is something that I really value on the job, and I think it could be a good fit for me. You You Boom. That's how we do folks, that's how we do. All right, so there's a

00:56:00
lot here, right? There's a lot here. We did a lot in this time together, right? And we've made a friend, which is the goal of these interviews, right? The whole time I did not stop talking. Every time I had a chance to ask Bob a question I did, I brought them in, I thanked them for their time. And at the end, even though when I had solved it, I knew how to make it a little bit cleaner, a little bit better. And so I began to question about how they would do things on the job, right? What does it look like, like how you write your code? What I am trying to do at the very end is to get Bob envisioning me working on their team Writing code that they would write so that Bob can see that. Oh, we have a good fit Leon's already writing the code. There'll be a good fit for this team,

00:57:00
right? Like that's the That's the goal See okay. Thank you for the raid. Let's go Thank you for bringing the crew along. Hope you're doing well. Saw that you were at TwitchCon. Hope your travels went well. Hope you had some fun. Welcome Raiders. We just finished up doing a technical interview question together. We talked through our secret method of prep, parameters, returns, examples, pseudocode, talking through how we can make it through these technical interviews. Technical interviews are really testing two things. is not only can you code, but do I wanna work with you for the next two years? And we're kind of wrapping up with some questions here about how we solve this first problem. TwitchCon was a blast. Hey, I love to hear it. That's awesome. Cool. All right, while we're here, questions about this first challenge.

00:58:00
Why don't we use two lowercase? Well, we actually clarified in our parameters that casing wouldn't be a problem. So maybe it would have been even super specific and said like, it'll all be lowercase, right? So that's something that you can in your parameter stage clear up. But if you did not clear that up, then you would definitely need to use that, leave that in your code. Oh, what level code wars would this be? This is like an eight, maybe a light seven. Yeah. Can you get the checklist we can practice with that is more than just prep? What do you mean, Blars?

00:59:00
Prep is the, for coding challenges, prep is the checklist. Would using code snippets be bad in an interview if you have them in your environment? Oh, that's something you wanna talk to your interviewer about. Remember how we said we shouldn't go into these interviews like an accident. We should know what we're getting into before we show up for the interview. One of the questions I might ask the recruiter or the hiring manager, whoever I'm talking to before the interview would be like, Hey, what's good during the interview? Can I use Google? Can I use resources like the MDN? Is it okay to have documentation up? Is it okay to use code snippets that I have already in my environment? You can ask all of those things before you get into the interview, and then you can even confirm those things with your interviewer too. Hey, I talked to Bob beforehand. He said these things were cool. I just wanna make sure that We're on the same page before we start the interview that these things are still good in your eyes as well

01:00:00
What level challenges common interviews well, like I said Well, I like I said Daddy Yankee built a button with HTML and CSS, no coding challenge. Sean, no technical assessment. There's like 30 more of these, at least on our celebrations channel, where there was no coding challenge because they did all the other stuff that we talked about. Right? They did all the other stuff that we talked about. Right? Then a good portion of interviews, if you do prep well enough, you can make it through with your prep and the methods that you have

01:01:00
really, really well prepared. But every company is different. That's why we do our research and we know what we're getting into before we show up in that interview. You should never show up to an interview having no idea what's about to happen. You've done you've already messed up You should know you should be needling. You should be trying to figure out you should be using glass So you should be using blind you should be using GitHub to figure out what the interview is gonna look like you should be talking to the recruiter You should be talking to people on the team. You should be talking to hiring managers You should be talking to the person that gave you the referral. You should have an Overwhelming amount of information about what you're about to walk into so that you know what to be prepared for So, a large portion of your interviews won't have a technical challenge. If you've done everything else to pass the sniff test, you have an amazing $100 project, you have a portfolio of work that has real clients, that has real engineering experience

01:02:00
on it. A lot of times you can get into these with just strictly behavioral. Don't believe me? Go to Celebrations channel, see 30 other plus people that have done it. Then a strong portion of your interviews, if you do prep well, and you realize it's about communication, it's about collaboration, it's about not just strictly whether or not you can code or not. You can get away with your methods, right? You're doing the 10 minutes of prep, 20 minutes to solve the problem, hard cut off at the 45 minutes because you have another interview to get to. You can always go ahead and send them more optimal solution following up, right? And then there's gonna be a strong number of interviews where you're going to brute force your way through a problem and that's enough, right? We're using just the big four variables, functions, conditionals, loops. If you use the method we just talked about, 15 minutes for prep, 20, 25 minutes for trying to solve it, brute force saying, Hey, I know we have a hard stop at 45 minutes. I knew I can get a more optimal solution. Do you mind if I follow up with it? It'll

01:03:00
work. Does it work every time? Absolutely not. Are you going to get got? Yes. You're going to get yours more than you get got. Uh, I guess, I mean, just a list of good questions to be asking throughout. Um, yeah, that's what this class was for. Uh, so I think a really good thing to do would be to run this VOD back. Right. To run this VOD back. Right. Um, to, to run this VOD back. and listen to the questions that I'm asking and then try to mimic those questions. Even if you just like heard me say, like even if you just like paused it and then said back what I just said, right? That would be good practice to get into like, all right, how did Leon clarify the parameters? Hey Wolf, thank you, I appreciate that,

01:04:00
right? How did Leon clarify the parameters? All right. Leon said, will it ever be empty? That's a good thing to keep it back in my mind. It will be empty. Will it have special characters? Will there be numbers? Will it be a singular word? Will capitalization make sense? Right? And then repeat that, right? Get used to that. Add that to your prep. The reason why you all agreed to use prep, the reason why you all agreed to use prep For the rest of your life is because the more you do it The better you get at doing it, right the every code where you do going forward every every Leak code you do going forward you're doing this prep and you're talking out loud You're talking to your duck the entire time. It is no longer enough, right? It's no longer enough to just be one of these people Oh, okay, that's two some problem. I know there's a hash map somewhere. I don't know how to do a hash

01:05:00
map. How do I do a hash map again? No, the communication and the collaboration is just important and nobody's good at it out the gate. I've hundreds of students, hundreds of students that I've helped with this stuff. I've never seen somebody be good at this out the gate, ever. ever. It's weird. We spent, we spent how many months, right? How many months talking to ourselves, not talking to ourselves, just coding, right? Thinking through everything internally. Now you got to start verbalizing all the things that you're thinking. Right. And so you practice every day with the prep, you practice the things that we just did. And then remember 60 network applications. So the first 10 that you do, they're going

01:06:00
to be bad, but what you're going to test out. It's like, all right, did I, like, I lost the interviewer at this point. I, I, I, you know what? I got two in my head with the pseudocode. I stopped asking questions and I could see that they, they tuned out next time. I won't do that next time. I'll verbalize all my pseudocode so that I know. I keep them on the hook, right? You take those first few interviews, those first few interviews are gold. You should be giddy to bomb an interview. You should be the happiest person in the world to go into that interview and just absolutely bomb because you're going to learn so much. You're going to take that to your next one. Will they ever tell us to stop talking? Uh, no, because you're not just talking. You're communicating with them. Like, don't be the person that just like, blah, blah, blah, blah, blah, blah, blah. But like, like you just got like your headphones on. You're just like jamming out. You're just like,

01:07:00
that's not what I was doing the whole time. The whole time I was asking Bob questions, very important difference. I wasn't just talking every single thing. I was clarifying with Bob. I was talking to Bob. I was getting Bob to say yes. I was engaging Bob in the questions. It wasn't just me talking like at them. I was literally, and don't, and so this is a, this is a very common problem. Glad you brought this up. A common problem is I've seen this happen quite a few of my students. Cause they're so used to doing it with an inanimate object. They'll go, all right. So this, um, this array will just be numbers, right? Great numbers only. Like they don't, they don't wait for the interviewer to say yes, only numbers. They kind of just like already filled it in their head that it will only be numbers in the array So just be mindful of that as well. That does that is that does become slightly of a problem. So What we will be doing Through a couple nights together is

01:08:00
practicing our technical interviews together Right, so the first time you're doing technical interviews shouldn't be in a real interview. It should be doing it with us as a community together first. So we'll have a mock behavioral night and we're going to have a mock technical night as well so that you can get practice working through these questions. We're going to do it kind of like speed, speed interviewing style where you're just going to get paired up randomly. One person practices, you give feedback, then it switches, the other person practices, you give them feedback. And so we're gonna do at least a night of behavioral and a night of technical. So the first time you're doing it, it's not just you. Community taught, exactly. All right. Now,

01:09:00
the last thing I wanted to do is I wanted to do one more problem. We got like 25 minutes left. I'm gonna do one more problem just so we can see a point about brute forcing a problem. And then we'll stop there. On Thursday, we're gonna show, we're gonna start our data structures and algorithms knowledge so that we can take our brute force solutions and make them more optimal. And we're gonna talk about like what optimal means. Like, how can we make our, like, what is, why is it our code good? And how can we make it better in terms of space and time complexity? If you don't know what data structures algorithms are, that's okay. We're gonna do that on Thursday. We're gonna use big O notation. All these big words that we're gonna treat as disrespect until we get into class, we'll be there. Also, you'll notice for homework, is there was a raw JavaScript course

01:10:00
that it was an introduction to algorithms by Scotch IO. And it was my favorite course for my students to get a taste of data structures and algorithms that was simple, it was approachable, and then they got bought out and it disappeared. But it's still in the way back machine. So your homework is to start going through that tutorial, but it's a little weird because we're using the Wayback Machine to get through it. So the link is in Discord. Your homework is to start doing that. I recommend that you'd start the homework. If you have the privilege of the time to start between now and Thursday, I definitely want you to do it. And then if you don't have that approach of time, you're gonna finish it up over the weekend. But a lot of the core info that we'll cover on Thursday comes from that course because it's just so good. So we'll start there, just I want to keep that in mind for homework. All right, brute force. Eventually, to

01:11:00
reach a certain echelon of interviewing, you have to move away from Code Wars. It's not that the Code Wars problems are not good problems to continue your interviewing prep, it's just that they're phrased differently. And so, my advice to you is once you are comfortable with seven queues and you can take swings at six queues, it's probably time to leave Code Wars and make it over to LeetCode, okay? You don't have to pay for LeetCode, it's completely free, just like Code Wars. Whereas if you do pay, like you can get like certain like frequency lists and stuff like that for specific companies. But my advice for folks is the reason why I want you to switch to leak code is because a lot of companies, right? A lot of companies mimic their

01:12:00
questions just straight off of leak code. And yeah, there are others. There's code forces. There's Project Euler. There's like all these other places that you can go to that have these but as someone So for my students, I typically ask them to give me a Report like we used to take for resilient coders after each interview. You told us like what you experienced in that interview and Across hundreds of interviews you would be surprised The number of companies that are going to leak code searching for high-frequency problems and yoinking the high-frequency easy problems and asking them during the interview. It was mind-blowing. The first month we asked for this feedback and I got a taste for what the questions were being asked, a shocking and alarming amount of companies are taking high

01:13:00
-frequency problems off of leak code and literally asking those problems with slight variations, sometimes with little changes, little tweaks here or there. So that's why I asked my students to eventually make their way over to LeetCode. I really do believe that if you've done everything we talked about tonight, and you've studied your methods, they're committed to memory, you know what they are, and you talk about your code, and you go through the prep process that we do tonight, You could get a job with just that knowledge. To open more doors, right? To open more doors, we also start the LeetCode S style problems, and we sprinkle in some data structures and algorithms as well. You do not need this to get a job. In hundreds of students that have never had a LeetCode S problem, be the deciding factors to whether or not they got a job, right?

01:14:00
And so this is just opening that last door that will give us more opportunity and it's something that we'll be practicing throughout Huntober, is like getting good at these types of questions. What makes LeetCode hard at first is that the way they phrase questions is a little more computer sciency than maybe Code Wars would be. And so it takes a little while to get used to that style of question. It gets used to, it takes a while to get used to talking about it in that way. So that's why we make the transition. Cool. This is a very common problem. I'm even seeing some people in chat say that they asked this problem at their company. This is a two sum problem. Two sum, when you go to leak code, you can sort by like high frequency. This is like the most common question. So many companies ask this. Now, so many companies ask this, but let's get into the board

01:15:00
real quick. This is opening a door. Do you need this? No. This is opening a door that opens up more interview possibilities for you. But if you know your methods cold, you know your prep cold, you could still get a job. I've shown you people that had less than that and still got jobs. That's enough for a strong portion of the interviews you'll go into. If you use the methods we talked about tonight, but this last piece, this leak code data structures algorithm is the last piece to open up more opportunity for you so that more interviews go your way. Cool. All righty, this is something that we'll be practicing during Hunttober, right? And one of the things that you'll notice about this question is that this question lends itself to a brute force solution

01:16:00
pretty quickly. All right, so the question is given an array of integers, which we'll call nums, and an integer target, return the indices of the two numbers such they add up to the target. So I'm gonna go ahead and create a new replit for myself. Create. All right. Should have had this prepared. I took my own advice. All right, have a new replit. I'm gonna say, all right, Bob, thank you for the question. Just so I can hear this question again, you want me to go ahead and take in an array of integers and an integer, and then return the indices of the two numbers as they add up to a target. So I'm just gonna repeat this back to you. Do you mind if I take some notes? All right, thank you, Bob. All right, so you're gonna give me an array of nums, and you're also going to give me a target number.

01:17:00
And what you would like for me to do is to return the indices of the numbers that add up to the target. Now, that's a lot of big words. I'm gonna treat them as disrespect. And this is why we start this process of prep. It's why we start this process of having a way that we're going to approach these problems because this will happen in interviews where you're like, well, right. But we don't do that. Say, all right, Bob, thank you so much. And then you work through your prep and your prep gives you what prep

01:18:00
gives you What prep gives you 15 minutes to figure out what the fuck they're talking about. Exactly. All right, Bob. So you said we're taking an array of numbers and you're also giving me another num that you're calling the target. So I have an array of numbers and a target number. And what you want me to do is add two of the numbers in the array. So that they equal the target number, but you don't want the actual numbers. You went the indices of those numbers. So just to clarify, we'll have an array of numbers. And if you don't mind, I'm just going to go ahead and create an array of numbers here just so that this is not so kind of like theoretical. And we'll say one,

01:19:00
two, three, four, five, and you're gonna give me a target number. Let's say that target number is, let's say nine, right? So you want me to return two numbers that add up to nine, but instead of returning the numbers, you want the indices. So let's look, three and four is seven, four and five is nine. So those two numbers add up to our target of nine, but you don't want four and five, you want their indices. So if this was an array, indices is the plural of index, right? Bob, by indices you mean the plural of index, right? So in this case, you would want zero, one, two, three and four. So the actual return of this would be three and four because those are the indices.

01:20:00
Zero, one, two, three, and four. Right? So do I have a clear understanding of the problem, Bob? An array of numbers like this, a target number, and then instead you're gonna figure out which two numbers get added up to equal this target. But in the end, you don't want the actual numbers. You want the indices of those numbers. Is that correct? I have a grasp on the problem, Bob. All right, thank you. So now that I have a grasp on the problem, I wanna run through just some quick clarifying questions just to make sure I really understand everything you're asking of me. So this array of numbers that you're giving me, This array of nums, will it ever be empty? So not empty, great. Will it ever have anything that's not a

01:21:00
number? So no special characters, no booleans, nothing funny, just always numbers, right? Always numbers, so always nums, wonderful. Will the numbers always be whole numbers, right? Will there ever be like, like floated values? So always whole, okay. Will there ever be like negative and positive? Like, will there ever be like negative numbers, positive numbers? No, they'll always be positive. Great, so they'll always be positive. Great, hope you're having a positive day today, Bob. All right, so an array of numbers, the array will never be empty. It'll always be nums. They will always be whole. They will always be positive. and I guess since I know I have to add up two numbers, will the array always have at least two numbers? Yeah, always at least two. We'll say at least two.

01:22:00
We'll say, I'm just gonna say at two, just to remember, at two. And those two numbers that are in the array will always hit the target, right? There won't be a situation where the array doesn't have numbers that match the target. Cool. All right, so just to run that back, it's an array of numbers. The array will never be empty. It will always have at least two numbers. Those minimum of two numbers will always match the target. There will always be two numbers that actually match the target. It'll always be nums. They will always be whole. They will always be positive. Is there anything, Bob, that I'm missing about this array of numbers that might be odd or might cause me some headache down the line? Cool, seems like I'm on the right track. And I'm just gonna assume that the things we stipulated for the numbers in the array also go to the target as well. So

01:23:00
the target won't ever, there won't ever be like a missing target. There won't ever be any like funny business. it'll always be whole positive numbers. There's nothing funny about the target as well. Cool. All right, I think that gives me a good place to get started. You also asked that I return the indices of the numbers that match the target. So we're gonna return the indices of the nums that add up to target. Yep. And those indices, would you like them just as two numbers? Would you like them in an array? I think an array makes the most sense, correct? All right, wonderful. So I will put those numbers, Bob, into an array for you. And so those indices will be in an array. Wonderful, so we have coming in an array of numbers that we clarified, a target that we're clarifying, and coming back out to you, Bob, will be an array of numbers.

01:24:00
Do you mind if I run through some examples just to make sure that we're on the same page, Bob, that what I'm thinking is what you're thinking? Wonderful. All right, so let's go ahead and run through just a quick example. We actually already have the example up here that we walked through. Can we do one more, please? At least, please, let's do two more if you don't mind. So I'm gonna go ahead and do Five, we'll go ahead and do five. Let's do five, six, nine. And let's go ahead and pass in the target of 11. We're gonna change this to a comma, just to make it easier on myself, of 11. And so we know that five and six would be equal to 11. So we're gonna wind up returning, gonna change this to an array here, because you asked for an array to come back, Bob. You would want to see here, not five and six, which is the tricky bit about this problem, Bob.

01:25:00
You'd want to see zero and one. Is that correct, Bob? Cool. All right. Let's go ahead and do one more example here. And I was gonna pick some like random numbers. Let's do 22. Let's do seven. Let's do 100. Let's do five. And let's do a target of, I don't know, let's do, what's seven plus five? That's 12. Let's do a target of 12. Seven plus five would give us 12. So then we would have in this array, 22 would be zero, seven would be one, 100 would be two, five would be three. So we wind up with an array of one, three. Now, as I'm walking through, as I'm walking through these arrays, a couple of things are kind of starting to come to mind, Bob.

01:26:00
Does it matter the order of the numbers in the return array? Does it matter the order of the numbers in the original arrays they come in? Does that matter at all? Cool, no, the order position shouldn't matter. Okay, just something I was thinking about. All right, if you don't mind, I'm actually gonna turn these into some test cases for us. And so let's go ahead and build out a function here. And this function is going to, this function is going to take in a target and return indices. So we're gonna find indices, and I'm just gonna call it that. I think find indices is good enough for right now. We know we're gonna take in some nums, and we know we're gonna take in a target. We know those nums is an array though, so I'm just gonna call this an array and target. And I'm gonna go

01:27:00
ahead and call this a few times. So I'm gonna go ahead and run find indices, and I'm gonna pass in the stuff that we have here. So I'm just gonna yoink this, great. All right, plop that in. That'll be our first test. I'm gonna copy and paste this. And actually I'm gonna put these in a console log just to make sure our lives easier. Console.log, boom. And I'm gonna put the solution here as well so that when we run this code, we should see the output and our solution and they should match. Since these are the ones that we agreed to. I'm gonna put three and four here. I know this is a string, but it's just so that I can see it in the console on the right, Bob. All right, so we have three and four here. I'm gonna go ahead and copy this. And I'm just gonna do the other two examples that we walked through. Once again, I'm just gonna grab this array and target here. Wonderful.

01:28:00
And this value should be zero one instead of three four. And I'm gonna grab the last one, Bob, and then we'll be done with our test cases. Let's go down here, boom. This we grab this from here as well and change this up here. And then the last one is just this one in three, just to make sure that we know that we got the correct answer. All right, Bob, I think we both agreed that these solutions here, If this code runs and we wind up with matches to our test cases here, we could both agree that I solved the problem. It would meet the conditions of what you were expecting for this problem. Awesome, thank you, Bob. So what I'll do is I'm gonna work through coding this out and we know that when we run this code, if these all are the

01:29:00
same or true, then we will go ahead and assume that we solved the problem correctly. Alrighty. So the last thing I want to do here before we kind of get into the nitty gritty is I want to go ahead and solve the problem. And pretty clear to me is a brute force solution, right? Pretty clear to me is a brute force solution that while not optimal would get this working quickly. And so I'm a fan of getting a brute force solution on the board as we have time, we can optimize it. And so the brute force solution for me is I know that I have to find two numbers that match the target and So whenever I know I need to pick two numbers right off the top of my mind the brute force solution the non-optimal solution here would be to Just do two nested for loops, right though outside loop grabs the number and then the inside loop

01:30:00
checks every number against that other number. And then if those two numbers add up to the target, we found our two numbers, we can grab their indexes, and that's what we return. Is there any problem that you would foresee with that brute force solution? No, sounds like it would get to the point. All right, so let's go ahead and do that. Let's go and do a for loop. Inside this for loop, we're just gonna set up a variable, let i equal zero. We're gonna go, well, i is less than array.length, right? So that should make it so that we can go to the total length of the array. And each time we run, we're gonna make i go up by one. And what we're gonna do is we're gonna have just another loop that goes right inside this, right? So the outside loop will be responsible for grabbing one number, and then the inside loop will be in charge of comparing that number to every other one. So I'm going to say let k

01:31:00
equal zero. I'm going to do while k is less than array.length equal, and this will go up by one as well. So we'll do k plus plus. Now inside these nested four loops, all I have to do is compare the two numbers. And so for me, I know that the outside loop, I'm just gonna put some comments here. Outside loop is grabbing the original num, so we're saying grab a num. And then the inside loop will be comparing outside num to internal nums. Numbs Bob. So far, does this seem like something that would get us to the, to the, what you're thinking, like we grab a number from the outside, like we just grab one, for example, and then our inside loop would compare one to two to three to four to five, and then if it doesn't fine. Nine. Well, then

01:32:00
our outside loop would grab it and go boom, boom, boom. Something we could do like that. That sound like something that would get us close. Cool. All right. Thank you, Bob. That's what I'm going to do. I'm just gonna do a quick comparison in here. I'm just gonna say, all right, if array i plus array k equals our target, we know we grabbed those two numbers, right? I know I'm grabbing those two numbers, right? I know that I'm grabbing, I know that I'm grabbing a number from the outside loop, and then I know that I'm grabbing the numbers on the internal loop, and I was gonna add them up together to be the target. So if I ever wind up where this is true, then I found the two numbers, right? I found the two numbers that match the target, and I could just go ahead and return those two indices, actually, since I already

01:33:00
know the indice of the numbers that equal the target, I can just return I and K. But I did run into something that we didn't clarify with the parameters, Bob. Something that just came to mind as we started typing this out is will there ever be a situation, right? Will there ever be a situation where the same number equals the target, right? Like the number added to itself, will that ever equal the target, right? So I think that's the first thing I'm worried about. So can you clarify that Bob Bob? Will there ever be a situation where? The number plus itself would equal the target. No. Alright, so we can also I'm just gonna add that up here Number plus self will never equal target

01:34:00
Awesome. Thank you for clarifying that Bob. And the other thing that I'm that I'm noticing here is Will there ever be multiple solutions inside of this array? Right? Will there ever be multiple solutions? Or can I always assume that there will only be one solution where only two numbers will equal the target? Cool. All right. Thank you, Bob. So only two numbers will ever equal the target. And we know that those two nums won't be the number plus itself. Cool. So we don't have to worry about kind of clarifying anything here. If we really wanted to, just to, if we hadn't kind of asked this, we could have just done something like this, where we say like, I also doesn't equal K. Like we could have just made sure that we weren't using the same number in the array. Like if,

01:35:00
if we were both on zero and we got one, one, then this wouldn't be true. All right. So I think this should work, Bob, where we're grabbing a number on the outside. We're grabbing all the other numbers to compare it to. If the two numbers equal the target, then we go ahead and we return the indices that we've set. So let's just go ahead and run this real quick. Look at our answers here. 340113, beautiful. It looks like it worked. We said if these conditions ran, then we know that our code works. It looks like we're finding the correct numbers that add up to the target and returning just their indices, which is what you asked for. So the problem does work. Now, we did spend a little bit of time on this suboptimal solution. I know we have about 10 minutes left. The way that I would solve this, I would love to tell you how I would solve this in a more optimal way.

01:36:00
We have about 10 minutes left, and I'm sorry, unfortunately, I do have a hard stop. I do have to go to my next interview. I would definitely love to follow up by email with the optimal solution, just because we might not have enough time to do it right now. Do you mind if I have your email, Bob, just so I can send you the email of the optimal solution? Quickly, while we have some time to talk about it, I would solve this pretty easily with a hash map. And so I think if we're talking about more optimal code, I could use the hash map. And that's something I think that we could work towards to get this to be more optimal. If I took this solution that already solves the constraint and we went ahead and made it more optimal using kind of a slightly different data structure and a slightly different algorithm, maybe if we just use the hash map, Is that something you think would get you very close to the solution you had in mind? Wonderful. All right. Thank you, Bob. I really appreciate your time today I really appreciate you taking

01:37:00
the time to walk me through this question to clarify everything that we've done here together and I know that I was talking to Rachel earlier She told me I got to get my butt to the next one But I'll send you an email Bob very quickly as soon as I'm done that next interview with the optimal solution And, and, uh, yeah, I, I really appreciate your time. I'm really looking forward to, uh, hopefully joining this company. Everyone I've talked to has been amazing. And so, yeah, I appreciate your time. I hope tonight you saw the process that I use for every single interview. It really is prep. It really is about engaging with your interviewer. It's about building up that rapport, getting them saying yes. And it's something you can practice, right. It's something that you can practice. Now the end of this code, I was able to do this quite quickly. I didn't have a lot of like, I didn't have, I know we only had so much time left in class, so I went a little faster than normally would. I actually kind of skipped my pseudocode a little bit. I kind of went back and added the comments. I don't want to add the comments first

01:38:00
and then fill in the loops. And even though I know how to solve this with a hash map, I am still doing the brute force solution first, right? I'm still building up to the optimal solution. I'm still talking my inner viewer through, right? My thought process and showing them that I can solve it with even just the basics. Now, what we will be doing over the next two classes is talking about our data structures and our algorithms. So, this is not an optimal solution. Think about how this has to run. A loop inside of a loop takes a lot of time. Like for us to get to the next number, we have to run all the numbers, go to the next number, run all the numbers, go to the next and run all the numbers. That's just not efficient,

01:39:00
right? And so what we're going to do is talk about next class, how to make our solutions efficient, both in something called time and in space. And we're gonna learn all of these data structures and algorithms, what they really are at the core level, and then start putting them into practice over the next few classes. If you're doing Huntober, that's the point, is to kind of do these every single day. We start off with kind of simple method problems, then we move on to brute force solutions, and then we move on to more optimal solutions with data structures and algorithms. So that's the goal. The goal is to build up these things to get to the point where we feel comfortable no matter what door gets open to us that we can destroy our technical interviews. So I hope tonight was helpful. I hope that you got a little glimpse into what it's like to solve these technical challenges.

01:40:00
I hope you rewatch this VOD and you practice it. We've got to get serious for a minute before we get into our data structures and algorithms today. Today, we're going to have a gentle introduction to data structures and algorithms. We're going to talk about like why they're important, see the beginnings of something called Big O notation, and hopefully have some new tools that will enable us to do better during our technical interviews, to evaluate the code that we're writing with a little bit more clarity and have the, what I like to think of as really the last door you need open to get the job. Okay. Now, kind of went in a little bit this on the, uh, at the beginning, but you are ready. If you've been following along so far, you're, you're caught up with everything that's been asked of you, you submitted your

01:41:00
stuff for Huntober or you're very close. Uh, you are ready. There is nothing else extra. You need to get a job other than to go on the hunt, right? The hunt is a long grueling process. When we look at the, when we look at our trough of sorrow, that last dip is where the hunt really exists, where you've been going through this trough for a long time. You're kind of just starting to get used to being in the muck and then it just gets really bad And it gets really bad because the first few interviews typically don't go that well Sometimes you get lucky and your first interview is the one you knock out the park and that's always wonderful but by and far for most of my students their first three to four interviews are just not great and When that happens it can take a lot of air out of your sail. It can make you doubt

01:42:00
all the hard work that you put in. And so I just want to be very on the nose that the trough of sorrow that I showed you, that dip at the very end is a very, very real thing. But you are ready. You know the basics of HTML, CSS, JavaScript, object-oriented programming. You know the basics of Node. You know the basics of Express. You know the basics of MongoDB. You know how to build full stack web applications. You know how to do so many wonderful things. You've built so many projects. So many code challenges have been solved. of so many bits of information are now in your brain that other folks do not have. You know things that folks that have been running JavaScript for years don't know. You know things about the event loop. You know things about all the

01:43:00
little nitty gritty stuff. What promises really are with the async await is really underneath the hood. All these things that you spent hundreds of hours putting into your brain that has value, And it will be appreciated when you find the right fit for you. And so you are absolutely 100% ready to start the hunt and to get the job. You need nothing else. You don't need more react. You don't even need the data structures and algorithms. We're going to talk about today. You don't need to do anything else other than to commit to the process. Build out your hit list, start reaching out to folks at the companies that you're interested in, build a rapport with them, get in so you can get a coffee chat with them, get the referral, research the hell out of the companies, research the hell out of the interview process when you get the interview. Don't go into your interviews like an accident. Be ready to

01:44:00
prep your ass off to talk and engage with your interviewer. Let your skills shine. This part of the process, even with all that being said is increasingly hard because I'm not going to stop showing y'all folks that are getting jobs. So many folks have gotten jobs recently. If you go in that celebrations channel, it's just honestly ridiculous now. And even more folks that don't even post in celebration channel, like on Twitter, they post it. They send me messages privately. like it's wild in these streets right now, um, how many folks are getting jobs and I can, I understand that when you see others around you doing really well, that can even take an even bigger hit on your confidence as to whether or not you are ready. Other people's success has no bearing on your success. And so you can't compare yourself to others. You can't look around you and be like,

01:45:00
wait a minute, there are five seats ahead of me on the rollercoaster. Why are they pulling into the station earlier, nah, we're all on the same roller coaster. You're going to get there. You should see other people's wins as proof that it can work. And then it can work for you. Learn from their experience, learn from what they did well, what they didn't do well, and incorporate that into your hunt. Evan Shaw said, I was asked about big O linked list and doubly linked list in my interview. I flat out told them I didn't know still got the job a Did study all night and followed the next day with the answers to the og question. Let's go Evan we actually just answered that question today In stand up. So one of the questions somebody asked was Leon What if I prep my way through the question and I still don't know how to solve it. It's exactly what Evan just said You say, Hey, I feel like we've, we've come to a good point here where I have a really good

01:46:00
idea of the question. Uh, but at this moment, I feel like I can come up with an optimal solution. I would just need some more time. Are you okay with me following up after this interview with the optimal solution, get their email or some type of contact information. And as soon as the interview is over, immediately try and solve the problem, get the correct answer and follow up with them. Does it work every time? No, but you'll be surprised how often it does, right? I can't stress enough. You're going to get got, but you're going to get more than you get got. If you just go through the process. Can you ask your interviewer for feedback? If you didn't get the job, you can. But in my experience, a lot of companies have policies where they can't because they don't want to get sued. So if you have, if you did it right,

01:47:00
like if you just clicked apply, the answer is typically gonna be no, they're gonna be less likely to give you feedback. But if you networked your way into that opportunity and you got a referral, your connection is not with the company. Your connection is with the person that gave you the referral and you can sometimes ask them for feedback. And so you're more likely to get feedback if you do the process in the way that I asked you to do the process. Yeah. I was surprised to see the folks out there that got jobs with a take-home tech question, wait until you see the folks that got jobs with no technical questions, not even a take-home. It blows my mind. I've been doing this for 10 plus years and the folks that I've seen get jobs in the wildest of ways blows my mind. And I don't even share

01:48:00
my experience anymore. I just literally take the text of people that are telling you and put it in the slides because I just know at this point, nobody believes me. Like I just don't think people will believe me. So I stopped telling you, Hey, I've seen hundreds of people get jobs with like very minimal technical, like interviewing. And yeah. So that's why in the slides, I put the ones I think are the highlight that it's wild. Yeah. Cool. So I want us to put that out there. You are ready. You're ready to do this. you have the things that will make you attractive to employers, you gotta start. Start. This is your sign to start the process, to start the hunt, to start taking your hit list seriously, to start reaching out to people, to start getting your applications in front of individuals

01:49:00
so that you can get the job. Over the next few classes, we're gonna do the last little bits that we need to be prepared. We're going to build a hit list live. I'm going to give you lots of templates to do this successfully, but you need to get into that gear where you're ready for the hunt, where you're ready to go out weekend after weekend and catch nothing to come home hungry, only to do it again the next day. Now, the other thing too, I talked about kind of like comparing yourself to others. We're at this really weird point where everyone kind of becomes a code weenie. And so please be mindful of your inner code weenie, especially as we do HuntTober and we're doing a coding challenge together every single day, there are just gonna be people that literally can't help themselves, right? That they're like, I did it in one line, Leon, one line, right? All right,

01:50:00
so just know that at this point in program, everyone kind of becomes a little bit of a code weenie. Be mindful that you're being a code weenie. Be mindful that your experience is gonna be very different than anybody else's experience. We're all interviewing in different locations with different companies, with different experiences, with different backgrounds, with different paths. And so your experience will be nothing like anyone else's experience. Um, so many folks, when I, when I, when I try to give advice on interviewing, uh, know that, that you are going to have conflicting experiences because that's just has to happen, right? So what I try to do is I try to look at hundreds of interviews, right. Across hundreds of companies and synthesize the things that come up the most. But know that you might be an outlier and you might run into

01:51:00
some weird stuff that we haven't covered or things that are a little bit different. That's okay. Your experience might be a little bit different. But by and far, a lot of the same stuff is gonna come up over and over again. So be careful of your code weenie. When folks are asking for help, when they're doing the coding challenges, be helpful. When we're in, let's say Remo for the standup, make sure you're being helpful in those chats. Make sure you're being helpful on Discord. No one cares about your one-liner. Help somebody understand how to actually solve the problem. That's way more impactful on yourself and it's way more impactful on the community as a whole. So you're ready, be mindful of your inner Codeweenie and be mindful too of the energy that you bring to a space. right? You all have the power to to make somebody's day a little bit better because we're all interviewing now. People are going to have some really

01:52:00
bad days. You don't need to pile on them. You don't need to point out flaws. You don't just support each other, right? And so know that as we start the hunt and people start applying, it's a really rough experience for a lot of people. Be mindful of the energy that you bring. Be mindful of the emotional weight you put on others and try and lift each other up because it is just a really stressful process. The beauty of doing this with the community is that there are people to help, that there are people to uplift. Really make that your goal this next month to be a positive force on Discord, on Twitch, on Remo, because it really can make the difference in a lot of people's lives as they go through what is a very rough and difficult situation. Yeah, it's kind of really hard to carry these boats and logs by ourselves, so let's do it together. Cool.

01:53:00
Don't be this person. Don't be this person. All right, don't be this person. It's your turn to build out your hit list, but 60 companies with open roles on that hit list, start doing the real work of reaching out to folks that are at those companies, right, that are at those companies, get a referral into those companies. And if you're having some stress about how to do that, that's gonna be one of our classes next week is how to actually do this process. So if that real work of how to get a job is stressful, don't worry We're gonna have a whole class on how to do it on Thursday Looking apply should be the very very very very

01:54:00
last thing you do I've always said never click apply, but the reality is do everything the right way and then maybe like apply Who is this person and what did they do with Leon, right? The reality is that there are so many things that are going to move the needle, but you want to do all of those things first. Don't take the easy out. Don't just click apply, do everything. Do the hit list, truly reaching out and do the, the, the, the, the, the work that's going to actually move the needle to, to not have your resume just being a stack of things that never get read. And once you do everything right, you've opened all the doors. Clicking apply is probably one of those doors. I was at an online career fair yesterday and a few recruiters said just apply on our website. Yeah, that's going to be, that's going to be common from, from recruiters that are doing those like mass, like they're,

01:55:00
they're there to talk to millions of people, uh, they're not there to build a relationship with you. That's the wrong person to build a relationship with at that company. Right? Recruiters aren't always the best people to talk to. That's why if you watched our class on how to get the job, it was talk to the recruiter, talk to an engineer on the team, talk to the engineering manager, hiring manager, and talk to their mama, right? Because a lot of times the recruiters are like, they're just inundated with thousands of relationships and you won't be special to them, you know? All right, I'm going to say it one more time, the top of my chest here, prep and

01:56:00
methods and brute force is all you need. One more time, prep, methods, and brute force is all that you need to get a job. If you can prep your way through a technical interview, you're talking about the parameters, the returns, the examples, the pseudocode, you're setting up your test cases, you're building that nice communication with your interviewer, you're slipping in a few jokes as you're doing it, You're trying to have fun during an interview. Try and have fun during an interview, right? You're building that relationship with them throughout the interview. You know your methods cold, that's gonna open up so many questions. If you just know all your string methods, all your array methods, all your object methods, you know the things that can turn a tricky question into an easy dub, it's gonna be one of the biggest doors you can open. I have seen so many coding challenges that could have been solved just with a few methods if you knew what you,

01:57:00
if you had just studied them, that if you have put them into your Anki and you had studied them, that you knew them, that you had done code wars with them, you had done practice problems with them, if you had done Huntober with them and each problem that we do during Huntober should go into your Anki so that when you see it or something very close to it, you know what to do. So if you prep, you know your methods, please, please, please. If you haven't studied your methods, this is me begging you to study your methods because I see so many interviews that if they just do their methods, they would have slam dunked it. And then brute force, meaning that you're just using variables, conditionals, loops, right? And functions to solve a problem. You might have to think through it. You might have to, it's not going to be, it's not going to be pretty. It's not going to be optimal. It's not going to be the most beautiful code, but if you do prep, you get the brute force that's often enough. You can always say, Hey, we ran out of time. Let me send you the optimal solution via email right after this call.

01:58:00
I'm a flex, if you want a fang job, you better be able to solve a two leet code mediums or leet code easy and hard in 45 minutes. That's how Facebook interviews go. Yeah. We don't want to work at fang. I'm going to time me out for a little bit. There you go. Don't be a code weenie. We know this. We know this. We don't care about FANG. There are so many other companies that pay well. There are so many other companies that will give you amazing benefits. There are so many other companies that will give you a better experience as an entry level engineer, that if you focus on fang, you're missing the point. And this is the sad reality,

01:59:00
right? This is the sad reality of interviewing. This is one point in time where people take advantage of your fear. and it's really, really, really fucked up. Right? People will say, if you don't do this course, you're not going to get a job. They sell a dream of Fang so that you have to leak code your eyeballs out. Right? There is a completely different way. If you want to go to Fang, sure. That's that's that's your prerogative do it, please Go go go leak code into your eyeballs fallout. I want folks to get jobs I Rather you get paid All right, I rather you get paid

02:00:00
Continue to learn and in that year Build up the muscle to then go to Fang if that's what you want I've literally sent Two dozen people to fang over the last two years, like that were directly in my programs, have very good relationships with a lot of fang companies, right, sent an untold number of folks to fang, but I wish you wouldn't focus on it. I hope that you find a local company that pays well, That treats you well that gives you great benefits that gives you the work-life balance that you're looking for right and that just because a Youtuber told you you needed a course or this is what you should be focusing on or sold you on this dream of untold riches

02:01:00
You don't need it right now Right. You don't need it right now. That could be a goal for a year or two from now So many folks will just get caught up in this cycle of studying for something that is a long shot, right? It's the same thing as somebody saying, hey Leon, I am gonna practice baseball every day because I wanna go play for the Yankees. Great, don't let me stop you, you do you. You swing that bat every day, you catch those balls every day, I really hope you make it to the Yankees, right? And then somebody sells them a course on YouTube. Hey, use this course to learn how to throw better, to swing better, and you too can play for the Yankees. It's just a weird system to get caught up in. And so I say this as a word of caution. At this point in program, people

02:02:00
are gonna play on your fears, they're gonna play on your desires. Be careful, right? Be careful. You don't need another course. Data structures and algorithms. There are so many amazing resources that are absolutely free. Prime's course that I shared, absolutely free. Front-end mentor has another absolutely free algorithms course that I'm gonna sign as well, right? The the course I'm giving you is we're using the way back machine, but completely free All right Don't buy into these fears don't buy into these folks selling a dream Do the things that you know that you need to do to get ready for the interviews that you're about to face And if you want to get ready for Fang By all means go ahead and do it. That's not that's not my goal for y'all That's that's not what I think a lot of

02:03:00
folks should be focusing on right now So many other amazing opportunities that you could focus on that are that are that are a way easier reach And then if you want to to then continue on by all means do it And this is how many people from at amazon do we have from 100 devs now it's kind of ridiculous right it. But at this point, yeah, don't overwhelm yourself, right? Don't overwhelm yourself. Keep doing the things that you know you should be doing your bankie, your coding challenge each day, making sure you're building out your hit list. These are all things that are going to move the needle way more than Lee coating your eyeballs out.

02:04:00
It's all you need. It's legitimately all you need. Cool. And I'm gonna show these again, cause I think it's just beautiful to say. Had a coffee chat, is told they had so many applicants with empty GitHubs, no portfolio sites and no projects underneath their belt. These are the folks that are just clicking apply. If you've done this program, you have untold number of projects. You have an amazing portfolio. You have a well manicured LinkedIn. You have a great GitHub. You have all those juicy green squares. You have a coding challenge that you've literally done every single day for the past couple of months. You have a hundred hours project that's your own full stack project that you've built from beginning to end. You have real clients that you've worked with, real experience, it's on your resume, right?

02:05:00
All these things are going to help you stand out during the process because I can't tell you how many folks don't do all this stuff that help you pass the sniff test thinking thinking that if they're just really, really, really, really good at technical interviewing, that'll be enough. It won't. You'll smell like a boot camper. you won't get past the final interview. Cool. And then there are dozens of these examples in our Celebrations channel. There was no technical assessment. I just told them about the projects I had worked on and made sure I was friendly and connected with them as people. I know there are lots of people here that are better coders than me. This is absolutely possible, you can do this. Don't stop believing, stay consistent. It will happen. All

02:06:00
right. Imagine if you believed that you had to be able to do LeetCode mediums to get a job. Imagine if you waited until you were a beast at LeetCode to get a job. That to me is the saddest thing. And I see it all the time. I see so many folks that decide to just invest in doing LeetCode more and more and more because it's easy. It's easy. It feels like progress. Each day you're doing something. I'm getting better at my data structures and algorithms. It just feels like you're moving a little bit closer to the goal. When there are so many other things that we talked about, they're gonna actually get you closer to the goal. The coding challenges are one bit, but it's not the only door you need to be opening. plan out your days, make sure you're not just focusing on the coding challenges. So many folks have

02:07:00
gotten jobs and the coding, the technical interviewing was just a tiny piece, just a small bit. Be wary of what you're over focusing on and do the things that are gonna actually move the needle. Building out your hit list, reaching out to real individuals you can get an actual referral to is the primary thing that's going to move the needle for you. Everything else is extra. I have a four-week commitment in February. How should I address this with my interviewer? You don't, once you get the offer, you bring that up while you're negotiating your offer. Mm-hmm. Cool. You know what else feels like progress, but is absolutely not? Buying a course. We get that sweet, sweet, sweet dopamine hit when we buy the course that we think is gonna help us get better at interviewing, and then we don't do it.

02:08:00
So don't get got. Literally the best courses on data structures and algorithms are all free. I'm sharing them with you here and on Discord. These things are not real things that'll move the needle. All right, and if anything, you didn't hear it from me. I'm a flex. I know I was kind of messing with you. I appreciate you saying that. I agree with you. I worked on tons of startups myself because I didn't want to deal with leet code before. Most of them were project-based or language, didn't realize the demographic of the stream. Hey, no, no worries. It was I thought you were playing because of the the name I'm a flex But yeah, we we have a we have a meme here where we don't like our flexes sources or our code weenies So I appreciate you saying that thank you for being here Alright at the end of the day You don't believe me. We brought in Daddy Yankee themselves working at one of LA's hottest startups

02:09:00
They built a fucking button that was their coding challenge to build a button no JavaScript no node, no react, no coding challenge, no data structures, no algorithms, a fucking button. With that, let's take a break. When we get back, we move into data structures and algorithms that you don't need to get a job, but it's good to open all the doors possible. All right. Surge nine put put two more minutes on the timer. If you're new around these parts, we like to take a break at the top of the hour. We like to make sure that if you're able that You get up, move around, hydrate, take care of yourself. The hunt is a long, grueling process. Make sure you're taking care of yourself. I'm gonna put seven minutes on the timer. I'm gonna run the ads so new folks don't have to sit through them. And I will see you all very shortly. We're gonna get into these wonderful data structures and algorithms, a gentle introduction

02:10:00
to data structures and algorithms, and then we'll have more time to go deeper with it. Don't let me tell you what to do and not to do. I'm gonna show you how I think it's best to play the game. each and every single person has to figure out what things they're gonna use to help them in their personal hunt, what their end goals are, what their objectives are. And I hope that I can share enough that you have a rough idea how to go forward, but it's your game to be played. I'm gonna tell you how I think it should be played, but it's up to you to figure out how you wanna play it. And the last thing I really wanna say on this before we move on is that, you can't lose a job that you don't already have. Alright, so many folks go into the hunt with these anxieties and these pressures on themselves. There's nothing you can do It's gonna make you lose a job that you don't already have Alright, so get in there find what works find what doesn't work for you Don't be afraid to mess up. There will always be other interviews. There will always be other places that you can find to

02:11:00
get interviews with Take that anxiety off your shoulders as much as possible. Don't let your dreams be dreams Alright. Let's talk about some data structures and algorithms. Now, what I'm about to cover is going to make the nerds angry. It's going to have them quaking in their boots. None of this is meant to be a comprehensive data structures and algorithms course. It's meant to give you the things that you should be thinking about and some ideas that I need percolating in your brain. Your homework is the Scotch IO course, and then we will have a full other data structures and algorithms course I'm going to have you work through plus our daily stand-ups during Hunttober. So the goal today is to get a primer on the things that you should be caring about, thinking about, and then as you complete the homework over the weekend, it'll solidify a lot of those concepts. We're going to come back on Tuesday. We're going to go deeper with Big O notation, have more examples to help drive home these points, and then it's going to be something you're going to

02:12:00
start incorporating into your daily coding challenges. So everyone should be doing a coding challenge a day, whether it's Code Wars or LeetCode, whatever you're doing, you're already prepping through those questions. Now you're going to add this last layer of optimization and thinking critically about the code that you wrote and is it optimal? Cool. So we talked about data structures and algorithms. Let's just get some quick things off the table. And when I say algorithm, all I really mean is just the steps that you are taking to solve a problem. That's it. There are many ways to solve problems and algorithms just a certain number of steps that you're gonna take to solve a problem. Now, most of the time when we're talking about algorithms, like for the purpose of our coding challenges and things like that, I'm just really kind of talking about a function and that's kind of it. a function that has some steps that we're gonna follow to solve

02:13:00
a problem. And that's kind of, that's it. Now, this function or this algorithm is gonna transform some input, which I'm gonna call a data structure, into a certain output that'll probably be either the same or another data structure. And when I say data structure, I'm just talking about the way that we form our data. You've been using a bunch of different data structures throughout our entire time. We just never really called them that. We've been using objects. We've used these different things that hold our data or the way that we structure our data throughout our entire program. So we're gonna have different data structures. We're gonna be using different things that enable us to work through our code critically. But when I say algorithm, right,

02:14:00
when I say algorithm, I am just talking about the steps you take to solve a problem. When I say algorithm, I really am just in this point talking about a function, and this function is gonna transform data from an input of one data structure to a certain output that is another data structure. Throughout our time together, we'll look at things like, We've already seen things like queues and stacks when we did our event loop. We're gonna look at things like heaps and linked list and all these other ways to structure our data, but we're gonna get to that in time. All right, the function that is our algorithm contains the logic that decides how we transform our input to our output, right? that figures out how we take this thing that we're putting in and how we get this thing that we're taking out. And to really kind of put a conceptual framework

02:15:00
behind this, because it's one thing just to say like data structures, but then to like actually think about like what a data structure might be, it's kind of like a jump that we have to make. So give me the chance to make that jump. All right, I like to think about when I'm learning about data structures and algorithms, I like to think about a library, right? I like to think of a library. And this example comes from Scotch IO. I always thought this was the best primer on data structures and algorithms that was ever out there. They took it down when they were acquired, but it's still on the way back machine. And I really like this example because it gives us something like physical that most of us probably have experienced that we can tie these like kind of ambiguous concepts to. So a

02:16:00
library contains many different data structures, Books, magazines, CDs, DVDs, Blu-rays. When I was in Boston, our libraries were lit because they had like video games too. Like you could go get like 3DS games and other like video game stuff, which was always pretty cool, right? So a library contains a lot of data and that data is structured in many different ways. We can have data that's represented as a book. We can have data that's represented as a magazine. We can have data that's represented as a CD. We can have data that's represented as a DVD. We can have data that's represented as a Blu-ray. Lots of different data represented in different data structures. In this case, our different data structures would be these different objects, the books, the magazines, the CDs, the DVDs, the Blu-rays. Now, if your data is just a bunch of

02:17:00
text, it makes sense to use a book to hold that data, right? Like, let's think about that. If we have our data and our data is just a bunch of text, right, then it makes sense that we would use a book to store that data. However, if our data was a bunch of, let's say low quality video, it would make sense to use a DVD to hold that data. So there are better ways to hold different types of data. Could we put our book on a DVD? Yes. And can we break down our videos into individual frames to put in a book? yes, but we wouldn't be using the appropriate data structure for that

02:18:00
data, like it just wouldn't make sense for video to be in a book and for our text to be on a DVD. So as we start to evaluate our data, we'll think about the different data structures that might be appropriate, right? Then there are some other things we might start thinking as we start to evaluate the right data structure as well. So DVDs have a limit on the amount of data they can hold. They are cheaper, but they are constrained when compared to Blu-rays. Blu-rays can hold more data, but they cost more. So if you have a bunch of video, you could use a DVD to hold that, they are cheaper, but you might run out of space. Whereas blu-rays can hold more data, you have more space, but they cost a little bit more.

02:19:00
Now, when we're worrying about real data and its cost, we're not really talking about like the monetary cost, like a DVD being cheaper than a blu-ray, right? The cost when we're worrying about our code and the data that we're representing in our code comes down to two things, space and time. Space is really just the amount of memory that this structure is gonna take up. And time is how long does it take us to get done the things that we wanna get done. And this works, this comes into play with our data structures, and it also comes into play with our algorithms. As we start to evaluate different structures, as we start to evaluate different algorithms, we're gonna keep our mind on the cost, not the monetary cost, but how much memory will it use and how much time will

02:20:00
it take up. I like to think of a very common data structure that comes up in interviews all the time, and that's a linked list versus a doubly linked list. This is a quick pulse check. If you've heard of a linked list before, just throw like an emoji or an emote inside of chat for me. Just kind of see where folks are at. Just throw something in the chat. Okay. Might've run into it in your code wars or your elite code. Might've started doing the data structures algorithm homework already. Cool. So, we have a linked list up here on the top and a doubly linked list here on the bottom. Now, something interesting about a linked list is that it uses way less memory, but it is less efficient, why? Why would I say linked list is a little bit less efficient than a doubly linked list?

02:21:00
It's one way, exactly. A linked list literally takes up less memory, but we can only go one way. Now a doubly linked list takes up more memory, but it's more efficient because we can go both ways, right? So if you were ever in a situation where you only needed to go that one way, you would be better served using a linked list as opposed to a doubly linked list that would take up more space. So these are all the considerations that we need to start making. To make good decisions as an engineer, we need to understand the different structures for our data and the implications it has for how our code takes up space, how it takes up time, how it will impact the things that we are trying to do. And so we are gonna learn a bunch of different data structures that are

02:22:00
important to have memorized, are important to have in your brain, but it just helps us make better decisions, right? That's the whole point that we're trying to do. The whole point about learning data structures and algorithms is to just be able to make better decisions. Now, like I said, you can get away with most of your coding challenges, right? With just knowing methods and just brute forcing your way through these problems. But we saw on Tuesday that I was able to solve a problem using nested for loops. And while it worked, I don't think that was the best engineering decision that I could have made. There was definitely a way to optimize that code, right? To make it better in terms of the cost that we care about in terms of space

02:23:00
and time. So that's the point of what we're trying to do here, is that we're gonna start learning these things that make more sense, that enable us to make better decisions, that enable us to think critically about our code, and in the end, write more optimal code. Now, the reason why I tell you all to learn your methods first is because the methods, someone's already done the heavy lifting for you. Pretty much all the methods that you're gonna use in JavaScript, right? Depending on where they're implemented because each browser can technically implement the methods a little bit differently, but somebody's already thought through how to do it the most optimal way, right? Like if you look at the code underlying those methods, they're using the best data structures, there's the best algorithms, like everything that could be done to optimize that code. So by

02:24:00
using the methods, you're probably already using the optimal stuff, right? And so that's why I'd like the folks to start there. One of the things that you might do, right? One of the things you might do is, I often will just look up the runtime or we'll eventually look up the runtime complexity or the time complexity of those methods. And I just have them in my Anki. So when I'm in an interview and someone says like, oh, you use this method, do you know how optimal your code is? Boom, yeah, I've already looked this up. It's already been in my Anki for months. Every time I look at that method, I also know the amount of time that it's taking up. So what we're gonna do now is we're gonna look at ways to make better decisions, the things that we should be thinking about. And through our standups, I'm going to expose you to a lot of these data structures through standups. I'm going to expose you to a lot of these algorithms, and it'll also be in the homeworks that you have assigned as well.

02:25:00
So to kind of visualize some of this and start to think through how we can make better decisions, let's go back to the library. Not hard to have fun when you have a library card, folks. How am I looking up, um, I, I stack overflow, uh, like if you, if you like, if you just look up like time complexity of a method, uh, there's always a stack overflow post on, on it with somebody that'll pull up like the actual, like, like ECMAScript specification or like the V8 engine, like specification for it. That's how I find most of them. The real code weenies, exactly. You know, you need code weenies every once in a while. Cool. Let's go back to the library. The best data structures consume minimal resources while storing the data in a meaningful way for various

02:26:00
operations. What? Let's think about this again. The best data structure, typically when you're making decisions on what data structures to use. The way you're gonna say that was the best data structure is because it's gonna consume the least resources to store the data in a meaningful way. The meaningful way is the really important bit here. Because we could have a data structure that's more optimal, but if you can't do the things you wanna do with it, it doesn't make sense to use it. All right, so let's talk about that. Let's talk about a flipbook versus a DVD. All right, we could print out our video frame by frame into a flipbook, right? It would work. The data structure would store our

02:27:00
video frame by frame in a book. And if we wanted to, we could sit there and flip it and see the video happen, right? Or we could store our video on a DVD. Now there are some considerations to make here. What's using less resources, right? And can we use the data in a meaningful way? If we know that we're going to use the data to take screenshots of our videos Flipbook might be better Right, but if we know we're gonna watch the video then the DVD is probably better All right liquid words, hey, how you doing So when we're evaluating these different structures for our data, a flip book versus a DVD, we have to evaluate, all right,

02:28:00
what is the, how am I going to use the data, right? It's not always just, this is a more optimal data structure. It's, well, I'm going to use this structure because this is what I want to do with that data, right? Who brings up a good point? If I want audio, then flip book, that data structure is out the window. There's no audio with a flip book. So if I want to be able to listen, then that cuts off that data structure immediately. So it's not just about optimization. It's about how we're going to actually use the data that we are storing. Cool. All right. I want to ask a question here. We're in a library and I want a specific book. What could I do to get a specific book? I want us to come up with an algorithm, right? I'm gonna give you a data structure that's

02:29:00
holding a string, a name of a book. And what I want as the result of this algorithm is the actual book. So I'm gonna give you a title or the name of the book and you're gonna give me the actual book. Now, we're in the library. What is our algorithm? I've given you a string and I want a book back. What could I do to go and find the book that I've just given you? My algorithm is ask the library, use the card catalog, look it up. There's a lot of things that we could do. but let's think about how we can simplify this for a second. I could walk into the library and realistically I could check every book, right? I walk into the Boston

02:30:00
Public Library main branch, I don't know how many floors they have, probably a million plus books, right? I could start with the first book that I see and check every single book, right? I could check every single book. I could just go in order until I find it. Would I eventually find the book that I was looking for? Let's say that the book does exist, that it's in the library. Yes, you might die first, but yes, eventually 2-3 days later I might find the book, right? We're assuming that it's there, that it's not checked out, yes, we would eventually find the book. Is there a more optimal way for

02:31:00
finding a book? Absolutely, there's a Dewey decimal system, there's sorting, there's ways to look it up. So we use algorithms every day of our lives. We use data structures every day of our lives. Whenever I start talking about data structures and algorithms, it can feel scary, right? You already use these different structures for your data all the time. If you've ever been to a library, a book with a data structure for your textual data. Textual, that just sounds cool. You already knew how to handle your textual data, right? It could be in a book, right? Right, right? It could be in a book. You already know how to handle your video data, right? That could be in a DVD, right? You're already used to accurately

02:32:00
picking the right data structure for the data that you care about in the way that you're going to use it, right? If you know that you are going to want to see all the text, right? You're gonna want all that textual, all that textual data, right? Then it's probably gonna be a book. But if you want video, it makes sense to go for the, for the DVD or the Blu-ray. So you already know how to choose the right data structure for the task at hand. You do it all the time. When it comes to code, there are these data structures we have to learn. Heaps. We saw queues. We saw stacks already. We're going to see these different types of lists. We're going to see all these things that we were going to pick up over time. Right? But you already know how to use data structures. Now it's just using data structures relating to your code. Now, you also already

02:33:00
use algorithms all the time. None of you would walk into the library and go, all right, I'm gonna start with book one, and I'm gonna go linearly through all of the books until I find the book that I want. Right, you're going to find that book you want, you find it, finally get your textual healing, textual healing, you find the book, right? But none of us walk into the library and go through all the books until we find it. we have a better algorithm to find the books that we want. We know that we can, we know that the books are sorted already. We know that we can go to a specific area where that book might exist. We know that we can go to the librarian and get the book that we want. So we already know how to use algorithms

02:34:00
and you already know how to evaluate the complexity of those algorithms. You know intrinsically that checking every book would take too much damn time So it's gonna be the same thing when it comes to your code There are gonna be certain ways that when you write your code and you look at your code You're gonna be like that's taking too much damn time There's a way that I could do this more efficiently that I could do less and get the thing. I want faster Alright, if we were to do it book by book, it would take us a lot of time to move through each book. But there are also other concerns too, like, did we already go through that row? Right? Did we already go through that row? Do we remember all the rows that we've already been to? It's a lot.

02:35:00
So I'm going to ask you, what do you think would be the most efficient way to find your book? What's the algorithm that you would use to find the specific book? What are you going to do? Ask Bob. Library, ask the librarian. Hash map, it's always hash map. The answer is always hash map. You ever stuck hash map? Ask the librarian, cry in the corner until somebody comes and helps you, use the Dewey Decimal System, does that still exist? Identify the Dewey Decimal Number, locate the position in the library based on that. I think there's a whole like we're thinking like that. Oh my gosh Into old

02:36:00
I just think that like There's no way in hell There's no way in hell that by the time my child is old enough to like really go to the library that they're using the Dewey Decimal System. There's gonna be an app on their phone, right? And they're gonna type in it, and it's gonna be like, go here, right? I just, it works. I just don't know, like, will it exist still? Like, will it be a lost art? Exactly. Will there be a new library meta? Will there just be QR codes? Like, I don't know. Right, will it still be there? Will there just be air tags in each book? I don't know. I just did a coding challenge for an interview. They told me the structure they wanted the answer

02:37:00
in. They didn't just care about the right answer. This matters. It really does. Cool. So yeah, so there's a lot of different algorithms that we could come up with to find our book using the librarian, using the Dewey decimal system, I'm going linearly through each book, right? Asking someone to go find it for you, paying, I was gonna say, don't do this. It's like, pay the kid in the children's section to go find your book. No, please don't do that. Now, how long it takes to find our book is our time complexity, right? Is our time complexity. Searching each book by book would probably have one of the greatest time complexities. Asking the kid that doesn't know how to use the Dewey Decimal System to go find your book might actually be longer in terms, like less

02:38:00
efficient in terms of time complexity. It might take them longer because they get lost. They go home with their parents and you don't see them until next weekend. So that might be an even less efficient system. And now they have money. they just went to the gift shop or the cafe or whatever, right? So these different algorithms and how long it takes to find the book would be our time complexity, right? We could go book by book, that would be a long time. Using the librarian might be a little bit faster, using Dewey justice system might be a little bit faster, right? So there is how long it takes to find our book what we would consider our time complexity. And so thinking through the appropriate data structures, do I want a book? Do I want a DVD? Do I want a Blu-ray? And the appropriate algorithm, am I gonna go book by book? Am I gonna use the librarian? Is how we can efficiently solve problems. And yes, these are silly examples. Yes, we're talking about books and libraries

02:39:00
and things like that, but it is the same process when it comes to our code. How are we gonna structure our data? in a meaningful way, so that we can do the things that we want to do with it. And what is the algorithm, the steps that we're going to take to solve the problem, and is there a way to do it with less steps, to do it more efficiently? These are the concerns that as engineers, we need to start thinking about. We need to start bringing these concerns to the code that we write every day, and then to the code that we especially write for our coding challenges. Now I bring up the word effectiveness, and so when we're talking about the effectiveness or the complexity of a solution, we're gonna use something called big O notation. We're gonna use something called big O notation. And so all big O notation is, is a way of mathematically describing the complexity of your

02:40:00
algorithm in terms of space and time. Now, these are a lot of big words, You can treat them as disrespect, but all it is is a handy reference to say, all right, this is how long I think this is going to take. And this is how much room or space in terms of memory I think this is gonna pick up. And so it's not really, like we don't really have to know math here. Don't let that get you scared. It's just a way for us to be able to talk about the different complexities that we are running into. And for us to talk with other engineers about how we might make our code more efficient. So there are a few common complexities that we're going to start off with. I'm just going to very much skim the surface here. This is just to get these ideas in our brain. To get them top of what we're thinking about. So that as we start to write our coding challenges throughout Huntober. As you continue to do your code wars and your elite codes. These things to be at the top of your brain. I want you to let

02:41:00
them marinate over the weekend. I want you to do the data structures and algorithm homework over the weekend and we come back Tuesday. We'll go deeper We'll go deeper with our big O notation. So here are Three I'm only gonna focus on three common complexities O of one or constant time O of n or linear and n squared or some people call it quadratic These are the complexities that I'm going to focus on tonight and I want to walk through where we might see them. We're going to talk through some examples and we'll end it there. So you have maybe we'll end a little early, maybe you'll get a chance to maybe start jumping into that homework and see these in play. So when we're evaluating kind of our algorithms or we're evaluating the efficiency of our code,

02:42:00
right? Right. That's the first time I see somebody do that. The we don't with the end early. Code winning is really sweating right now. They are. They can't. They're just trying to chomping at the bit. Like I said, this is an easy introduction. This is not like the end-all be-all, right? Cool. Cool. It's not the end-all be-all, right? Here we go. I want to start thinking through the number of inputs versus the number of operations that my code would have to use. So the first thing I want to think about in terms of inputs and operations is let's think of an array.

02:43:00
So you can think about this chart as showing the number of inputs increasing and the number of operations increasing as well. So with an array, let's say I had the numbers one, two, three, four, and five in my array. If I wanted the first number out of my array, how could I get the first number out of this array? I want the first number out of this array. Yeah, I could use the zero index. I could do array and use the zero index. How many operations did I have to perform to get the first number out of my

02:44:00
array? One operation. What if I added a million inputs to my array? What if my array now doesn't stop at five, but it goes all the way to one million? All right, that's where my array goes now. Does it change anything? Nope. So this is an example of constant time. No matter how many inputs I have as part of my array, accessing, let's say the first, the first element in the array, it never changes. Like accessing

02:45:00
an element based off of its index will always just be one operation, no matter how many inputs there may be. What if I wanted the last value in an array? It's still just one operation, right? We could do, it's gonna be a little fancier looking array. And we'll do array length minus one, right? It's still one operation, all right? All right, all right, still one operation, right? So we can say that accessing an element, right? accessing an element

02:46:00
in an array by its index happens in constant time or O of 1. No matter how many inputs we have, right? No matter how many inputs we have, the number of operations will always stay the same. Now, let's think about our library example. I want to find my book in the library, right? I wanna find my book in the library. Right now, the library has a million books, right? My library has a million books in it. But Big Daddy Gates rolls through, and

02:47:00
you know what, donates a million more books. Right, donates another million books. So my inputs went from a million to two million. If I am going, if I am going to go book by book, my potential operations just what? doubled. Yeah, they just doubled for each book I added. I added a potential operation. if I am going book by book, right? If I am going book by book, my number of operations are going

02:48:00
up linearly, right? They're going up linearly. Each input means that there could potentially be another operation. So we call this linear or O of N. In this case for each input, I might have to do another operation. So if the algorithm I was following was to check and try and find my book, book by book, right? Book by book, right? There might be a worst case scenario where my book is the last book in the library, right? And as I added an input, I also added a potential operation. Cool. Yeah, exactly, worst case scenario. Now, something interesting is that we'll get to, not today, but you'll see that there are

02:49:00
some instances where linear complexity seems like it's better than constant time, or there's like these other ones like logarithmic and even quadratic. There seems to be some instances where like linear might be a little bit better, but that doesn't seem right. Like constant time is always one operation, right? But that linear, when would this linear algorithm pay off? Like when would this linear algorithm where each book I add adds another operation, aka another book I have to check, Like when, when would this might pay off? Small stuff. If there's only one book in the library, yeet. I got it. Right. Or if it's the first book I check, right, small input sizes, getting lucky with being at the first book. Like there are some things we could think about later on. And we'll get to this on Tuesday, right? Where in smaller sets of data, things get a little weird. but we're talking

02:50:00
about the long haul here. We're talking big picture, right? We're talking big picture, right? Talking worst case scenario. As we add another book, we're adding another potential operation. Now, the last thing that I want to talk about today, and then we're going to break all these down, is this N squared. We saw an example on Tuesday of a time complexity that's n squared what was that that what was that thing that we saw that was a complexity of n squared yeah it was the nested for loops so we had nested for loops that were trying to find um that were trying to find uh it was matching numbers right trying to find the the the the matching numbers, or sorry, the numbers that added up to a target value. And so what we had to do was we had an array of numbers,

02:51:00
right? We had one, two, three, four, five. We had an array of numbers. And what we were trying to do was find which two numbers equaled, I don't know, let's add six here too. Be a little easier on ourselves. what two numbers added up to 11? Right, what two numbers added up to 11? And so we have these two nested for loops where the first loop was grabbing a number, right? The first for loop was grabbing a number from the array. And then the internal for loop was comparing that number to every other number in the array. And if it didn't find anything, then it moved on to the next number. So this would it do if we were actually to run out this this to some code we would pick the number one And then we would do one plus one doesn't equal eleven one plus two doesn't equal eleven one

02:52:00
plus three doesn't equal eleven One plus four doesn't equal eleven one plus five doesn't equal eleven one plus six doesn't equal eleven and then our outside loop Would go up To the next number but our internal loop still had to do two plus one doesn't equal 11, two plus two doesn't equal 11, two plus three doesn't equal 11, two plus four doesn't equal 11, two plus five doesn't equal 11, two plus six doesn't equal 11. And then we had to go to the next number. So for every number on the outside loop, the inside loop had to do it all those times. So think about the danger of adding a single input. If we make this go from six to seven, how many more operations do we need to do? Cause now this internal loop also has seven. So we add one input and we have at least what? At least one, two, three, four, five,

02:53:00
six, seven, seven more operations, right? With just one singular input addition, this internal loop has to do so much more work. As we add a singular input, we can see our time complexity almost becoming exponential. And I'm using that word very, very loosely here, right? That you could see this, just how aggressively we're going to be adding operations for each input that we add, right? With a linear complexity, it was a little bit different. Each input we add, we just want to have one operation, Another input, another operation. But with a quadratic or N squared complexity, boom, through the roof, two inputs, and we're adding so many, so many more operations. So that's where these complexities come into play.

02:54:00
We can start to look at our code and think through, all right, does anything change when I add more inputs? Does it stay constant, right? If I add one input and I only get one operation, does it continue that way linearly? And if I ever find myself in a situation where I'm adding one input and I'm just getting exponentially more operations, I need to pause and think to myself, is there a way to do this more optimally, right? So that's what we wanna get. We wanna be able to evaluate the code that we're writing in terms of these complexities so we can write more efficient code, not only for ourselves, but also in technical interviews. During our interviews, you're going to solve a problem and one of the common questions your interviewer might ask, is this the optimal solution? And if you looked at our solution from Tuesday, you would say, no, this solution seems like it's nested four loops. This looks like it's N squared.

02:55:00
There probably will be a way to make this more optimal. so when We come back from our break. We're gonna dive deeper into these different complexities I'm going to show you some examples of constant time. I'm going to show you some examples of linear time I'm going to show you some examples of our n squared or quadratic time and We're gonna get a little more comfortable with them and then we'll stop for the evening We'll let these things percolate in our brains over the weekend You'll have some homework to work on over the weekend that puts these into practice and we come back on Tuesday we'll go deeper and we'll add a bunch of other complexities to the list. But the idea here, right? The idea here is that we are moving into this world where it's no longer just about writing our code. It's about writing our code optimally. It's about choosing the structures for our data that do the things we need it to do and the algorithms that get the job done efficiently. Cool.

02:56:00
How can we do the two array numbers more efficiently? That's a hash map, which we'll get to later this month. We can't be baddies no more, exactly. We gotta be efficient baddies. Bye, Tina, no. Tina's always a part of us. Yeah, cool. All right, let's take our break. Five minutes on the clock here. All right. So let's see some of these examples and the trick that changed my life. All righty, so we talked about O of one already. O of one, you might hear some people refer to it as order one, if you're really like a code weenie, but more often it's called constant time. For all the inputs in our algorithm, there will always ever be one operation required. So no matter how many inputs we put in, our algorithm will only require one operation. Like the steps we're gonna take will be one step. Cool. So here is an example where we have an array of numbers.

02:57:00
And when we want to get a specific number out of that array, like we have, we have the, the, the, we want to get the first number out of the array or the last number out of the array. We know we can use the index, the one operation, right? One operation, and we can get that number, right? So if we wanted to get the first number out of the array, we just do nums zero. That would give us the first number. If we wanted the last number, we could do something like nums.length minus one. And that would also give us the last number in the array. So no matter how many inputs we have, we could add a million numbers to the array. And if we just wanted to get the first or the last or a specific number based on its index, it would only ever be one operation. So those types of algorithms

02:58:00
where no matter how many inputs you have coming in, you're only doing one operation, we call those constant time O of one operations. This is kind of where you want to get a lot of your stuff too. A lot of times folks will ask you, oh, can you do it in constant time? Can you do it in O of one? Can you take something that's quadratic and make it linear? Like these are the things you might start having as conversations with your cool friends All righty The next that we saw was o of n you might hear code weenies call it order n Linear is what you most often hear it as so a linear complexity is For all the inputs in our algorithm, so as we add more inputs We get one operation per input. So for each input we get an operation Input, operation, input, operation, input, operation. And so that linear complexity we call O of N. Now,

02:59:00
let's take through an O of N, an O of N problem here. And then I'm gonna show you the one weird trick for all the singles in your area, right? All right, here it is. Here's an O of N example. We have arrays. We have an array of numbers, right? We have an array of numbers. And I want to sum all the numbers in the array. Right? I want to sum all the numbers in the array. So if I have a linear solution, right, if I have a linear solution, the linear solution to sum this would be to loop through the array, grab each number and add that to my sum. So my array right now has five inputs.

03:00:00
How many operations will this linear solution require? Five operations. If there were a hundred numbers in my array, how many operations would it take to find the sum? Would take a hundred. So this is a linear algorithm, right? This is a linear algorithm. For each input I add, I add another operation, right? All right, I add another operation. And so, just to kind of play this out real quick, let's say our array was one, two, three. We would go ahead and run this for loop. The very first time it runs, we grab the first num, which is one,

03:01:00
and we add that one to our sum. So our sum is now one. The next time it runs, we grab the two, num is two. We add that two to our sum, which is now three. And the last time this runs, it's three. We grab that three, we add it to our sum. Now we're at six. So we had three numbers in our array. We did three, the one fricking place I could put the sum is right behind my head, right? All right, so for each number or each input we had in our array, we did one operation. So that's a linear algorithm. One operation per one input. But are you ready? Can you handle it? You ready to have your mind blown? Your world turned upside down? What was real is no longer real. What was good is now bad. What was textual

03:02:00
is now factual. All righty, here is something people refer to as Gauss's theorem or Gauss's trick. What it does is it says if you have an array that meets some conditions, right, Gauss's sum, yep, if you have an array that meets certain conditions, in this case, what do we notice about our array? Okay, what do we notice about our array? It's sorted, it's continuous, meaning it goes from one to the next number without skipping anything, right? And it starts with one. So it starts with the number one, It's in sorted order.

03:03:00
It doesn't skip any values, right? It's contiguous, right? So this array is special because it's already sorted. It goes from one to certain number. No funny business, exactly. But this is a pretty common array that we might see. And so there's something really cool. If we were to do our linear solution, if we were to do the linear solution that was O of N and that we just learned, how many operations would it take to solve this, to get this sum? If I wanted to sum these numbers with the O of N solution that we just did, it would take five operations. You ready? Let's take a look at this. So here is a function, and the function only performs one operation. It just grabs the last input. That's it. it grabs the last input. And when you have the last input in an array of numbers that starts with one, is

03:04:00
continuous, meaning that it goes from one to the last number, doesn't skip anything, you can just grab the last number, so one operation, and then do this math trick with it. You take that last number, you add one to it, you divide it by two, and you times it by the last number, and that gives you the sum. So let's go back to our easy array. One, two, three. We know our linear solution, this equals six. Let's try Gauss's sum here. Gauss's sum says take the last value, which is three. So we'll do three plus one, which is four. Four divided by two gives us two. Two times the last number, which was three,

03:05:00
gives us the same sum of six. My mind broke when I learned this trick. So now, we have a way, a way of taking a what would be a normally reasonable linear solution, but doing it in what type of time? O of one or constant. So we could now speed up this operation. It's just night and day, right? Like you went from having to do one operation from every input

03:06:00
to only having to do one operation no matter how many inputs there are. So this is an example of how we could take something that was a linear solution. And by having deep, like algorithmic knowledge, know that Gauss's sum or Gauss's trick, whatever you want to call it, could do this in constant time. This is why people study algorithms, right? This is why people study algorithms. is not that they are coming up with these solutions on their own. In fact, coming up with more efficient algorithms is not really a thing that happens unless you're doing your PhD in computer science or math or something like that, right? But what you are doing is memorizing a lot of these algorithms, right? So that when you encounter a similar problem, you know how to solve it in a more efficient way.

03:07:00
All right, so that's the point here. All right, that's the point. The point here is that we're memorizing exactly. We're memorizing some textual patterns here, some algorithms, so that when these types of problems show up again, we know how to apply it. If you're in an interview and someone asks you to sum an array of numbers, even if it's not a contiguous or sorted array of numbers, you can still pepper this out and go, oh, you want me to sum these numbers? No, it'd be really cool is if the numbers were all, like if the numbers were continuous and they were sorted, we could do this trick where this linear solution is actually in constant time. Can I show you real quick? Right, and then even if it wasn't the actual problem, the interviewer might get excited, and then you get the job, right?

03:08:00
You get the job. And so a lot of these, like these algorithms, I'm gonna show you, the algorithms that are coming up in the homework are so you can pull them out during your interviews, right? You can pull them out during your interviews and get to these optimal solutions. But I just wanna make sure I'm very, like abundantly over clear. This is not something that I would expect you to derive on your own. It's something that you memorize and that's why like you'll see people that leak code their eyeballs out And memorize a lot of these algorithms to make their jobs easier You know Can you show us how to properly do math on advocates I do have my abacus Cool so I hope that this kind of starts to make it click why these algorithms might be important, right? Does that make sense? Now, does it make sense why choosing the right algorithm, the right data structure might save you time

03:09:00
and can help you write more efficient code? Cool, awesome. Let's talk about the last one and that's where we'll end for today. Committing these to memory, like I said, is very important. and this Gauss's sum should be in your Anki deck for sure. These very simple linear complexities, these constant time examples should be in your Anki deck for sure. You wanna be able to start recognizing these. And as you start to solve your coding challenges on Code Wars or LeetCode, take another second at the end of your prep, right? Take another second at the end of your prep to see, all right, is this happening? How many operations am I doing here per input? Is this constant time? Is this linear? Is this quadratic? And we're gonna spend more time on Tuesday doing exactly that.

03:10:00
I'm gonna give you some real world scenarios, some code scenarios, where we'll sit back and kind of reflect on, all right, what type of time complexity is this? And can I do it better? Somebody said, could I run the math back again? Yeah, so if we did this normal array sum before, right? We had one, two, three. If we did the linear sum, right? If we did the linear sum, what we'd be doing is grabbing the one and then adding it to the sum, then grabbing the two and adding it to the sum to make this three, then grabbing the three and adding it to the sum to make it six. that would be three operations. Grabbing this input, grabbing this input, and grabbing this input. Three operations to get the sum. But with Gauss's trick, or Gauss's sum, all we do is grab this last input,

03:11:00
and now we can use it, this three, we can use it in this little math value here. So three plus one is four, four divided by two is two, two times three would give us the exact same answer of six, but we only did one operation. We only grabbed one input out of that array. So what took us three operations before is now only taking one because we know this algorithm. We know this Gauss's sum. So my, some folks have been asking this and I think it's a really good question. Why doesn't this count as an operation? Because none of this is, do I have it? No, it's in the slides on Tuesday. None of this is like exact,

03:12:00
right? These are theoretical complexities, right? We're not like literally counting like line by line. We're saying, all right, as I add an input, are my operations going up, right? Is this all exactly approximations? This is like rough, rough ideas. These are a theoretical concept that we're buying into so that we can explain the efficiency of our code. we're not really super focused on like, oh, 0.3 seconds, or like, it's exactly just that one. It's rough ideas of how we can talk about what's happening in our applications. Yeah. And even if,

03:13:00
yeah, thank you team. Even if we said, you know what, this whole thing is an operation. This operation only runs once, right? Like if we just said this whole thing was an operation, right. Even if we said both, like, even if we said this is an operation, and this is an operation, right? Do our operations increase with the number of inputs going up? So if I added, right? If I added a million inputs, and even if we counted this as two operations, right? If we said two, one, And we said two, one, right? We said two, one. So there's two operations and it stays two, no matter how many inputs we put in, that's still constant time. And technically what we'll get to on Tuesday

03:14:00
is that you would reduce this down to all of one or just one. So even if you counted it as an actual operation, it's still constant, right? And then we boil them down to the base notation that we're using, O of one, O of N, N squared, exactly. Am I wild for thinking data structures and algorithms might actually be fun? Now, I think so. This fundamentally broke my brain. This is when it, like, like I, I didn't understand, like, and you might be feeling the same way. Data structure algorithms didn't make any sense to me. Like, why would I do this? Algorithms, like, why would I invest time in like needing to know this stuff? And then I saw this and I was like, shit, this could be useful. I could see myself maybe running into some things where if I had more knowledge, I could do stuff more efficiently. And that's the beauty of, I

03:15:00
think, Hunt Tober as we're doing these daily standups. At first we're just solving problems, But once we get to like hash maps and like some other fun data structures some other fun algorithms that we have in our back pocket things that used to take an Exponential amount of time and I keep using that word very loosely we could do in constant time sometimes Like it's just it's just it's just mind-blowing and then if you think about the real implications this stuff could have on your code bases Like if you can if you can have something in your code base that goes from a linear to a constant or a worse time Complexity to constant like that's that's game-changing And so for me, this is fun. I love learning algorithms. I loved doing LeetCode when I was grinding out LeetCode because it was a chance to learn these really neat things. I put them into my Anki. And over time, you start to develop this sense for, all right, this is the complexity, and I know that there's this thing I can use that would make my job easier. Cool. The last one

03:16:00
that we saw was something that we call n squared and or quadratics and people might call it. It's where you have loops inside of a loop. That's like the easiest one. There are some loops inside of loops that aren't technically n squared, but whenever you see a loop inside of a loop, your brain should start going, wait a minute, wait a minute, loop inside of a loop, we might be getting into a really inefficient time complexity here, right? In this case, we are trying to see if this, if this array has any duplicates, right? And so we have a loop that's grabbing one number and then comparing it to all the other numbers inside. So if we were to run through this, our outside for loop is gonna start off with the number one and our inside for loop is gonna grab one, two, three, One, two, three, four, five. Why does

03:17:00
it stop me from writing? Did my Apple Pencil just die? Five, five, right? And it's gonna check to make sure that it's not the same number. So it went from number one, it didn't find another one. So then it moves on to two, and it's gonna do one, two, three, four, five, five. It doesn't find a duplicate, right? Then it moves on the three and it does one, two, three, four, five, five. Doesn't find a duplicate. So then it goes on the four. One, two, three, four, five, five. Doesn't find a duplicate, five. Finally with five, we get the one, two, three, four, five, but it was the same index, so it doesn't count. And then finally five, we find the duplicate. So we had five inputs, but it took us five times one, two, three, four, five, 25 operations,

03:18:00
right? With the nested loops, we had five inputs, but we did 25 operations, right? And if we had had more in here, we could have wound up doing way more operations. We had it like six and we got to add six to all of these lines here, right? So by adding one input, we added at least four more operations. Right, we had at least four more operations. And that's why the chart looks like this, right? For each input, our amount of time it's taking, the amount of operations we have to do is just skyrocketing, all right? Just skyrocketing. Cool. I see some people say, I love data structures and algorithms.

03:19:00
Gonna get the crew together. We're doing algorithms, baby. All right, so for homework, your first bit of homework this weekend, where I want you to start working through these things. Is the Scotch.io Data Structures and Algorithms course. You don't have to do it alone. Jump on Discord, get in a voice channel, start working through it. So data structures, I kind of talked a little bit about data structures last class. And I gave a lot of like, I would say weird examples. Right, I said, all right, think about books. Think about DVDs, think about Blu-rays, right? Well, I actually like that, because I think it's a good way to think about data structures. A book can hold text, right? And it's really good at going like page by page. It's easy to get to exactly where you

03:20:00
want to be, right? Like, I want to get to page 100, boom. You can jump to page 100. Very easy to consume text-based content. However, think about how many books I could fit on a Blu-ray, right? I have way more space, way more things I can do when I'm using a Blu-ray, but it might be slightly harder to get to the exact text that I want to get to. And so this idea of like data and the structure of it, we use in the real world all the time. Like we have a concept of like, all right, here's, I want to store data. and when I store data in this way, I get some quirks, I get some features, but I get ways that I can use and manipulate that data because of the structure I have chosen. Right? I can, if I store my textual data, if I store my textual

03:21:00
data, In a book I get some things that I might not get when I store it in a DVD when I store something in a DVD, I might be able to search through stuff faster. I might be able to hold more right, but we're used to storing data. organizing data, and it's something that we use every single day. So when it comes to our code, it's still kind of the same thing. A data structure is simply an organized way of storing data, whether it's text, numbers, right? It's a way that we're gonna organize that data. But when it comes to a data structure, the thing that you really kind of also focus on is how it's collected and organized so that you can perform different operations on it

03:22:00
correctly and efficiently. Like if I wanna find a specific sentence, is the book the best way to do it? Like is that the best way to store and organize my data? If I am storing a video, I could have my video as a flip book. Is that the best way to store my data to get to a specific scene that I want to watch? Or would a DVD make more sense to store my video content? Right? So this is a lot of big words, but why? Like, hold on. A data structure is simply an organized way of storing data. It's a pattern of collecting and organizing data for performing various operations correctly and efficiently. but why, like what is the reason? Like why does this play out? Why do we like do this? Why is it even worth thinking about this? And I just want to give you a very, what I think is an example that we might all feel

03:23:00
comfortable with having gone through program. If I wanted to store information about a stock trader, like a person who trades stocks, and I wanted to store information about them, Would it make sense to store their information as an object or an array? Chat is overwhelmingly saying an object. And so you've already know how to make these data structure decisions. You said, hey, if I want to store information about a stock trader, well, then an object makes the most sense because we know when it comes to using objects, we have key value pairs, right? We can store first name, we can store last name, we can store their location, their job title, their years of experience. We can even have a data structure inside of our data structure, right? Like recent trades.

03:24:00
And it makes it so that we can get the things that we want, right? We can get the things that we want quickly, right? So if I want to get their name, I can just do StockTrader.firstName, right? If I want to get their job title, I can do StockTrader.jobTitle, right? It kind of goes back to this idea that it's a pattern of collecting and organizing the data to perform various operations correctly and efficiently. Well, if I want to store information about a StockTrader, it makes sense to use an object because I can access the data in a way that makes sense. Right, in a way that makes sense. I don't see total losses. Yeah, we need to add that. Cool. So when you hear data structures, I don't want you to get

03:25:00
scared, right? You've been using data structures this whole time. Chat accurately picked the best data structure for the problem at hand. And what you're going to do as you go through the homework, not only the homework last week, but the homework that's assigned for this week, is you're just gonna add more data structures, right? You're gonna add more data structures to your repertoire. You're gonna add more data structures to your tool belt, and these different structures are gonna be usable for certain types of data that you wanna store in a way that makes sense to consume that data. So it's not just the data, but it's the way that you can access and organize the data that makes up the data structure. When I think of a library, I think of a lot of different data structures, because I'm storing a lot of different types of content. I'm storing text inside of books. I'm storing video inside of Blu-rays. I'm storing gaming

03:26:00
data inside of a video game, right? Like, we learn these data structures in our day-to-day life. It's not anything different when it comes to our code. Let's see another one. What if I wanted to store the stock traders recent Tesla purchase prices, right? This stock trader is trying to accurately pick up Tesla stock at the cheapest price. And I just want to store the prices at which they bought the stock. Does it make sense to store as an object or an array? And chat overwhelmingly is saying array right now because that makes the most sense. We are already used to using data structures every single day to solve our problems when it comes to code And array makes the most sense Right we can have they bought it at 208. They bought it at 205. They bought it at 217 They bought at 222 220 right like they these are the price the the purchase prices that they made

03:27:00
now why? Why would an array make the most sense in this case? Could we technically have an object that had the purchase prices? It's all the same key. Yep, it's all the same type. Ease of access and memory, that could be a thing here. So we can sort it, we can get the average. The things that we want to do at these prices probably requires us to loop through all the prices, to sort the prices, to find out which prices were the min, like all the things that we'd want to do with this type of data, an array is in a way more efficient data structure to do the things that I want to do with this kind of data, right? Like if I want to

03:28:00
sort it, I want to find the min, the max, if I want to find the average, having it already in an array is the better data structure because it can do the things that I want to do with that data. Could I have an object that had like price one and then a price, price two and then a price? Yes, but it would still be harder to do the things I wanted to do with that data, Like, could I easily loop through it? Yes, but then I'm doing things a little bit more difficult. I'm not gonna be able to do the things that I could as quickly and efficiently do with an array. And the cool thing is, if I did want that level of data exactly via BSL, I could have an array of objects if I wanted that level of detail, right? So I still get all the benefits. And so these are the things that we start to think through when it comes to data structures. All right, I have this data that I want to organize.

03:29:00
What is the best structure to organize that data? If I'm trying to organize something about like a person, an object just makes sense, right? Like I could have their first name as a key value pair, last name as a key value pair. If I want to store the price of their trades, it makes more sense to be an array because I can do the things I want to do with that data easily. Does that make sense of why data structures could be important? Like we're already using them, right? We're already using them, but as we add more data structures to our, our tool belt, it becomes easier to organize and work with the data that we run into. Cool. Yeah. Madeline of trivia says, Rivia says, we just need to pick the best one. Exactly. You just need to pick the best one. Now, how do you learn to pick the best one? You do your code wars, you do your leak codes, and you come to

03:30:00
the boardroom. Every Monday through Friday, 6 p.m. Eastern time on Remo for standup. Because what we're going to do is at first, yeah, we're just having some fun solving some problems, but quickly our days are gonna turn into, all right, here's the problem at hand. What data structure makes the most sense for this problem at hand? At first, we're doing really messy stuff. At first, we're doing things that work, that were brute force, and we're working our way up to hash maps and other fun data structures that we haven't seen. and we're bringing stacks and queues back into the mix. We only saw them very briefly when we were talking about the event loop. So as we start to progress in standup, we bring more of these data structures into our repertoire. It'll be part of the reading

03:31:00
for those problems and it'll be part of the problems that we're doing. And so you can slowly build up your knowledge of these data structures and feel more comfortable with them over time. Could you do this on your own? Absolutely. You can keep doing your code wars, you can keep doing your leak codes and you'll build that up as well. What I'm doing with stand up is I've cherry picked. Quite a few that I think leads to that natural progression where each one kind of starts to build off the other. Cool. Are the remote rooms getting full now? Like I said, we've been hitting between like 5 and 600. There's a cap of 800. There you go. Alrighty now. Those are data structures. We also talked about algorithms. And so an algorithm is simply the steps you take to solve a problem. That's it. What steps are you gonna take to solve a problem? They come together because often

03:32:00
if we're talking about data, the data structure and how we store that data might dictate kind of what type of algorithm we use, right, to solve a problem. That's why they kind of come in tandem. But when you think of an algorithm, it's just the steps you're taking to solve a problem. And that is it. Now, when we're thinking through appropriate algorithms, we're trying to think through the efficiency of solving a problem. So when we have a problem at hand, as we're seeing our code wars, as we're seeing our elite codes, as we're seeing real problems on the job, we can think through different steps we could take to solve the problem, and as we are thinking about those steps, it enables us to say, all right, the steps I took in this solution, is it as efficient as the steps I'm taking in this other solution? And eventually, what you start to realize is that you can memorize quite a few

03:33:00
of these steps or these solutions to solve common problems. And so just like you can build up your data structure knowledge, you can build up your algorithmic knowledge, right? You can build up your algorithmic knowledge where you're figuring out, alright, in terms of space and time, how efficient are the steps I took to solve that problem? And the cool thing is there are a lot of algorithms that solve or the steps they take to solve that problem that are efficient in terms of space and time. So you can brute force solutions, which will get you there, or you can be exposed to these different algorithms that someone has taken the time to think through the space and time complexity, how much memory they're taking up, how long it takes to run in terms of for each input, how many operations am I increasing, right? Once again, space, just how much memory is being used, time, how many operations

03:34:00
are executed per input, right? if we start to build up our algorithmic tool belt, we can start to find solutions to problems that take up less memory and perform less operations per input. Now, when we're trying to evaluate the algorithms or the steps that we took to solve the problem, we need a way of talking through how efficient one solution is compared to another. And so for that, we use big O notation. But why, why do we use big O notation? What the heck, why, where does big O coming from? What is this notation? Big O notation just mathematically describes the complexity of an algorithm, like the steps you took to solve a problem in terms of how many

03:35:00
operations per input are you taking and how much memory are you consuming. Big O is the mathematical notation for those two things and why do we use this? Like why do we need this notation? Why can't we just say, Leon, I wrote code, I can see that it's more efficient than this other code. Right. Why would the code that's running on my computer, what, what, why do I need this like universal language to talk about how efficient my code is? Well, one, it helps us describe it to others. Exactly. But what we also have to understand is that if I run an algorithm on my souped-up PC, right, my PC has a 3090, soon to be a 4090, it has a Threadripper 3960X, like if I run

03:36:00
an algorithm on that computer versus running an algorithm on my Chromebook, even though it's the same kind of code, one would run faster, right? We can understand that our code runs faster depending on the computer, it runs faster depending on the environment, right? Like I'm running JavaScript in my browser, what if I ran it in Bunn? Would the same algorithm be faster? Like, let's stop and think about this question for a second. The same algorithm running on my beast of a PC, 3090, Threadripper, 3960X, 256 gigabytes of RAM, right? I take that code, right?

03:37:00
Take that code, I run it on that PC. I take the same code and I run it, right? Take that same code and I run it on a Chromebook and I just looked at the raw numbers, right? On the PC it ran in one second, on the Chromebook it took 20 seconds. Does the amount of time that it took to run on my PC versus the amount of time that it took to run on my Chromebook, tell me anything. Like the raw milliseconds, does that tell me anything? No. So when we're evaluating, when we're evaluating the efficiency of our code, it's not really the raw numbers. like

03:38:00
how fast it executes, like in terms of like the actual amount of time. When I say time complexity, I'm not really caring about the actual amount of time. I'm caring about the rough estimates, right? I care about the rough estimates so that I can convey my ideas to you as another software engineer, and you can convey, Leon, I actually think we could do this more optimally in terms of time and we're not going to sit there and compute the actual number because that'll be relative to the computer, the environment, how cold it is in your room, right? Like all those things could affect the raw milliseconds. So we need a way to talk about the rough estimates, right? The way that as engineers, we can talk through actually, as we do this

03:39:00
type, if we take these amount of steps, we're exponentially adding to the number of operations we have to do. And that's where big O comes into play. And it's where it's worthwhile to memorize some common complexities. So when we come back from break, we're going to take a look at some constant time complexities, some logarithmic, some linear, some quadratic, see where we might run into these different scenarios, see some oddities as we kind of run into these different scenarios, and hopefully walk away at the end of tonight being able to look at a problem and go, oh, this algorithm or steps I took to solve a problem is more efficient because it is happening in constants Whereas this one is less efficient because it is happening linearly. And we're actually going to see some really. We're going to see some. Examples where at

03:40:00
first it seems like it might be one, but as we think about it, we're going to realize, oh, it probably is another. So when we come back, we're going to see the common complexities again. It's a nice space repetition in. We're going to see some real world examples of a problem that I'm currently facing and how I could solve it using this big O notation. when we're gonna actually take a look at some common stuff that we use every single day in JavaScript and ask ourselves, wait a minute, underneath the hood, what type of complexity are we talking about? Now, you could big brain it and go deep into like the real math behind all this stuff. If you really went to like nerd out about big O notation and you have somewhat of a math background, the cool thing is that like MIT's entire computer science curriculum is online, including all their lectures on this stuff. And so for folks that have that background and want to you can definitely dig into it But is it necessary?

03:41:00
Charlie said hard pass. No, it's absolutely not necessary Once you have a job You're getting paid well to do this stuff and you want to start leveling up. You can come back to all this Do you need it for your first job? Do developers make it their whole career without knowing this stuff? Absolutely, right? But once you get paid, you wanna come back and level up, you can. It's all out there for free. Talked through some common complexities. We talked about Big O being rough estimates. Let's go ahead and take a look at some of these complexities. Let's take a look at our quadratic, our linear, our logarithmic, our constant. And I actually wanna get to the point where we can understand what's happening here. Like if we look at this, it looks like, it looks like in some situations, linear, for example, is better than logarithmic. And I wanna make sure that by the end of tonight, we kind of understand

03:42:00
how that could be true. So that's kind of one of our goals for this portion. All right, we saw last class the basics, So we're gonna kind of walk through it to get our repetition in, and we're gonna see a new one, and then we're gonna have a greater talk about it. And then we're gonna see some examples. All right, for all of our inputs to our algorithm, there will only and ever be one operation required. So no matter how many inputs we have going into, right, how many inputs we have going into our algorithm, only one operation is being performed, right? And so we call this O of one or constant time. What is the classic example of something that has a lot of inputs, but only requires one operation? Something that we saw quite a few times. Yeah, getting,

03:43:00
getting like looping through, like getting, getting some, not looping through everybody, like getting something out of an array, right? If we wanted to grab say the first number out of an array, no matter how many inputs we have coming into this array, this could go from one to a billion, right? If we still want the first number, boom, we can do index zero and get that first number. If we want the last number, we can do array and inside the square brackets, we could do the array dot length minus one. and that would still give us one operation, even though there is a billion inputs, right? And so the beauty here is that we can have any number of inputs that are going, but only take one operation. So we consider this constant time. All right. Now, another example we saw last class was this idea that as our inputs increase, so do our operations.

03:44:00
So for each input I have, my operations increase. When I have an operation for each input, we call that linear, O of N, or linear. And what is an example of something we've seen that was linear? Yeah, looping through an array of numbers, right? FourString said, why is this not two steps? Don't confuse steps with the total number of operations. Remember, we're going for rough estimates here. We're going for, it's not the actual counting of steps. It's like, what do we have to do based on that input coming in? So even if you treat it like grabbing the value and then putting that value into the index,

03:45:00
That's still like two steps for any number of inputs. So if that was two, one, what is two, one reduced down to? One, right? So we'll see that again in a little bit, but the idea here is that if you're doing something, it's about, yeah, it's a rough measure, right? It's a rough measure. It's not the exact like, oh, I did this, this, this. Like, no, no, it's a, it's a rough measure of how many operations you're performing. So in this case, we consider this one operation. If we want it to say, loop through our array and create like a sum, right? Like create a sum, right? And each sum requires us to look at each number that's in the array, right? So if we have one, two, three, four, five in our array, we loop through that array. we grab the value

03:46:00
as we loop through. So if there are five inputs in our array, how many operations are we going to perform? Yeah. Five operations for five inputs. Is big O like the worst case? Yeah, it's like the worst case scenario that you can run into. And yeah, so somebody else say it's about how it scales. Exactly. We're trying to measure the efficiency in terms of time right now, right? How many operations? So it's about how that, that efficiency scales. Remember, it's not about the, the rough actual, like actual numbers, right? It's about talking at a high level about what's happening in our algorithm. and how does that algorithm scale as our inputs increase?

03:47:00
Right? If we're talking about something that's happening in constant time, right? We're talking about something that happens in constant time and it takes like an extra step for us to get that value, right? Like it takes, like we're gonna set, actually we'll see it over here. Like if I wanted to figure out how to go from this linear complexity to something that uses constant time, We could use Gauss's summation that we learned about last class, right? That Gauss's trick or Gauss's sum. What we could do is we have this linear complexity where we're looping through each number, right? We're looping through each number. And as we loop through, we're grabbing each input to add it to the sum. So if there were five inputs, we had five operations for this linear solution. However, when we look at Gauss's sum, what we are doing is we are going ahead and grabbing the last value. Oops,

03:48:00
this should be A. I forgot to update this slide. We are grabbing the last item, right? The last item in that array. And so if we have a contiguous number array that's already sorted, one, two, three, four, five is contiguous, it's sorted. we can just grab this five and if we grab the five, we can calculate the sum using Gauss's trick here. Now, this is two steps, right? Like, all right, we're grabbing the last number out of the array and then we're doing this fancy math trick with it. If we think about how this scales, as I add a million inputs, Inputs, how many steps have I changed to? It doesn't really

03:49:00
matter, right? It's still the same thing. So if we're talking about at a high level, how does our algorithm scale? If we're talking about a high level, how many operations are happening, right? This is still one operation, no matter how many inputs we have. And if you want to code we need out and be like, all right, I'm going to treat this as a step that happens in constant time. And I'm going to treat this as a step that happens in constant time. So it's really, it's really O of two. What the heck does O of two simplify to? Yeah, it still reduces to one and we wind up with O of one or constant time, right? So even if you wanted to code, we know that actually two steps here, right? No, but that's not how we're thinking about. We're thinking about like, all right, total number of operations, right? Right,

03:50:00
total number of operations. And what we're gonna do here is if we're using this Gauss's sum, no matter how many inputs we have, we're still performing at base level one operation. The algorithm is not getting more complex. We're not doing more work as we add more inputs. So this, like I said last time, is what actually blew my brain, right? This is what, as soon as I saw this, I was like, I need to know my data structures. I need to know my algorithms. What else am I missing in this world where I can go from a linear complexity to something in constant time, just by knowing this trick. And that's what the data structures and algorithms will do for you. The more, right, right, right. but the more you

03:51:00
learn in terms of how you're organizing your data and data structures, and the more you learn the different algorithms that can take you from a linear to a constant time complexity, the more efficient code that you can write, and it's literally like unlocking cheat codes, right? It's literally unlocking cheat codes. And so that's why we study these. That's why we're doing our standup every day. It's why I'm giving you so many like tutorials that work through the basics of this stuff. Because if you can have these on your tool belt, you can do really, really cool stuff. Some folks are asking like, how does this work out? Well, let's do a simplified version. Let's go ahead and do one, two, and three. So one, two, and three. If we're doing a linear solution here, we're gonna grab each number and add it to our sum. So we'll grab one and

03:52:00
add it to our sum. So now our sum is one. And we're gonna grab two and add it to our sum. So now we're at three. And we're gonna grab three and add it to our sum. And now we're at six. So when we did it linearly, we had to do three operations to get the sum of six. When we use gauss's sum, we have the same array, one, two, three. We only have to do one operation, which is grabbing that value out of the array, right? And so now once we have that value, if we do three plus one, it gives us four, four divided by two gives us two, two times that three gives us six. So we performed one operation, we got one input, right? We got one input and we were able to get the same exact sum. If my input, my array, if I added a

03:53:00
million, I went up to a million now, so I'm adding almost a million new inputs, right? This is 100 million. But I'm adding, let's say 100 million inputs, right? Does my number of operations change at all with this solution? Can I still get the sum, right? Yeah, it doesn't change, I can still get the sum. Now, I can feel the code weenies just shaking in their boots. they're nerding out about the more complicated math that can be had here. Are there more nuanced ways to talk about this stuff? Are there slightly more mathematical notations that you can add to discuss the problems we're

03:54:00
talking about? Absolutely. But for your first pass, and for what actually matters, right? for what actually matters when you're trying to evaluate the efficiency of the solutions you're writing for your code wars, that doesn't matter, right? So you can, you can stop shaking. It's okay. We understand that you, that you took your, your intro to math class in your computer science classroom like that. That's okay. We don't need it right now. Once we're getting paid real money, we'll go back and learn all that stuff. Wolven said, unclutch thy buttocks. Well actually, all right, let's talk about quadratic. What's

03:55:00
the example of a quadratic complexity that we saw before? Yeah, one of the simplest ones that we've talked about is just nested for loops. Now, not every nested for loop becomes a quadratic problem, but a lot of times they do. We'll see one during stand-up that I've picked out specifically to get you got, because we're gonna get so used to seeing nested for loops and go quadratic, quadratic. But I'm gonna throw one in that's not quadratic, so just as a note there. But here we are checking to see if there are duplicate nums that are not the current num. And so we have an array that goes one, two, one, two, three, four, five, five. And what we are doing, right? What we are

03:56:00
doing is grabbing a number, right? We're looping through on the outside. Our outside for loop is looping through grabbing a number. And then we have an internal for loop that's making sure that we're gonna run through each number again. We're gonna compare one to one, but since that's the same number at the same index, it doesn't count. Then we're going to compare 1 to 2, 1 to 3, 1 to 4, 1 to 5, 1 to 5, and realize that there are no duplicate ones. And then our outside loop runs again. And we do 1, 2, 3, 4, 5, 5, 3, 1, 2, 3, 4, 5, 5, 4, 1, 2, 3, 4, 5, 5, 5, finally runs one, two, three, four, five, finally finds the duplicate and stops, right? So the problem here with a quadratic solution, right?

03:57:00
Right? Right, the problem with the quadratic solution is that if we were just to add one more input, think about how many more operations we actually have to do, right? If we just add one more input, each one of these now has a six in it, right? We added one input and immediately we can see right away, four more operations, right? Almost like completely exponential, right? Like literally adding one input, we have to do all these more operations. And so the quadratic can get pretty sticky pretty quickly because you're adding one input and boom, The number of operations you have to do is going up. And so if we were to think through some of the things that we might want to be wary of introducing into our code base, this might be one of them, right? Whenever we see a quadratic solution, we should probably stop and think,

03:58:00
is there a way, right? Is there a way to do this more efficiently? All right. The last one that we hadn't had a chance to talk about, and I'm just going to talk about at high level. I'm not going to bog you down with like the actual code. So we'll be able to talk about it. It's something called logarithmic. And a way logarithmic works is with a specific algorithm called divide and conquer, is that for each loop that you do, your operations become halved, right? So for each loop you do, your operations become halved. So let's think about, let's think about an array here that goes from one to a million.

03:59:00
Right, goes from one to a million. And I want the number 500,000. If I was to do this linearly, how many operations am I about to perform to get the number 500,000? I'm about to do 500,000 operations. Well, what if I told you there was an algorithm that enables me to crack my array in half and that's the operation. So I take my array going from one to a million and I crack it in half and I look and I see on this side, it went from one to 499,999.

04:00:00
Is 499,999 less than 500,000? Yes, so I throw it away, yeet. And now I can look at my other half and see, Oh, 500,000, I'm there, done. So it went from 500,000 operations when we were doing a linear complexity, right? To two, to two. Let's talk about a different one. Let's talk about 750,000. If we were doing it linearly, And we're yes, we're assuming some things here. It's already sorted. It's continuous. It's going from one to a million, right? Right 750,000 we take our

04:01:00
Array of one to a million we crack it in half is four hundred and ninety nine thousand nine hundred and ninety nine less than 750,000 yes, so what do we do with it that whole set of numbers? What do we do with it? Yeet We take a look at our another half. Other half is half a million to a million. So what do you think we do with this set that's half a million to a million? Crack it in half. We look at the number. All right. 749,999. Is that less than 750,000? It is. Yeet. Put out the window and then boom. So we did how many cracks there? We did one crack for half a million, another crack for 250,000. So we went to two operations. So this logarithmic, right, this logarithmic algorithms can

04:02:00
approach something that is not quite constant time, but it can be really efficient, especially with large amounts of inputs, right? it can be really efficient with large amounts of inputs because we could have a billion inputs and literally in two operations get to the thing that we cared about. Now, let's think about a scenario here. Why does it look like for a small number of inputs? Why does it look like linear complexities could maybe be better? Let's

04:03:00
look at this. We can see logarithmic here is taking more time. linear is taking less time until we get to like more inputs. And I think it's worthwhile to mention that like with a small number of inputs and you'll learn this from the homework that was assigned for this week. With a small number of inputs, you're really not going to be optimizing for efficiency. You should be optimizing for like readability and some other things, right? Because it gets a little wonky with small input sizes. So we just said, Leon, wait, if you had a million inputs and we went to get the 500,000 or 750,000, it was so quick. It was two operations as opposed to all these, all the other ones that we had with a linear complexity. So why with a small number of inputs could linear be better than logarithmic?

04:04:00
Let's think. Let's think. Let's do a small number of inputs, shall we? Let's do a small number of inputs. If we were to do, let's say we wanted to do the number three. Right, or let's make it even bigger. Let's go ahead and say number of one through 10. My pen stopped working. All right. Let's stop at 4.

04:05:00
Let's make it 5. All right. Let's make Make it easier, sorry, my pen stopped working. There we go. All right. Let's say I want the number two. I want the number two. Linearly, how many operations am I going to do? Two, one, two.

04:06:00
Logarithmically, how many operations am I about to do? Right? We're gonna do our first crack. Boom, first crack, right? We see three and four. We yeet out four. We do our next crack, maybe we have one and two, three. So maybe we're at like two operations, but maybe even like that third crack has to happen. So we're already kind of at a similar, right? we're already kind of like at a similar number of operations. What if we were looking for the number two inside that

04:07:00
original array of a million. If I'm doing it linearly, how many operations am I taking to get to that two? Linearly, I'm still doing one, two operations. Boom. I got the number I cared about, but if I'm doing it logarithmically. All right, boom. Crack a million to half a million. Crack that half a million to 250,000. Crack that 250,000 into 125. Crack that 125 in the 75. Crack that 75 into, right? Think about all those cracks we have to do to get to that number two. Right? And so there are some cases right there are some cases where when you're just thinking about rough estimates right rough estimates if you focused on like the raw

04:08:00
math you would see some weird stuff with low input sizes but when we are trying to figure this stuff out do we care about like the raw math. Do we care about the raw compute speed? Do we care about the raw numbers? No. We are doing it. I thought that was on the other slide. Sorry. We are doing it to get roughest estimates, to figure out how our complexity scales, to figure out the worst case scenario. So when we are looking at low amounts of inputs, things can get a little weird, right? Things can get a little weird. We can be like, hmm, maybe linearly could be a little bit better in this scenario, but we're talking about rough estimates. We're talking about worst

04:09:00
case scenarios. We're talking about how things scale. And so we keep that in mind as we're evaluating the complexity of our applications. It's important to commit these to memory. The quadratic, the linear, the logarithmic, the constant. Those are the ones we start off with. Are there more? Yes. Right? There are more. Dev ethos A. Thank you for the hydration. Cheers to you. Right? Memories are important because it's going to help you talk about your solutions as you are, right? As we are going through our interviews, as we are working with other engineers, it's

04:10:00
important to be able to identify something that might be quadratic. It's important to be able to identify, oh, this might be happening linearly. Oh, this is important to see that, oh, this might be happening logarithmically. And no, this might be happening in constant time, right? And so it's not that we're worrying about the day-to-day raw math, the day-to-day exact details. It's about being able to take like a high level approach to what's happening in your code. And so part of what we're doing during stand-ups is doing that. We're looking at the code that we write each day, we're like, all right, I think this is actually happening linearly, or I think this is happening quadratically, I think this is happening logarithmically, and seeing those examples come to life. But you can start doing this with your code challenges every day. As you're doing your code wars, as you're doing your elite codes, you should be asking yourself, is this the most efficient? How efficiently am I solving this? Is there any way to get this to go from a quadratic to a linear? Is there any way to get this to go from a linear

04:11:00
to constant time? And as you do the tutorials that I assigned for homework, as you keep pushing, I'll keep gonna give you, I'm gonna give you a third one as well. So we start off with the Scotch IO, and we're moving on to the older front-end masters, and then we'll move on to Prime's newer front-end masters. By the time you make it through those three tutorials, you'll have enough data structures and algorithms in your tool belt that for pretty much whatever you run into, you should be okay. You combine that with our daily standups where you have lots of practice, you'll be golden. But all of this is just the what? The sprinkles, the cherry on top, exactly the extra. Do you need to super focus on this? No,

04:12:00
knowing the basics here is enough to honestly impress quite a few interviewers. and for some interviews that want you to go super deep into big O and they want you to give you like a super more optimized solution, that's just one of your 60 and you keep it moving. Cool. Alright, I have a problem. A big problem. The problem is that the price of boxes is too damn high. I have a thing, you know, my thing is Pokemon. Been doing this for a long time.

04:13:00
Pokemon blue, complete in box, first edition, not only first edition, but first edition misprint, misprint, collect up to 139 different Pokemon playing the red version. This is the blue version folks, but it says red version on the back. Not only is it first edition, it's first edition misprint. first edition first edition

04:14:00
first edition or first print whatever you want to call it The first print, ugh. The holy grail, sealed in box, ugh. Sealed ugh. And then the graded stuff started happening. Oh my gosh, oh So Here's the problem The problem is Can't stop buying boxes and and The cost of boxes

04:15:00
are too damn high you go and look at boxes right now you go on eBay These stuff like this Right Pokemon blue Factory sealed VGA 85 plus sold for 7k right sold for 7k but you go on eBay you go on eBay and somebody's offering a VGA 80 of inferior quality for 30K. So I'm too big, sorry, I didn't go back to little Leon. Right,

04:16:00
we look VGA 85 plus sold, like actually sold 7K. Then somebody same timeframe or an inferior version wants 30K. So not only are the price of boxes way too high, the prices are all over the place. It's just ridiculous, right? And so the real purchasing, right? The real purchasing doesn't go down on eBay. That's where you get got. It really goes down in like Facebook groups. It goes down in like these other marketplaces that aren't eBay. and it's really hard to keep track of stuff. So what I wanna do is I wanna build a platform, right? I wanna build a platform where

04:17:00
folks can list their boxes for sale, right? And list their boxes for sale. And I wanna be able to have some quality of life features for myself where when I create this bidding platform, uh, you can, you can find how quickly, like the max and min bids are. Uh, we can see if those bids are reasonable, compare them to past bids, like I want to build a nice, reasonable bidding platform or where people really buy boxes. Right. All right, now, I want to build this platform and we were like, Leon, you're flexing. I'm not flexing, I wanted to flex. Show you this. This is learning, see, this

04:18:00
is a flex. and if you know you know this is a flex now what's on here is a backup of a cartridge that i still have working by the way that's sealed and locked away this is my backup and on this backup up is the dump of my Pokemon blue. And on this dump of my Pokemon blue is a gen one mu with certificate of authenticity from the 1999 Pokemon trainer tour. See now that's what I would have brought out because if you collect Pokemon and you're going for a full dex, you

04:19:00
ain't got this. Now the real flex is I don't have just one now. I have two with letters of authenticity with working cartridges and that's all we'll say back to our regular schedule programming okay now problem is boxes are too expensive. Right. I actually didn't buy that Mew. The, the, the second Mew I traded, uh, I, I trade most, like I don't buy any of this stuff. I trade for it. Like I, like this is, this was like my hobby for a long time. I would go to swap meets. I would go to gaming conventions. I would bring cash,

04:20:00
buy at severe discounts, resell, use the money I made to like buy what I wanted to buy and I started getting into this way before the prices went up. Um, now to get the second meal, just cause we're here. Uh, well, the way I did it is I have a bunch of, when you used to go to, when you used to go to like GameStop, you would get the event Pokemon, well, those event Pokemon are actually on cartridges that you put into like the different game boys or three DSs and stuff like that, uh, they weren't meant to be resold, but I have, I have, I have, I don't want to say all of them. I've pretty much all of them though. I'm pretty close to having all of them. And so I traded a bunch of those like event exclusive cartridges for the Mew. It's probably the best trade I've ever, ever did. Is he still talking about this? Yeah. Get timed out. You don't know, you don't have to worry about talking about anything. This

04:21:00
is important to me. Alright, so prices of boxes are too damn high Right. This is this is one of my my my supreme hobbies It's what I spend a lot of my time on boxes are too high. The real bidding is going down in Right. The real bidding is going down in Other platforms that are not centralized and so I want to build a bidding platform where I can really easily take a look and see if there is the the min bid and a max bid on every box that has ever been sold. I want to see the the full range of bids on all the boxes that are being sold. Now I could find let's say the min and max bids by looping through all the bids that have been made all the bids that have been made on a

04:22:00
particular box. So let's say I pull in all the bids for every Pokemon Blue that has ever been listed on the platform. I have all these bids that are all over the place, two, seven, three, one, four, five, five. How could I find the min and max bids? Well, I could loop through all the bids, I could loop through all the bids and then compare the current bid to the bid that I am currently in with the internal loop. So if I had this array up here, two, seven, three, one, four, five, right? I could grab the two and then compare it to two, seven, three, four, five,

04:23:00
continue to start building all of these bids, right? Inside that internal loop, not only am I only comparing the numbers, but I'm saying, hey, is the bid that I am currently on greater than the current max bid? So is two greater than seven? Nah, we would skip this. Is eventually seven greater than two? Then yeah, that should be a candidate for max bid. Is four greater than seven? No. Is five greater than seven? no, is five greater seven, no. So then we would have our max bid that was set inside this loop. We could also be setting our min bid

04:24:00
inside this loop as well. We do two compared to two, nothing happens. Is two less than seven? No, so nothing happens. Is two less than three? No, so nothing happens. Is one less than two? Yes, so then our min bid becomes one. So I could have a loop on the outside that's looping through all the numbers and then a loop on the inside that's grabbing each number and comparing it to the number that we are currently at. And we're setting our max and min bids. Would this work? It would work. but would it be efficient? Yes, but at what cost? The cost of time, exactly.

04:25:00
It would cost a lot of time. This is really bad code. This is us being baddies, brute forcing it. It works. We found the max and the min, right? We brute forced it, we came up with a solution, but at what cost? What would be the complexity of this solution? Nested for loops. Yep. Nested for loops. We're talking about quadratic complexity. Now, if I'm building a bidding platform. Right. And the platform becomes popular. We have a lot of people in chat here that were very, very interested in the Pokemon conversation I just had. Lots of potential customers for this new bidding platform, especially as you all start to get these amazing jobs and realizing that all the money that you're making should be funneled into boxes, right?

04:26:00
Lots of folks might be using this platform. The more people that are on the platform, the more bids, The more bids means what in this scenario if we still have a quadratic solution? MLM incoming. This has all been about getting you all to buy more boxes. Yeah, it means more bids as we increase the bids. Oh shit, way more operations are happening. this would be the crux of our bidding platform. This would make our platform work at first with just us. But as it started to take off and it became a more popular platform, this loop would take more and more time. It would get

04:27:00
harder and harder. It would become something that could slow down on our application significantly. So this is a real thing that we have to think through even if it was just a simple, silly application like a boxes bidding platform, right? So how can we not be baddies and write inefficient quadratic code? What would be some way of fixing our bidding platform, right, fixing our bidding platform so that it didn't take as much time or as many operations. Well, let me show you something first. What if one loop found the min

04:28:00
and the other loop found the max. Let's take a look. So here's a loop, here's a for loop, and all this for loop is doing is moving through each number and comparing if that number is greater than the max bid. So what happens at first is max bid is set equal to the first number in the array. So max bid starts off as one. Then we loop through and say, hey, is two greater than one? Since two is greater than one, what does max bid become? Max bid becomes two. All right. Is seven greater than two? Yes,

04:29:00
since seven is greater than two, what does max bid become? Well, it becomes seven. And we do the same thing for three, four, five, five. None of them are greater than the seven. So we return our max bid of seven. What type of complexity was this loop? It was linear, right? As we added more numbers, we simply added one operation for each item. Now, the cool thing is I could just do this again with another loop that does the same thing for a minimum bid, but instead of it being greater than, we're looking for less than, right? Now, I'm not nesting them. it's just one loop that runs, right?

04:30:00
It's one loop that runs for the max bid, and then a completely separate loop that runs for the min bid. Now, what's the complexity of the max loop? And what's the complexity of the min loop? They're two separate loops. What's the complexity of each? Yeah, they are both linear. and since they are both linear, we wind up with something that's 2n, right? We wind up with something that's 2n. And since it is 2n, right? What does this reduce down into? We have two linear loops, right? We have two linear loops, right? We could think about this, right? As even though we have two linear loops, they don't rely on each other, right? Doesn't care what one loop is doing with the other loop. We can still

04:31:00
think of it as O of N, right? Right? They don't rely on one another. They're just separate linear loops. We don't have to think about them as anything that would be quadratic and think about anything else. It's just two linear loops doing their own thing. So when we have two linear loops that are doing their own thing, it still boils down to a linear complexity, right? So we went from something that was nested and bad and quadratic to just thinking about, wait a minute, why do we have to like nest these things? Why can't I just have them run separately? And just with that one decision, you've turned a quadratic problem into a linear problem. Cool, so our box bidding app, right?

04:32:00
The box bidding app is now back online. What would have taken us forever to calculate min and max bids, right? We're now back online, we have a linear solution to our problem. Now, some folks are kind of a little confused on how this is going to work. This, we agree, is linear. Right? It's just one input for one operation. So this loop runs once for each input in our array. As we add more inputs, we are linearly adding operations. All right, so as the number of inputs increases, we are still only adding one operation for each input. Now,

04:33:00
the cool thing is we have a separate loop that is doing, or a separate, even in this case, function that is handling the max bid, and then we're gonna have a completely separate one that is doing the min bid. And since this loop here is linear, and this completely separate loop that does not rely on the other one is linear, how many linear loops do we have? We have two linear loops. And when we are trying to get the rough estimation of how much time this would take, we can reduce this two linear loops down into just a linear time complexity. Now,

04:34:00
this is not a direct corollary to what we just talked about, but let's say we had two libraries. We had one library and we wanted to count each book in our library. We wanted to start with the first book and go all the way to the end to grab the last book. Each book, we did one extra count. We went one to two to three to four. If we go through our whole library, what was the complexity of moving through our entire library to count the books. It was linear, right? It was linear.

04:35:00
Now, if. If I was going to say, if, if Bezos came along and says, Hey, Leon, I want to give be a whole other library, but I need you to count the books. I have this whole other library. When I started the first book and go to the end, how is that complexity? What is that complexity? It's still linear, right? So does it matter that they were separate libraries? It's still the same process. this is still linear. I'm still just doing one operation for each input. I just happened to do it two separate instances, right? And so it's the same thing with this code here. We're just doing something twice, but since they're both linear, nothing changes. They were two separate libraries.

04:36:00
They were two separate instances. We wouldn't like magically say, oh, because there are now two libraries, something has changed. No, we did linear and we did linear. So it's still linear even though we now have more books. It could be the same thing as saying We just have more input. It's still linear at the end of the day Cool Now what if our data was already sorted it. What if our data was already sorted? Like, what if all of our bids, like our min and max bids, like what, like we have a bid coming in, right? We have all these bids coming in over time, I still want the min and max bid. What would that be? Yeah, that's constant,

04:37:00
right? Accessing an element out of the array happens in constant time. Now, you might say, Leon, but I'm taking two things out of that array. But what we could realize is that, all right, it's two things that are happening, but if we think about it at a high level and we separated out those plucks, right? We have our bids that are going from one to, let's say that the most expensive bid was 100,000, right? I had this array of bids that went from one to 100,000. Does it matter if the bids keep going up to be something else? Will it always still be the same number of plucks to get the min and the max? Like no matter how many bids we add, no matter how many inputs we add into this array, to get

04:38:00
the min and the max, they'll always be the same constant number of operations. So even though it's two things that we're doing, we can treat them as two independent events that are both constant, right? There are two constant things that are happening. You could say that was O2, but then we could reduce that down to O of one or constant time, right? Grabbing the first index would always be index zero. And then grabbing the last index would always be the array dot length minus one. Wait a minute. Hold on. Hold on. Leon, you said accessing it by the zero, we get that. That's always gonna

04:39:00
grab you the, that's always gonna go ahead and grab you the first element out of the array. That's clearly constant time. Right, but then you say to get the last element in the array, you need to do the array dot length Minus one well leon How fast or what is the complexity of dot length What can we tell about dot, if we know that this reduces down to constant, what can we tell about dot length? Dot length is probably happening in constant time too. And let's think about it. What is an array really underneath the hood when it comes to JavaScript? It's an object.

04:40:00
And that means that length is really a what on that object. Length is actually a property on that object. Remember how I said data structures aren't just the data, it's all the stuff that comes and helps us organize that data. So arrays are really an object that has a length property. And as we are adding inputs, that length property is going up. So it goes from when it's just one element in the array, it goes from one, when there's two elements in the array, it goes to two. And as we're adding elements to the array, we're actually updating this length property in real time.

04:41:00
And then accessing the property of an object happens in what type of complexity? Constant. Someone said, does JavaScript have to count the length somehow? No, if it had to. If our arrays had to calculate length, right? If when we did array.length, if it had to go through and do, all right, one, two, three, four, five, if it actually had to do like that looping each time for length, then it would be what? It would be linear, but we know that arrays

04:42:00
are really just objects underneath the hood. I've just told you now that this length property is a property on that object. And so each time we add something to the array, this length property has already been updated to be five. So when we go to access the length, we're not like looping through the array to figure out how many things there are. it's already a property of the array that we get access to. And since accessing the property of an object is happening in constant time, we have array.length minus one inside of something that's accessing the array. So this is constant. This is happening in constant, right? So even though we have like all these constant times, And yes, there's a couple different constants. They all reduce down to constant. Because

04:43:00
we're not doing math. We're doing high level, rough estimations of what's happening in our code, right? So if you sit here and you try to like, all right, one plus two plus three, no, no, no. You're missing the mountain here, right? You're missing the mountain here. It's that even though there's a couple things happening here, it's still constant because as we add way more inputs, the operations don't ever increase. It's still gonna be the same thing no matter how many inputs we have. Cool. All right, we're gonna squeak this out. Give me a few more minutes. I know we're at the top of the hour for a break, but let's do a quick five minute break. Five minute break and then we'll come back

04:44:00
and we'll finish this up. I do wanna end a little early just so folks can start working on the homework. Let's go ahead and take a five minute break. When we come back, we're gonna just quickly reiterate the different examples that we've seen so far. and we're gonna look at some JavaScript and see what JavaScript is really doing underneath the hood and what things are happening in constant time, what things are happening in linear time. And it's just as surprising to me as when I start to really think about, all right, dot length is a property, properties are accessed in constant time. So when we get the length of something, we're not actually going one, two, three, four, the length has always been there. Beautiful. All right, five minutes on the clock. If you're able to, please get up, move around, hydrate. And we'll be back together shortly. Let's take a look at, well, I want you all to give me, what's an example of something happening in constant time?

04:45:00
Ah, yeah, access to an array. When we use the index of an array, that's happening in constant time. Beautiful. What's something that happens in linear time? Yep, loops, like looping through an array, right? Or maybe we're adding all the numbers in the array together, that would be linear. How about something that happens in quadratic time? Yep, nested loops can be an example of quadratic time. And what's an example of logarithmic time? Anybody remember what I called that? Also in the slides, but what's a, what's an example of an algorithm that runs in logarithmic time? People are throwing out binary search. Okay, I see y'all. Yeah, any type of divide

04:46:00
and conquer algorithm, and things like that. Cool. And let's just take a look very quickly. Give me like another couple of minutes and then we'll end for the evening. Actually gonna end early this time, which is amazing. Let's take a look at some things that are actually happening in JavaScript. So a method that we use all the time, or especially as you start doing your code wars would be pop. What does pop do? Yeah, removes the last item from the array. So if we had an array with 1, 2, 3, 4, 5 in it, pop would grab this 5 off of the array. Now, what complexity do you think this is happening in? Yeah, this is constant, right? Underneath the hood, maybe it's just using the array minus array.length, right?

04:47:00
To grab that last element out of the array. And so grabbing that last element out of the array happens in constant time, so pop happens in constant time. How about shift? What does shift do? Shift, remember, takes the first element off of the array. So what would, if pop is constant, what does shift? And a lot of y'all did the homework. All right, so kind of a you got got. So you would think if pop is constant, why wouldn't shift be constant? We have to think about the data structure at play, which is the array. So if I was to shift off the one, what happens to the two? Well, the two has to become the zeroth

04:48:00
element and the three has to become the first and the four has to become that and that has to become that. not only are you just removing the first element off, but you're literally changing the index of every single element. And so that makes this no longer constant, but what? Linear, exactly, linear, yep. So we could see a pop being constant time, but shift, since it's literally changing the entire array, that's linear. Beautiful. We already talked about length, right? Length is a property that's being set as the array gets bigger. So when our array just has one in it, the length property on that array is one. When we add another element, it becomes two. When we add another element,

04:49:00
it becomes three. and we add another element, it becomes four. When we add another element, it becomes five, right? But it's happening at the same time. So when I go ahead and I try to use dot length, I'm not even looking at all the numbers in the array. I'm looking at this property that has been kept up with as the array got bigger. So since I'm just accessing the property of an object, this is what? Constant, beautiful, constant, yes. We're getting some of this, I love it. All right, now we also have these methods that come baked in with a lot of the stuff we use in JavaScript, and we use things like arrays, and we see them in a couple other places. So we have like these foreach, these maps, these reduce, where they're looping through elements in the array. what would be the complexity

04:50:00
of a foreach, a map or a reduce? Okay, yeah. Well, underneath the hood, they are just a simple loop. So that would be linear. However, however, some of these take in a callback, right? They're higher order functions. They take in a callback and depending on what that callback does, these could no longer be what? They could go from linear to be something else, depending on the callback that you passed in. So we'll actually see that during our standups where we'll use something that off the jump looks linear, but depending on the callback we're passing into it could get us into some other types of complexities. Cool, all right, look at us go. Look at us understanding how pop can be constant, but shift can be linear, understanding the different

04:51:00
complexities of the JavaScript we've been writing all along, able to have a really weird problem where we're saying, all right, we want to create a bidding platform because Leon wants the bidding platform. We're able to think through high level. All right, if we want to get minimax bids, we should stay away from these like nested loops because that'll get us into quadratic. But if we were to separate out the minimax into their own loops, those are both linear and that would reduce down the linear like this is the stuff that we start thinking about. As we progress through the stages of our engineering muscle, right? And so we're adding little sprinkles here so we can get more comfortable with these tools that are nice to have on our tool belt now, the weenie life. Yeah. Now you had the Scotch IO course to work through. I'm asking you to work through this practical algorithms course, which is also a completely free course to go

04:52:00
through. This will be two out of three algorithms courses that I'm asking you to work through. This one is four hours, but expect to take double to triple that amount of time to work through it. I'm going to give you like a week or two, at least like a week or two to get through it, because you're gonna slowly start to see me incorporate it into the standups. And also it's just important for you to get this knowledge underneath your belt. So you got through the Scotch IO, which I know is really helpful for a lot of folks. I'm seeing a lot of your answers have been influenced by that, which is really cool. Now you have this one, which will using, it uses regular JavaScript. So all this stuff you already know and slowly build you up, slowly build you up to having all these different tools and tool belts on your belt. So please this is the core homework. I need you to get through over the next week or so Please do it. It's going to help you and it's going to help you Immensely put these sprinkles on top but your true homework and the reason why we're ending early You have 30 minutes plus

04:53:00
of time left over And what I want you to do Is to take your first step of the hunt if you have not been applying if you have not been reaching out Tonight is the night where you start your hunt. So take the next 30 minutes, find an open job, find somebody to talk at that company, send them an email, send them a cold Lincoln message, do whatever you need to do to get on the radar of somebody at that company, and you're gonna do it tonight. If you need the templates, exclamation point, templates, we come back on Thursday. I'm gonna build out a hit list live. I'm going to show you all the messages I would send so that you can mimic what I'm doing and take your hunt in stride. Hi everybody. No raid tonight because I really do want you to take that first step. No delay. Start today. You are more than ready. You are more than qualified.

04:54:00
You are a phenomenal lean mean software engineering machine. Time to get you a job. Everybody, have a wonderful rest of your evening. I will see you all tomorrow for standup. I will see you all again on Thursday for standup, again for class, Friday for T-Spill, Sunday for our office hours, and we do the whole thing again next week, folks. All right, everybody, have a wonderful rest of your night. Take your first step. Don't just click off and not do anything. Take the step. You deserve it. You owe you. Goodnight, everybody. Peace.