126 Does Knowing Data Structures and Algorithms Benefit a C# Developer?

Do I need to know about data structures and algorithms to be a good developer? Do interview questions actually apply to the real world? Do I need to know what a linked list is or how it works? These are the questions we are going to answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:25

Does knowing data structures and algorithms benefit a C developer? Well, that's what we're going to get into in this episode of DevQuestions. And if you have a question, go to suggestions.imtimcorey, ask it there, and hopefully you'll see your question answered on a future episode of DevQuestions. Now, this question did come from a suggestion site, and it's one that is a pretty common one. When you go to an interview for a developer job, you'll often hear about horror stories of having to create a linked list on a whiteboard or creating data structures and binary trees and all the rest in order to prove that you're a real developer. So do data structures and algorithms benefit C sharp developers, or are they just an interview topic? Well, I think the answer is yes. Yes, they do. And no, no, they don't. So let's talk about what were really the heart of the matter here. We're going to start with definitions, because these are big words, data structures and algorithms. What does that actually mean? Let's start with data structures. A data structure is just a way to house data inside your language, inside C sharp, since we're using that as an example. So a data structure could be an array, it could be a list, it could be a dictionary. We've used these, and if you have been inside C sharp for any period of time, you've probably seen most of the things I just mentioned. So they don't have to be really scary. They're just a way to store data. And yes, when you comes to interviews, they don't talk about lists or arrays. They talk about more advanced and edge case type things. We'll get to that. But a data structure itself is just a way of store data or uh hold data to process it inside of C sharp. So what's an algorithm? An algorithm at the very core of it. Now, there's been a lot of things added on to algorithms, but the very core of an algorithm is just a logical way to solve a problem. It's not a necessarily a rule, it's not a even a pattern. Patterns can be algorithms, but algorithms don't have to be patterns. They're just a way to solve a problem. And in software development, that's really all we're faced with is logic problems. We're faced with, okay, I want to do this. How do I make my code do that? Logic. Well, that's you create an algorithm to do that. You create a pattern to do that. And some of these things we have kind of defined into design patterns where we say, okay, we've seen this problem often enough, and we have solved it with an algorithm multiple times. We've looked at those algorithms and said they're all kind of similar because similar problem, similar solution for the most part. And so we've kind of boiled it down to, oh, let's create a design pattern that will kind of encapsulate our thoughts on the best ways to solve a problem like this generically. So I have a generic problem like this. Here is the general idea of how you would solve it. And that's where we kind of mix in design patterns and principles into algorithms. But an algorithm is just a way to solve a problem. And it's it can be unique to your specific situation. So that's what design patterns are, I'm sorry, that's what data structures and algorithms are. That's not really that scary, right? It's just a way to work with data and work with your application and how to work with the logic of your application. And when it comes to evaluating a person's ability to perform the software development role, it kind of makes sense. Do you know how to work with data? And do you know how to work with logic? That makes total sense. And so from that perspective, yes, you should absolutely know data structures and know how to work with and create algorithms. This is where things get off the rails a bit, though. So a lot of things are simple. Okay. And actually with.NET, uh.NET Core even and.NET 6 and beyond, things got even easier when it comes to working with our data structures. Because we've got a lot of great data structures, and really for most cases, the data structure is a pretty common one. We'll use a list or we'll use an I enumerable, but that's a pretty common one to use, and we don't necessarily have to deviate from that standard type. Maybe if we have a certain use case come up, we'll use a dictionary. Or they're all generic and they just work. And maybe we work with an array once in a while, but not often, because we have the generic list. So we don't have to deal with too many decisions on the data structure side, because most of those things are really performance, and it's only in the very, very edge cases where we have to make good decisions about one specific type versus another specific type. I'm not saying you shouldn't know more, but really for a junior developer, a mid-level developer, even up to almost a senior developer, you don't have to worry about it that much. It's only when you get into those really edge cases where you start to think, yeah, maybe I should figure out how to optimize or micro optimize this because I'm doing it 100,000 times. And a micro optimization becomes a macro output value, macro improvement. So we don't normally have to deal with knowing too many data structures. But that's hard to test. It's hard to evaluate. Hey, you know what dictionaries? Yep, good, cool. So is everybody else. So how do I evaluate you? Well, we bring in edge cases where we say, okay, how would you create a linked list? Do you know when the last time I used a linked list was intentionally, like an actual linked list in C sharp? I'm not sure I have. Okay? Because I've done lineup business applications where it wasn't really necessary. And for the most part, list works just great. And iEnnumerable works just great. And the other types that I need do what I need them to do. There is a time and a place for linked lists, and I'll probably cover that in a future video, but I don't use it that often. So why would I need to know that for an interview? How often do you use a linked list in your organization? And that's one of the questions you should probably ask is, okay, first of all, there's a you should learn the five-minute version of the linked list in C sharp and know how it works and know why it works. Sure. And that way when you walk into the interview, you can say, here's how I'd create it. And they say, well, how would you create a whiteboard? Well, how often do you create code on whiteboards? Don't you use an editor and don't you use the built-in C sharp stuff? And really, I haven't used a linked list in, let's say, five years, but Google has the answer. And I could just Google it and implement it once. So they try to, some companies try to kind of get the tricky questions because they think that it gives a better um, they can see a better depth to a software developer. What it really means is you study for the interview. So there's a lot of things like that. The same thing with algorithms. You start getting into, well, do you know how to implement this design pattern? Which again is an algorithm, but it's kind of down the road from algorithms into specific design patterns. And so the question comes up well, should I learn design patterns? Should I learn these algorithms that have been kind of refined and built over time? And as a junior developer, no. No, you shouldn't. As a mid-level developer, yeah. You should start to understand them. And then by the time you're a senior developer, you should know at least what they are and generally how they work, so that if you need to implement one, you can and you can identify that situation when to. Because here's the thing the purpose of a design pattern is to really make something less complex. But design patterns are often very complex themselves. So it's a complex solution to make something less complex than the solution you're putting in. So if you're a junior developer, you're not writing complex code. And if you're a mid-level developer, you're starting to write some complex code. And you may write some, but you might not be writing a ton of it. And when you are, those patterns start to reveal themselves. And that's one of the things that people often miss is design patterns really reveal themselves because again, what's a design pattern? It's just the kind of accumulated knowledge and boiled-down essence of a solution to a given general problem that people create algorithms for. And you can create an algorithm to solve that same general problem and go, oh, that kind of feels like this. And so you kind of take some of the lessons learned from those design patterns and implement them. That's why you should at least know about them at that point. Because design patterns are there to help you. They're designed to bring some institutional knowledge in, some knowledge we can build on top of that help us make better decisions in our code, because we are making decisions based upon the collective knowledge of multiple developers. So it's one of those things where if you're interviewing for a junior-level job, you really shouldn't have to know a ton about edge case data structures, and you really shouldn't have to know a ton about uh design patterns. However, and this is the key here, you're gonna have to in order to get through certain interviews. So what do you do? Well, you learn the basics. Okay? Don't base your career on these things, but learn the basics so you can talk about them, so you can have this discussions about them, but don't decide that in order to become a junior level developer, you need to understand about linked lists, binary trees, and know about the factory pattern in C sharp. You don't need to know all those things. That's too much burden to start out with. But as you grow as a developer, those things will naturally add to your skill level. They will naturally grow your abilities, and they will naturally come into play as you grow in your experience. So they should be an over-the-time thing as far as actually using them. But as far as learning them in order to pass an interview, just learn enough to pass the interview. Okay. So concentrate on C sharp itself. Know enough to pass an interview. That's my encouragement to you, especially as you're starting out. Again, as you grow as a developer, these things become more and more necessary, more and more helpful to you. So you should continue to expand your toolbox. Learn these things, learn how they work, learn when you might want to implement those. And then when situations come up, you can recognize that and you can implement a data structure or a design pattern or another algorithm that helps you write better code. But until you've written enough code to really understand that and really recognize those situations, it's not really gonna help you. And in fact, it's gonna hurt you and discourage you. Okay. So should you learn design pattern, or I'm sorry, uh data structures and algorithms? Not at first, but eventually. And if you need them for the interview, go ahead and learn the high-level knowledge of them. All right. Thanks for asking the question. If you have a question, go to the suggestion site and leave your suggestion for a future episode of DevQuestions. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_01 13:13

Thank you for joining us for this episode of Dev Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Dev Questions. You can also send your questions to questions at IamTimcore.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.