The Case For Learning Data Structures as a Frontend Engineer
If you’re a Jr. Developer from a non-CS background (maybe you completed a boot camp like myself or maybe you’re self taught) there’s a good chance you have asked yourself something like “Why do I need to learn what a Binary Search Tree is? I just want to design websites!” I definitely had this thought and even rebelled against the idea of learning data structures at first.
But here’s the issue. Once I started applying to full-time jobs or even internships at companies I liked, they all began sending me DSA heavy coding challenges.
So, begrudgingly I began the long painstaking process of learning what the hell a Depth First vs a Breadth First search is, or why you’d ever need to use recursion. But then something weird happened, I began to fall in love with this way of problem solving. The tests were extremely challenging, and strained my critical thinking ability in ways I had never been tested before. I took a bunch of coding challenges, bombed them miserably, studied my ass off, bombed a few more, got frustrated, thought about quitting, and then one day it all started to click.
So now I’m here to make the argument that every single engineer, whether you’re building advanced AI Machine Learning neural networks or just want to make something look pretty using JavaScript and CSS, should challenge themselves to be able to crush these “LeetCode” type algorithm and data structure questions.
Interviews
Let’s start with the reason I began studying DSA (Data Structure & Algorithms).
As I mentioned in my intro, almost every single company that you’ve heard of that hires Software Engineers is going to test you on this stuff at some point. I hear the argument often that “I’ll never need to invert a Binary Tree on the job, why should I have to for an interview!” and it actually has a lot of merit. Very few industries that I know of test their candidates on stuff not directly relevant to the job. However, whether you agree with this or not doesn’t change the fact that it has become the industry standard to test a candidates problem solving ability in this way.
The best way to think about it is as a standardized test. Engineers come from many different shapes and sizes, with all different backgrounds, experiences, and knowledge of coding languages. It would be way too hard to compare hundreds of candidates without a uniform system of measurement to test each one against. Thus, this is the system that has been put in place, and if you want to get these jobs, you have to play by the rules of the game. Think of it similar to an SAT or GRE exam for entrance to your university. You’ll never have to figure out the probability of pulling a red ball out of a jar of mixed color balls in real life, but they analytical ability to do so is probably a good indicator of the type of student you will be.
DSAs work exactly the same way. How will you approach this problem that you have never seen before, and how effective is your solution. Even though this problem may never pop up on the job, lots of unforseen problems will, and your ability to deal with these and come up with effective solutions are what separates the good engineers from the great ones.
Scaling Your Applications
One of the most prominent topics when learning DSA is a topic called Big O Notation which effectively measures how well your code scales. Here’s a great blog on the topic if you’re unfamiliar with Big O.
You may be thinking, I’m just making a small calendar app with a couple of entries a day, why should I care if my data loads in 1 millisecond or 3?
And to an extent you’d be accurate. But once you have thousands of users on your app one day with not tens of thousands of data entries each. This time to execute is going to grow and grow exponentially slower eventually making the app unusable for all.
So while you’re first starting out, I’d agree the most important thing is making sure you code runs properly, and works without bugs against all edge cases. But making the next leap from a decent engineer into a great one requires that you are able to write code that is optimized to scale and handle massive inputs. The best way to do this is by learning your data structures and your sorting algorithms in order to apply them to real world situations down the line.
Becoming ‘Full Stack’ is A Necessity These Days
Back in the day there was much more separation between backend and frontend development, but with the advancement of many of these frameworks, the lines between the two have become blurred.
Almost every website/web app now is just rendering data on the frontend but storing and pulling all of that info from the backend. Therefore, it’s important to effectively store and send these data to the frontend so that it can be rendered efficiently. As these apps become more and more complex, more and more data needs to be send, and an inefficient model now, could be completely obsolete by next year.
The benefits of learnings to create clean efficient code on your backend, and organizing it into the optimal data structures and algorithms to access the data far outweigh the inconvenience of having to learn and study this stuff in my opinion.
They Are Fun
I know, I know, but hear me out. Getting good at anything requires you to spend a lot of time learning, failing, improving, and failing again before finally making a breakthrough.
Back in the day I used to play a lot of Guitar Hero. I got into it in High School because a lot of my friends used to play it. When I first picked up the guitar shaped controller I completely sucked. I couldn’t even pass the simplest song and had to keep looking at which color corresponded to which finger. Then, timing the stroke and trying to hit a multiple note chord was the next challenge. I honestly didn’t have any fun playing the game for several weeks until I finally started to be able to beat the songs on ‘Easy’. From there, the jump from ‘Easy’ to ‘Medium’ came much quicker. The jumps from ‘Medium’ to ‘Hard’ and then to ‘Very Hard’ came even quicker than each of the previous. Finally, I was having a lot a fun playing and was able to easily beat all of my friends (I even briefly jumped into the Top 10 nationally in Guitar Hero 3 Online, no big deal).
Why am I telling this story? Partly to brag about a skill I learned and spent a ton of time on that’s not really applicable anymore, but also to say that I hated it at first and it didn’t become fun until I actually became good. And the journey of becoming good was probably the most fun part. That’s how I feel about algorithms on LeetCode.
There are ‘Easy’ LeetCode problems that honestly may seem impossible at first. You can get the right answer and LeetCode can still tell you “Sorry too slow. Try again.” This is beyond frustrating, and can drive anyone insane. But just like all things in life worth doing, it's not easy and practice makes perfect. I promise once you get the Easy ones down, the jump to Medium and then Hard becomes easier and easier. Still, you’re not done once you just pass each test though.
In Guitar Hero, once you just pass the Hard song, there’s still more you can do. Can you 5-star it (meaning you have to hit a certain score on the song)? Can you perfect it and not miss a single note? LeetCode works the same way. You may have passed, but 50% did it even faster than you. How can you make your code even better? The challenge is thrilling and it will certainly make you a better problem solver and engineer
Here is a great list of LeetCode questions to get you started on each topic of DSA (Arrays, Graphs, Dynamic Programming etc).
Also if you haven’t seen the scene I used as the header image of this article. Enjoy!
-Sean
Level Up Coding
Thanks for being a part of our community! Subscribe to our YouTube channel or join the Skilled.dev coding interview course.
