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
#298 - Data Structures and Algorithms 101 (3 patterns you must know for your next interview)
Grab your free interview prep crash course here: https://parsity.io/interview-prep
Whiteboard interviews aren’t broken — most candidates just prepare for them the wrong way. This episode shows why copying Big Tech interview prep is a trap and walks through three algorithm patterns that consistently appear in everyday software interviews. It’s a no-nonsense roadmap for learning just enough DSA to pass interviews without wasting years on theory.
Shameless Plugs
Join Our Christmas Coding Launchpad below to land your first dev role in 2026 👉 www.parsity.io/christmaslaunchpad
🧑💻 Free 5 day email course to go from HTML to AI
🤔 Got a question you want answered on the pod? Drop it here
Apply for 1 of 12 spots at Parsity - Learn to build complex software, work with LLMs and launch your career.
AI Bootcamp (NEW) - for software developers who want to be the expert on their team when it comes to integrating AI into web applications.
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. Whiteboard interviews are biased, ridiculous, and they don't represent the kind of problems that you're actually going to solve as a software developer. I used to say stuff like this, and it was pure cope. Now, I want to be really clear here. That can be true, but what's also true is your next interview may likely involve data structures and algorithms or DSA. The problem though is most of you are studying this in the absolutely wrongest way possible, and I know because I was once you. The biggest mistake that I see people making is they're treating their interview like it's Google's interview. Interviews for big tech companies are overly documented and talked about online, but the other 99% of software developer interviews aren't going to necessarily look like that. In fact, there's a handful of algorithms and data structures that you should probably be familiar with that will help you pass the majority of your coding interviews. And I want to go over three of them right now that are good for absolute beginners. We're not going to talk about any fancy math or obscure algorithms. We're going to go over three of the most common examples of data structures and algorithms that you're likely to see in your next tech interview that's not at a massive tech organization. But before we start, what even are data structures and algorithms? I think people get really scared by this term, and me too, honestly, coming from a very non-traditional background, meaning I don't have a computer science degree. This really did hurt me because I tried to avoid data structures and algorithms for the first two or three years of my career. And then I spent a ton of money learning them through interview kickstart. I am not sponsored by them in any way at all. I do think it was a great program. I also think that if you're not going for really large tech organizations, you don't need to prepare for your interview like you are. When people hear data structures and algorithms, they usually think math or guys that died a long time ago that have too many letters in their last name. But really, data structures and algorithms are just a repeatable process for us to solve common problems. I like to use the analogy of cooking. You can think of the data structures as ingredients and algorithms as the recipe. It's just a structured, step-by-step way to achieve a result. Data structures are how we store and organize data, and algorithms describe how we might work with that data. So here's one of the most common approaches to solving problems you're going to see. It's called the frequency counter. An example of this may be determining if two words are actually anagrams. Anagrams are words made of the same letters to make different words. For example, if you had race and care or cat and tat, that's not a word, by the way. But you get what I'm trying to say here, right? The way you recognize you need to use this approach or this pattern is when you get asked to count the number of times something appears. So if you're counting letters or you're comparing two collections or you're matching quantities, think frequency counter. Now it doesn't really matter if you're using Python, Java, JavaScript, TypeScript, whatever. These patterns are language agnostic, meaning they don't care about the language. Now the way you implement them obviously will be different. And now the easiest language I can think of to do these is probably going to be JavaScript, right? So a frequency counter could be something as simple as an object where the key is the thing you are counting and the value is the number of that count. For example, if we were looking at the words race and care, we would see that R has a count of one. We'd see that A has a count of one. We'd see that C has a count of one, and we'd see that E has a count of one. If we did the same thing for care, we'd see the exact same object with the exact same keys and values. We'd see every letter represented once, and we'd see every letter with a count of one. Then we could simply compare the objects and determine whether or not these are anagrams. Now I have challenges for every single problem that I'm going to go through in the show notes. You can grab it, it's a repo full of challenges with unit tests that you will need to make pass so you can understand if you can actually solve these problems. It's yours for free. I used to actually sell this, but I'm giving it away because I think it's a really valuable resource. And honestly, maybe it'll even funnel you into my business for an interview program I'm planning to run in the near future. But hey, there's no sales pitch here at all. Just grab it. I think you're really going to get a kick out of it. Pattern number two is the sliding window pattern. And the common problem that you'll see in an interview is something like this: given an array of numbers, find the largest sum of three consecutive numbers. So if you had like one, two, three, eight, ten, twelve, well, eight, ten, and twelve would be the largest three consecutive numbers in that array. They sum to the highest amount, right? How would you know how to do that? Now, in your mind, you probably think, oh, that's super simple. But with code, this is often a little bit trickier. And there is a common way to approach this called the sliding window. In a way that you can recognize if you need to use this pattern, if you hear the interviewer or you read in the problem and you see something like subarray or a fixed size of elements you need to consider at any given time, like the maximum sum of X numbers in an array or something like that. Now, this problem can generally be solved by just using a for loop. You could start at a for loop at any index of an array and you could calculate the next n amount of numbers or items in that array and say, hey, is that the highest amount? Oh, I'll go to the next one and I'll loop all over again. I'll go to the next one and I'll loop all over again. Now that can certainly work, but it would be really, really inefficient. But you should usually ask yourself this how many operations will I need to do if this array or if this collection, if this data expands? If I, for example, had an array of a million different items, would this work or would this process be so long running that it would essentially make the program unusable? And you should think, is this going to be a viable solution? Is this going to scale well? With an array of a hundred or even a thousand, this might not be a big deal. With an array of 10,000, 100,000, a million items, this can be a very, very big deal. So you need to think, how can I do this efficiently? And the sliding window pattern allows you to do that. So the sliding window essentially works like this. At any given time, you'll see a window or a slice of the array. Now, that slice can be any length at all. And what you might do for finding the largest sum of three consecutive numbers is looking at the first three items in the array. Then you simply slide that window over one. So the last item in that array drops out and you would subtract that from the current sum. A new item enters in and you would add that to the current sum. You can keep doing that and sliding the window over one at a time and then subtracting the last scene one and then adding the new item into the array. This is a very simple way of doing it, which is super efficient. And now the number of operations that you have to do is dramatically reduced from doing a bunch of for loops. Basically, you just update the sum without having to start over a bunch of different times. Again, if it's really hard for you to mentally visualize this, I have this exact problem in the interview prep material that is in the show notes or pinned in the comments of the show. Now, the last pattern I'm going to go over is binary search. This is one of the most common ones you're ever going to see, and it's really not that hard to implement. Binary search comes in handy when you want to look at sorted data. Remember this. Anytime you hear the word sorted or even partially sorted, your brain should go to binary search. Now, binary search is actually pretty intuitive in many ways. Think about this. When you open up a dictionary and you want to find the word kangaroo, would you start at the very beginning of the dictionary and go page by page by page? Maybe if you're a masochist or something like that. But the way that most of us do it is using something that's similar to binary search. We'll likely open up half the dictionary. We'll look at where we land. Maybe we're on L and we say, okay, well, K is actually before L. So now I know I need to look in the other half of the dictionary. I don't have to consider the half that is after L right now because I know it's not going to be there because the dictionary is sorted. If it wasn't sorted, you would have to go page by page by page, and that would be really the only way to find it. But because it is sorted, you don't have to do that. So now instead of doing a thousand operations or a thousand page turns, you could do between one and five, right? If you open it up again and you divide the section between A and L and you land on like F or something like that, you say, okay, well, now I have an even smaller amount of surface area to check for this word that I'm looking for. And you do this a few times and eventually you'll land on the word. It's way more efficient than doing a sequential search. Now, binary search in computer science is just implementing this through code where you'll look at some arbitrary index in an array, for example, and you'll say, Hey, is the number I'm looking for greater or less than that particular number? Well, I'll throw away whatever items are to the left or right of that particular number right there, because that way it decreases the surface area in half every single time. This is a super efficient way of looking through really large data sets and is used under the hood of a lot of programs and databases that you're likely already using. Again, all this stuff is in the interview prep material that is in the show notes. I can't stress that enough because you could listen to me talk about this stuff, even have some cool pictures, whatever, but it's not gonna make sense until you get your hands dirty with it. And for the love of Bob, do not memorize solutions. When you walk into an interview, they're not gonna say, use binary search for this, or you should use a frequency counter. They're just gonna say, here's a problem, the array is partially sorted, or this is a sorted array. How do you propose we solve this? It's up to you to say, I think we're gonna use binary search for this reason. Now that alone can give you some huge brownie points because nowadays in the age of AI, you could probably just implement that really simply by saying, hey, implement binary search on this array. But the fact you knew which algorithm to pull off the shelf means that you know how to solve problems that have been solved a million times over. The whole point of data structures and algorithms is to make you think a little bit less. They actually are sitting there built by geniuses so that we can use them to solve problems that people see need to get solved a whole lot of times. Now, I want to do a couple more episodes on this because I do see that there's a lot of people out there that really get intimidated or freaked out or just don't know how to study this stuff. So I want to go over things like recursion, stacks, cues, breadth first search, depth first search, advanced problem solving, maybe even dynamic programming. Because I think these things are not only interesting, but can give you a lot of confidence as a software developer, even if you never use them in your day-to-day activities or you never see them in an interview. I actually have not seen very many DSA problems in the majority of the interviews I've gone into, but I know that everybody out there has a little bit of a different experience and there's no standardized way to assess software developers. So we just kind of are at the mercy of the market. But you might as well be prepared for whatever life throws at you. I really hope that's helpful. Again, last time, get the freaking thing in the show notes. It's free, it's just for you. I'm not charging you anything. Just take it, take it. Anyway, hope that's helpful. 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 want to work directly with me and my team, go to parsity.io. And if you want more information, feel free to schedule a chat by just clicking the link in the show notes. See you next week.
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
