Data Structures and Algorithms..oh my!

Hello, my name is Sylvia Favello. I am a self-taught software developer documenting my journey to share with the community what I have, am, or will learn. I hope reading this article will provide some sort of insight for you.

I came up with this topic when I got a chance to do a technical skills interview with a software company. I passed the first round and here I was, elated, excited, ecstatic, etc. I was all of the e's. I felt like a variable getting assigned a value. I had value, it felt validating. I wanted to shout off to the rooftops. I got this!

Until I read the email. I had to do a general coding assessment. Was I prepared? How much and what material do I study? Suddenly the list of things to do began to pile up until it became a mountain. I needed to figure out how to climb it and I didn't even know where to start.

I felt a mixture of emotions that I wasn't prepared to handle and the longer I sat in those emotions, the worse I felt. I had 4 days to learn everything that I could about data structures and algorithms. I knew the basics and I was able to take practice tests along the way. But each practice test that I took, the worse I felt, and the worse I got.

I am not sure what is a worse feeling when you finally get to step into the door of potentially being hired. Knowing you might fail and lose out on an exciting opportunity or knowing that if you do fail, it's going to feel like it's your fault. And it was my fault. I didn't understand how to read and break down the problems nor did I understand how to translate my solution into a suitable program. It was frustrating and overwhelming to realize that I was at the edge of my abilities. Even if I did, by chance, get the tests to pass, my space and time complexity were not optimal. Sometimes I felt like errors scrolled along the code that felt miles deep. I repeatedly kept making inefficient programs. I felt like a bad developer. The imposter syndrome hit me so hard and sudden, I was taken aback. It felt like all the hard work that I had done was beginning to unravel. That's when I had a light bulb moment.

This was a difficult lesson for me to learn, but beneficial nonetheless. Remembering that all setbacks and failures are just moments for you to learn. All of this can help motivate and keep you on your path. That's what I did. I took the defeat and made it into a learning experience. Do I understand data structures and algorithms? Not yet, but I know I will.

After that very long introduction, here is a small breakdown of the very basic of what I have learned. This is just on the topic of what data structures and algorithms are and why it's important to think about them when we are making our programs. This is not an article on how to create or utilize them. That is, for now, above my knowledge. Data structures and algorithms on their own are a heavy and dense topic. It's the Art of War, kind of dense topic, but do not let that deter you away from the subject. I promise once you get a hang of it, it is such a rewarding topic to understand. And from experience, if you're going to be interviewed, you're going to want to know what this topic is about.

Data Structures and Algorithms

Here's an analogy I like to use when I think of the purpose of data structures. You are at a library and you really want to read a particular book. A normal library will have it broken by genre and arranged in alphabetical order. This makes finding your book quick and easy. Now let's say that the same library, two weeks later, has everything disorganized. There is no separation by genre and nothing is in alphabetical order. A cookbook is next to an autobiography and a medieval romance novel is next to a self-help. Trying to find your next read is going to be much more difficult than it was two weeks ago. That's what data structures do.They organize and store the data so that it makes the program run efficiently.

Data Structures four main forms are:

• Linear (lists and arrays)

• Hash (table, maps, trees)

• Tree (binary-search, heap, etc)

• Graphs(directed, acrylic )

Since these are a subject in themselves, I won't go into depth on what exactly they are or what they do. The best thing to take away is that they are the way in which the data is stored. To learn more about them in a digestible way, I highly recommend the website I linked below.

https://www.integralist.co.uk/posts/data-types-and-data-structures/

The hardest part about Data structures is the fact that they're a case by case scenario. Not one particular solution will solve all problems. What may work for one program, might not be the best for another. It really depends on the program and what you want from it to understand what kind of data structure to implement.

This is often where algorithms, time and space complexity comes in. Time complexity is how fast or slow your algorithms runs. For example, if you have a large database of 1 million+ users and you want to find a user based on that data, like twitter, and you created an algorithm that produces a worst case scenario of O(n). That means, after searching 999,999 users, the user you were looking for is that millionth user. That's not a good thing since that means the program had to run 1 million times just to find the user you were looking for.

The best case scenario is if you were to find the user you were looking for right off the bat or the running time of O(1). But an efficient program doesn't run with the idea that it will get its best case scenarios 100% of the time. It would be very bad practice if we try to base our programs on the idea that we will be getting the best case scenario every single time the program runs. More than likely when your program runs, we will be getting average case complexities, but they are harder for us to determine in comparison. Also it's a wise thing to know and think about the worst case scenarios when it comes to our programs so we can fix the problem before they get into our users hands. It is a win-win situation.

If twitter had an algorithm that ran on linear time complexity of O(n), then that's going to be one slow program. Start asking what do we absolutely need and what can we give away? For a faster program, sometimes having more memory allocated towards your program is a possible solution, but that also cost more. Do you or your company have the funds and or budget to allocate that memory necessarily?

I believe it is better practice to start asking ourselves these questions when we are studying these subjects so that we get into the habit of doing this in the future. It's also important to know what kind of questions to ask so that we can write implement that when we begin to write the algorithm to get that desired result.

Algorithms

Algorithms is its own monster to learn, but don't fear the monster. Learn from it.

There are many kinds of algorithms but the main ones are going to be:

- Recursive (Solve the existing case & it's simplest subproblem.)

- Divide and Conquer (Split up your problems and solve one at a time.)

- Dynamic programming (Nostalgic, remembers the past while solving the future.)

- Brute force (Find the solution quickly than optimize it later on.)

- Backtracking ( Almost as if brute force and recursion are merged into one. )

- Greedy (The problem is now and we want the solution now, the outcome and future is not on our mind.)

- Randomized (Solves its problem based on a random input (number it receives .)

To learn more about them I highly recommend following the link below.

https://www.codingninjas.com/blog/2020/06/04/types-of-algorithms-and-its-uses/

Long story short, since I could go forever on this topic, is that algorithms are the directions, the step by step guide for our program to take. Think of the algorithm as the librarian in the book analogy I used earlier. If you're trying to find a book at a library you've never been to this library before, which running time do you think is faster? Asking the librarian or searching aimlessly for it? The librarian is the algorithm and the labels for each book is the data structure. The data? The books of course.

Overall, I hope I helped you in some way. Even though we only scratched the surface, I hope at the very least, I helped you understand their purpose and necessity in studying them. They are difficult to learn but don't give up on them. I promise the knowledge is worth it.

Disclaimer: I apologize for any information I may have gotten wrong, grammar and spelling mistakes, and run on sentences.