Develop Yourself
To change careers and land your first job as a Software Engineer, you need more than just great software development skills - you need to develop yourself.
Welcome to the podcast that helps you develop your skills, your habits, your network and more, all in hopes of becoming a thriving Software Engineer.
Develop Yourself
#249 - Data Structures and Algorithms for Beginners (Replay)
Learning data structures and algorithms (DSA) isn't JUST a smart interview skill, it will boost your confidence as a software engineer, give you a deeper understanding of computer science fundamentals and they can even be fun once you know how to use them.
If you're self teaching or just starting out with code, they can be intimidating.
They don't have to be.
I break down a pretty comprehensive guide here for learning DSA as well as a video on Binary Search Trees (BST)
DSA Study Guide My popular guide to DSA
Video on Binary Search Trees (Source Code included in the comments)
PS. Zubin and I are building stuff for Parsity. What should we build next? Take 15 seconds and tell us here: Quick Survey
Shameless Plugs
🧑💻 Join Parsity - For career changers who want to pivot into software.
✉️ Got a question you want answered on the pod? Drop it here
Zubin's LinkedIn (ex-lawyer, former Googler, Brian-look-a-like)
Welcome to the Develop Yourself podcast, where we teach you everything you need to land your first job as a software developer by learning to develop yourself, your skills, your network and more. I'm Brian, your host. Hey, this episode is a replay of one of the most popular episodes about data structures and algorithms, where we're gonna talk about what is a data structure, what is an algorithm, and a bulletproof study plan to take you from zero into being confident with data structures and algorithms so you can go to interviews or you can get more confident as a developer and learn all the stuff that your bootcamp probably skipped. By the way, tomorrow I'm going to have a special episode called office hours, and if you want to submit a question for office hours, which I'm getting prepared for, please go to the show notes and you'll find not only a DSA study guide but a link to submit your questions, and if you want to leave your name, I'll shout you out on the show. See you tomorrow.
Speaker 1:Every developer wants to know data structures and algorithms, especially bootcamp grads, because that's typically an area where they skip out on, and Parsity doesn't go deep into data structures and algorithms either. We do have courses and materials around that we don't go really, really deep into it, and there's reasons for that. I don't think that most of you out there are going to encounter data structure and algorithm type of problems on the interview circuit, but there's a chance you will. And if you want to go to Google or Netflix or Meta or Apple or a lot of the really top tier tech companies out there, you are going to need to know data structures and algorithms. The real problem is that people are studying them, mostly completely wrong. What they're doing is they're going on a site like LeetCode, which is a huge collection of data structure and algorithm type questions. You can choose the language and you can do these problems, and then they get on there, they get frustrated or they get really intimidated. They're like I don't even know how to start this and they maybe just try to power through like hundreds of lead code problems. At the very worst, they memorize the answers or they memorize how to do them. They get to the interview and they completely bomb it. They don't really understand data structures and algorithms and there's a way, better way to do that, which I'm going to outline for you right now. So, instead of studying 500 lead code problems, this is what I call a bulletproof plan that's going to get you prepared for 90% of the interviews out there that do require data structures and algorithms.
Speaker 1:So, before we even get into that, what is a data structure or an algorithm? Data structure is simply kind of like what it sounds like a way to structure data right. So there are certain types of data structures, ways that we can organize some data using code that help us more easily retrieve values from it. So if you're using JavaScript, you may be really used to the idea of an object which is a data structure. It's a structure full of data. You have keys and you have values. Right, you have an object with keys and values, one of the most basic common structures in JavaScript you can use. There's also maps. There's also sets. You should look those up as well. Those have been introduced in the last few years and they become really standard to use now.
Speaker 1:Now there are other data structures which you may not come into contact with explicitly in the course of writing code. There's things like binary search trees. There's things like linked lists. Maybe you're familiar with stacks and queues. So in JavaScript, a stack or a queue is simply like a collection of items in an array. Now how you use the array would be different depending on whether it's a stack or a queue.
Speaker 1:What I'm trying to get at here is that there are data structures that you're using all the time, whether it's a stack or a queue. What I'm trying to get at here is that there are data structures that you're using all the time, whether it's in the software that you're using. For example, if you're using a SQL database, you're leveraging binary trees. If you are using the search bar on a website, you're likely using some form of a tree there as well. Some data structures come up a lot more than others, and there's not that many to study really. There's binary search trees, there's linked lists, there's stacks, there's queues, there's heaps. If you learn a few of these collections and structures, you're going to know how to approach the majority of problems out there.
Speaker 1:And as far as algorithms, that's the word that gets tossed around so casually nowadays People say if their YouTube channel is not doing, oh, it's the algorithm. Oh, my podcast is doing that, oh, it's the algorithm. What is the algorithm? What does that mean? An algorithm is simply a step-by-step instruction that tells you how to do a certain task. There are algorithms for sorting data, for searching data. There are algorithms for looking for the shortest path between two distances in a graph.
Speaker 1:There are really famous algorithms, which are just a set of instructions on how to do something, a repeatable way to achieve a goal. Right, you want to get to a solution and you think, well, there's a bunch of ways you could do it. Right, it's not the only way to do it. Like, if you want to bake some cookies, you could use your grandma's recipe. You could use your recipe, you could look up one online. That's kind of like an algorithm. It's a set of instructions that you're going to use. Is it the only way to do it? No, are there better ways to do it than others? Yeah, is it better to use chocolate chips instead of raisins? Well, obviously you know. So algorithms are simply a set of instructions.
Speaker 1:There are some that have stood the test of time. There actually haven't been a lot of algorithms that are brand new. Most have been written between the 60s, 70s and 80s, I believe. So a lot of the algorithms that you're learning are just algorithms that older dudes, women from the older computer science days made up, and now you're leveraging them to do tricky stuff. So now that we have a basic understanding of what algorithms and data structures are and why you hopefully aren't too scared of them.
Speaker 1:Here's some other reasons why you should learn them outside of just passing interviews or whatever. You're going to be a better problem solver because you're going to get exposed to repeatable ways of solving problems. You're going to get exposed to fundamental computer science concepts which are often lacking. If you went to a bootcamp I self-taught, also went to a boot camp, also went to several other boot camps. After I got hired to learn more computer science stuff I realized that was going to be a major gap in my knowledge and I wanted to be more confident and understand what other engineers on my team were talking about. And I noticed the higher levels that I got to, the more it was important that I understood some of these fundamental computer science concepts, algorithms and data structures at some level. The confidence that you get from this is really important as a software engineer, especially coming from a non-traditional background. Maybe you're a career changer. Having the confidence to you feel, hey, you know what I do, know what I'm talking about that's really, really powerful for you.
Speaker 1:Now, unfortunately, what most people do is they go on LeetCode. They don't do what I'm about to tell you. What they do is they go on LeetCode. They do a bunch of random problems and then they come out on the other end. You know kind of better, like it's not bad that they did that, but they didn't really get the benefit of it, did they? It's kind of like going to the gym with no plan, throwing some random weights around and then expecting to get really really buff, not going to work. So let's break down how you should study and in order, what you should learn. I'm going to break it down step by freaking, step.
Speaker 1:I did this exact same pattern to get rounds at Google, facebook, amazon and Coinbase. I didn't make it at any of these places, by the way, but I got to the final rounds at Google and Facebook, which I felt pretty good about. I mean, this is coming from a person that knew zero about data structures and algorithms to actually passing the phone screens, getting on site and then doing well enough on site that I actually closed to an offer at Google. It felt really really close, but I got ultimately turned down by the committee. So I did actually technically pass the challenges, but the committee saw my application and they decided to rescind or reject my application. That's a whole other story. Anyway, I was very happy that I even got that far. I'm just blown away that I got to the final rounds at two of the biggest companies in the world, and from not knowing anything, and it wasn't like I was really into these companies. I wasn't like some Google or Meta fanboy, I just thought it was cool to do so.
Speaker 1:Hopefully this will help you out as well. I spent about $10,000 learning this stuff. By the way, too, do I think it was a waste of money? Absolutely not. I think it was one of the best investments I've ever made, and this was after I was already employed as a software engineer. This helped me tremendously in my career and gave me a ton of confidence. Let's get down to it. So here's what you should study in order Big O notation.
Speaker 1:Big O notation is essentially the runtime complexity of an algorithm. You can think of something like a for loop. How long would it take this for loop to run under the worst circumstances? So you think, if I had 10 items in a for loop, how long would it take to run it? And you express that runtime as in big O notation. So you'd say this would take an order of n operations. So let's say there's 100 items. This would take an order of 100 times to run. A for loop would be run every single time over that array of 100 items.
Speaker 1:What you can do to learn it is go to free code camp big O notation why it matters. Or go to digital oceanodeCamp Big O Notation why it Matters. Or go to DigitalOceanTutorials. And they have JS Big O Notation. It's a JavaScript one. How do you study this? You write the Big O next to every problem you solve.
Speaker 1:If you start thinking in terms of Big O Notation, it's gonna help you understand the time complexity of the algorithms which you write, because writing code that works isn't enough. When we write code professionally, it will have to work at scale. Often At scale doesn't mean a billion users. At scale could mean you know a hundred users. Sometimes you write code that works for you on your machine. You need to think wait, what happens if I have a hundred people using this code? What happens if I have a code? What happens if I have 1,000? What happens if I have 100,000? This helps you get a much better understanding of the code you're writing and how it's going to perform in the real world. I have a ton of horror stories based on my ignorance of Big O notation, which led to me writing code that didn't work at all when it got deployed and it was very embarrassing for me. So if you understand a little bit about, well, if I increase the load of use on this particular function, you know what does that mean. If I have five for loops in here and they're all nested underneath each other, is that going to work out if the input increases? Big O notation will help you determine that.
Speaker 1:Next is sorting and searching algorithms. I'd say this could take you a week if you're really aggressive. I'd say this could take you a month if maybe you're not so aggressive. Here are the concepts you need to learn for sorting and searching. Sorting and searching is a really common thing because you're looking at arrays full of data. You're often getting big JSON payloads right. If you're calling an API, you're getting a bunch of JSON back. How do you go through that JSON or an array in a performant way? If you have a massive amount of data? Do you really want to search one thing at a time? Maybe not. So here's some concepts you want to learn Merge, sort, quick sort, bubble sort.
Speaker 1:Even though it is completely ridiculous to use and you'd never use it, you still might want to check it out. If you want to get really advanced, check out whorevslomudocom. Hoare, h-o-a-r-e, lamuto, l-o-m-u-t-o. Partitioning Hoare versus Lamuto. Partitioning Binary search. Also, get the big O space and run times for each of these algorithms. And how do you study this? Create at least two of those sorting and searching algorithms from scratch. I would do merge sort and I would do binary search. Those two come up so often in interviews that it's really important to know those ones. I think those ones are the most common to come up in your interview.
Speaker 1:Next we get into something a little simpler. If you're a JavaScript person stacks and queues you can probably knock this out in maybe a day. Stacks and queues are just different ways of iterating over an array. In many ways Now they're their own data structures and they have specific use cases. But if you think of a stack like a stack of plates, the last plate you put on the top is the first one you'll have to put off. Think of a queue like a group of people lining up. You go one at a time, so the first person in the front is also the first person that gets out of the line.
Speaker 1:These are the two major concepts between them, and if you can create a stack and a queue using an array, add some methods to it so that you can traverse the array either in a stack method or a queue type of method, using last in, first out or first in, first out approach. That's going to be as much as you really need to know, and you'll see some use cases for how to use these as well. So that's really important too, not just study like, okay, what is a stack, what is a queue? Why would you ever use it? Why would you care? Is there a reason you'd want to traverse array from left to right rather than say right to left? I can think of some. Maybe you want to take out the larger items first. Maybe you want to look at the smaller items first. Maybe it was already sorted and now you want to iterate through it in a very certain way. Using a stack or a queue could be a good reason to do that. Solving problems like palindromes also will need you'll need to leverage a stack or a queue. Potentially. There's other ways that you may want to use these and you should look those up as well. Just look up use, chat, gpt, say what are some, you know, basic practical use cases for using a stack or a queue.
Speaker 1:Here's one of the hard ones heaps. Heaps are difficult to create in JavaScript. Other languages have heaps natively included, so in JavaScript one of the issues is that we don't have things like binary search trees, heaps, stacks and queues that are just come out of the box. You have to make your own implementation for those things. So that can be one of the more difficult things about studying algorithms and data structures with JavaScript. You actually have to make these from scratch. Heaps are actually one of the most difficult ones. What I would do here, instead of taking a ton of time to actually make them from scratch, I would probably look up the use cases for them, why you'd want to use a max heap, a min heap or priority queue. Look up reasons for these ones, maybe create a max and min heap from scratch. That's not too hard and if you look at the pattern for how to organize the data, that'll teach you a whole lot about why they might be useful to use.
Speaker 1:Now back to the fun stuff Trees, trees and tries. Tries are a type of tree and it's kind of weird. I've never heard that in real life, never heard anybody say look at that, try over there. No, of course not right. So what are some concepts you need to know with tries and trees, binary trees and binary search trees. Yes, there's a difference. Binary trees and binary search trees are organized in different ways. All binary trees have a similar pattern. They have a node and they have two children that are connected with it. Thus the name binary2, right, you have two choices.
Speaker 1:At each point in the tree you go down one branch and you say now I have two other branches, I can look at which one do I go down now? So when you make trees you can do a few. There's a few ways to traverse them, to iterate over the data within the tree. There's depth first search and there's breadth first search. If you learn those two ways of approaching trees, how to iterate over them, you're going to know about as much as you really need to. And on top of that you might want to learn in order traversal, post order traversal, pre order traversal, and in airy trees.
Speaker 1:Remember we talked about binary trees. What about a trinary tree? What about a tree with four branches? Five, six, seven, eight, nine, 10? You say in as a placeholder for the number of branches. So in airy trees. So the same way you would search a binary tree, it very well could be a way you search a tree with six branches at each point. So you should understand that a tree doesn't have like some limit to how many branches. And if you think about trees, there's a tree that all front-end developers and JavaScript developers interact with a lot and that's the DOM tree, the document object model. So if you're looking at the document object model, that is a tree structure.
Speaker 1:Objects are kind of like a tree structure. So understanding that and knowing how to traverse them and search through them, it's going to be really helpful and there's also some definite practical use cases for it. The same way you can do depth first search or breadth first search in a tree, you could do on an object, because an object has a very similar structure. Lastly, a tri T-R-I-E.
Speaker 1:Now, a tri is a unique type of tree and you may leverage this without knowing it when you're typing into a search box. When you're typing into a search and you type like D-O and it gives you a G as a suggestion, you're like oh yeah, that's right, I was looking for dog. Well, how did it know that there was a bunch of combinations that could have fed you, and in fact it might even feed you a longer combination. You might put D-O and it might G go to heaven, like dog go to heaven, and you might say, huh, how did it know that? That's a try? We can look at a certain set of characters and then from that set it can look at the X number of most popular search items based on your current set of input. So it looks at your input, do, and says, hmm, what do people typically write after that? Why say I have a few choices G, t, maybe dog, dot, don't, o, you know and then it can give you a bunch of different combinations or suggestions based on that.
Speaker 1:That is usually using something called a try. So that is a very practical use case that you will see and you've seen just out there. So how do you study this? Create the binary trees from scratch, create a binary tree, a binary search tree and a try from scratch and then create the methods for sorting and searching these trees and tries. This should take you the longest amount of time and the reason is because these are the most common data structures you're going to come across, not just in interviews but in life as a developer, and then think of some use cases for them. I just gave you some. But when would you use one over the other? When would you use a tree versus a binary tree versus a binary search tree versus a? Try? This is really important too Understanding when and where to use these really really important, because then when you see a problem, you're going to say, oh, you know what that looks like, a problem that would lend itself to a tree. I think this is the hardest thing to study, the one we're going to look at.
Speaker 1:Next, recursion, and I really think you should do recursion after doing search trees, because binary trees, binary search trees, will introduce you to some really basic recursion. But recursion is super difficult. In that class, I was telling you about where I paid like 10,000 bucks to learn data structures and algorithms with people that were really smart. I mean, these were engineers with tons of experience. I must have been one of the least skilled engineers in this whole course.
Speaker 1:Everyone had difficulty with recursion. Everyone, I don't care who they were. People had been working 25 years. People who had, you know, been at Google, at some of the top tech companies you've heard of, everybody had a lot of trouble with recursion. The reason why is recursion is really great for computers. It's really difficult for humans to grasp because what recursion is? It's a function that calls itself from inside that same function. Anyway, it's a doozy. Do not worry if this takes you a long time to get. So I think if you get some of the basics here, that's going to be okay.
Speaker 1:Here's some concepts you need to know with recursion, recursion and backtracking. Backtracking is a different form of recursion, so if you look up those two things, it'll lead you down some interesting rabbit holes. Look up the call stack. How is the call stack used in recursion? Look up stack overflows. You know that site stack overflow. There's a reason why it's called stack overflow and if you find out the reason why and you look up stack overflow plus recursion, you're going to also find some interesting rabbit holes that can lead you down.
Speaker 1:Next is solving problems that require finding combinations and permutations. So combinations versus permutations how do you look at a string or a set of numbers like 1, 2, 3? You think what are all the combinations you can make from 1, 2, 3? You can make 3, numbers like 1, 2, 3, you think what are all the combinations you can make from 1, 2, 3? You can make 3, 2, 1, 2, 1, 3. And permutations would be like well, you can make 1 or 2 or 3, or 1, 2, 3 or 3, 2, 1. So combinations and permutations are the different ways you can organize a set of data. Doing that by not using recursion would be difficult. There are certain ways, certain problems that lend themselves to recursion, combinations, permutations being one, finding all the different possibilities for something. If you ever see a problem that says find all possibilities, you should think, hmm, probably time to use recursion. This is the most difficult concept, so definitely plan to come back to this one a lot. Now we get back to some easy stuff Linked lists you need to learn singly linked lists, doubly linked lists, and what are the benefit of a linked list over a stack or a queue?
Speaker 1:How to study this one. Create an LRU cache at least recently used cache. Look it up. It's an interesting data structure. That's a cache management strategy that is used in a lot of computer systems and a lot of different databases you may be using or in a lot of services you may be using. Basically, how do you keep a cache full of data that is retrieved a whole lot? So, instead of hitting a database, maybe you're looking in this cache, this little in-memory store full of data, and an LRU cache would be.
Speaker 1:Well, you can't just keep stuffing things in the cache, right? Eventually you need to either empty it or take stuff out. And how do you decide what to take out or keep in? You can use an eviction strategy. An LRU is a very common eviction strategy, saying, hey, what is the least recently used thing? Then we can probably just get it out of there. So LRU cache, like least or the last recently used or least recently used cache, and you say what is the least recently used thing? Maybe we get it out of there or maybe we keep things in. Basically, is it the most recently used or is it the whatever? Some strategy for knowing how to get things in and out of our cache and linked lists provide a really good way of leveraging or for LRU cache to leverage.
Speaker 1:Now another fun one graphs. Graphs are all around us. Think about social networks using graphs, linkedin not using linked lists, but LinkedIn finding things on a map, the roadway systems for our streets these are all graphs that we use on a daily basis. You think about Google Maps or any type of map application. That's finding the quickest point from A to Chick-fil-A right Using a graph.
Speaker 1:So you need to study directed versus undirected graphs, adjacency lists, adjacency matrix, and then we'll see depth first search and breadth first search again. That's because graphs share a lot of similarities with trees. They're fairly similar in some ways, and the way you can approach graphs in many ways you could also approach trees. There are some differences, though, especially when it comes to how to organize the data, and using an adjacency matrix, an adjacency list and knowing whether it's a directed versus undirected graph will help you out in knowing how to traverse it, how to get through it, and there are some different ways that you can study this. You can create a graph data structure from scratch, and you can use adjacency or a matrix representation and then traverse both those representations with a DFS or a BFS DFS for depth first search. Bfs for breadth first search, and then you should study. How is DFS different from BFS?
Speaker 1:Here's a problem that Amazon used to love to ask all the time Flood fill problem. Look it up there's a problem called the flood fill problem, and that was a really, really common question that Amazon would ask for a long time. I think they're still very into graphs. So if you're going for the Amazon technical challenge coding round and you're doing the preliminary challenge, you're likely going to get a graph problem. That was the case for years.
Speaker 1:Solve problems where you need to detect loops also. So if you're in a graph, you wouldn't want to keep going back to the same point. Right, when you're in a graph and you're going around and around, you wouldn't want to go to the same point. So you should solve problems where you need to detect loops. Okay, there's some miscellaneous but important things I didn't really cover here because this is already a pretty exhaustive list, but two pointers frequency counters, sliding window and detecting intervals. These are things that don't require like really in-depth algorithmic knowledge, but they come up a lot, and these come up, I think, more outside of FANG companies, outside of the big tech companies, than they do outside of FANG companies outside of the big tech companies than they do otherwise. So how do you study these things? I would look up the concept plus LeetCode and then I'd solve two problems under each concept.
Speaker 1:That's a whole lot to study I gave you, and so if you're not studying solely for these types of interviews, I think you should use something like maybe AlgoExpert or Scrimba or, honestly, just build stuff with like React and Node Express. Do a lot of the same stuff that we do in Parsity. That's going to get you further ahead. These are really important things to study. This is a long list of things and maybe it's overwhelming. I think you can tackle this a little bit at a time. Do what makes sense to you, understand it's a long road and you'll come back to this often, because when you do do interviews I don't care if you went to college and studied this stuff eventually have to refresh your memory, your mind on what you're actually studying and potentially come back to this list.
Speaker 1:I hope that was helpful and there's tons of resources out there to learn this stuff. It's just more important that now that you now are armed with the actual knowledge of what it is to study, rather than just blindly poking around on lead code or just kind of blindly doing some random problems on all these sites, this will give you a very clear path to it, and if you want the path spelled out for you in an article format, just reach out to me and I will include it, by the way, in this episode so you can get it at the link below, but always happy to chat about this kind of stuff as well. Hope that's helpful and I'll see you around. That'll do it for today's episode of the Develop Yourself podcast. If you're serious about switching careers and becoming a software developer and building complex software and wanna work directly with me and my team, go to parsityio. And if you want more information, feel free to schedule a chat by just clicking the.
