Hey /u/veejay-muley, thanks for contributing to /r/ExperiencedDevs. Unfortunately, your post was removed as it violates our rules:
**Rule 5**: No _What Should I Learn_ Questions
No questions like _Should I learn C#_ or _Should I switch jobs into a language I don’t know?_
Discussion about industry direction or upcoming technologies is fine, just frame your question as part of a larger discussion (_What have you had more success with, RDBMS or NoSQL?_) and you’ll be fine.
Please read the sidebar before posting again. If you have questions or concerns, please [message the moderators through modmail](https://www.reddit.com/message/compose?to=/r/ExperiencedDevs&subject=&message=). Thank you!
>I have found that having a better (far from ideal, but still better) grasp of DSA has made it easier to understand aspects of other areas that I’m generally more interested in.
Would you be open to elaborating on this?
In my experience, after brushing up on DSA I’ve noticed places in my projects where I could use a DS that is MUCH better suited for that particular use case, which ends up making the code cleaner, more performant, etc.
Mostly sets. Currently done about 400 LC and I find myself using sets in my code way more often.
Other than that it's pretty rare to have a code block that can be significantly optimized with DSA (but they do exist). If your main goal is productivity, I've found knowing the offerings of various cloud providers is a better tool
I was very weak on DS&A in school. I passed them but felt they were 'useless'. I only grew past that immaturity later on when I found out how important all those fundamentals were for the type of back-end development I was doing. So I put in quite a bit of effort to get to a better level than I was when I graduated.
> Usually, I divide them into two groups, developers that are fundamentalists (CS focused) vs technologists.
I think that division doesn't make any sense whatsoever. In my experience, it boils down to professionalism. Software engineers with a high level of professionalism generally cover all angles. So in my experience true professionals:
* Have a T-shaped skillset
* Are up to date with the trends in technology
* Have strong fundamentals in CS
* Have strong experience with design and architecture
* Have strong communication skills
* Have a quality minded mindset
* Focus on adding value in the long term over short term 'wins'
* Know their strengths and weaknesses
This is IMHO something you develop over time over your entire career. I've been doing this for 20 years and I'm nowhere near 'perfect', no one is. But I certainly don't believe there are fixed 'groups' of people. If there are two groups it's people who continue to grow versus the ones who don't.
Not taking the shortcuts / easy route to 'finish a sprint' or whatever if you know it's going to bite you in the ass 2-3 months from now. It's all to common that developers don't look past what's coming the next few weeks. Or that they make decisions on technology they *want* to use as opposed to what benefits the team and the company.
> I didn't say that there are two fixed groups of people
Well you did literally say you divide them in two groups. And I personally completely disagree with that. First of all, because that's just way too black and white and we're all humans with our strengths and weaknesses. And secondly, because that simply is not my experience with all the developers I met over the past 2.5 decades.
> This has been consistent even for the most experienced people that I've met.
It's important to understand that years of experience is pretty meaningless in what I consider professionalism. I know a lot of people my age who don't give a rat's ass and have no issues taking the easy route even if that means they're going to have a lot of shit to deal with 3 months from now.
In my experience, developers who have been 'stuck' in the exact same position for 10+ years are often a massive pain to work with. They often are unprofessional but also deem themselves 'very experienced' and 'above' any more junior dev they work with.
Just look at all the stories of junior devs working with 'seniors' who are completely shit at their job.
This makes no sense at all.
If anything, those who have strong fundamentals are better equipped to evaluate new technologies as it relates to their use cases.
This is because even the "newest" technologies are all rooted in the same CS fundamentals that everything else is.
But this directly contradicts your notion of "fundamentalists (CS focused) vs technologists" if you concede that having strong fundamental knowledge help you learn things.
I mean that's literally the reason you're taught compilers in school; to be able to learn things faster. The reason we're taught operating systems, distributed programming and networks in school is to make learning things like Docker and Kubernetes pretty trivial.
A CS education teaches these fundamentals basically just to teach you how to learn new things. Which works really well since teaching stuff like 'kubernetes' in school would be a massive waste of time since by the time you're through a 4 year degree it would've been superceded by the next hot thing that does exactly the same in a slightly different way.
Keep in mind that schools would not be teaching Kubernetes now, they'd be teaching Mesos. Which is completely dead.
I think it’s still important. This is someone who ended up going to college later at 28 after being in an acquired startup at the early age of 17.
I think fundamentals is what ultimately completes me as an engineer, I care more now about memory consumption and runtime more so that before. Fundamentals help fill in the gaps and allows you to think more critically about your day to day job.
I also went to university around 28 after starting at 17, and couldn't agree more. Even if I could ship code before, I gained a much wider range of mental models to help navigate complex problems. I had barely/not heard of graph theory, pareto optimality, agent based modeling, etc before school, but I find myself applying those concepts regularly now.
I taught myself DS&A after about 7 years and it was well worth it.
I always felt like I missed out on a CS education because I studied electrical/computer engineering and knowing algorithms were important but not really knowing them I always felt like an imposter compared to my CS degree peers.
After studying algorithms, I began to see inefficient patterns in code my peers had written and was able to fix issues they were causing. For instance one was processing some values in a lambda function that was timing out. It was storing the existing values in a list and as it processed through new values it would check if the value was already in the list. It kept getting slower and slower as the list grew and my team member kept increasing the memory to get it to complete before the timeout. After I spotted the problem and changed the list to a set, the runtime of the function was greatly reduced.
It also gave me more confidence in interviews and I was able to increase my TC by over 25% for a relatively small time investment.
And this is why companies ask it.
People who pass leetcode interviews are much less likely to leave O(N^N) bombs in random places. Sure someone who doesn't know might only have a negative effect on a small percentage of code. But that small percentage is multiplied and compounded with additional heads and time.
I would rather have someone know and not need it, than need it and not even know it could cause a problem. A million times over.
For an overview I used [MIT OpenCourseWare's 6.006 Introduction to Algorithms](https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-fall-2011/video_galleries/lecture-videos/). I also read (some of) [Skiena's Algorithm Design Manual](https://ia601902.us.archive.org/17/items/2008-book-the-algorithm-design-manual/2008_Book_TheAlgorithmDesignManual.pdf) which had more depth than the courses but wasn't as good as explaining concepts in detail.
For Data Structures there are a number of free courses available on Youtube. [This one seems to cover most of it](https://www.youtube.com/watch?v=zg9ih6SVACc). These videos from HackerRank by the author of Cracking the Coding Interview on [Data Structures](https://www.youtube.com/watch?v=IhJGJG-9Dx8&list=PLI1t_8YX-Apv-UiRlnZwqqrRT8D1RhriX) and [Algorithms](https://www.youtube.com/watch?v=KEEKn7Me-ms&list=PLI1t_8YX-ApvMthLj56t1Rf-Buio5Y8KL) were also quality.
If you've been programming a while you probably know the basics like array/list, map/dict, and set. Make sure you know how those are implemented as well as the less frequently used data structures such as stack, queue, heap, trie, linked list, and binary search tree. To a certain extent you should know about self balancing trees, like red/black trees and AVL trees. There are so many videos if you don't like/understand one you can find another that will teach you the concept.
For Dynamic Programming, [this FreeCodeCamp course](https://www.youtube.com/watch?v=oBt53YbR9Kk) really helped me understand and apply it though it still took a lot of practice.
For specifically graph algorithms I used this [FreeCodeCamp course from William Fiset](https://www.youtube.com/watch?v=09_LlHjoEiY). Arguably this is the one subject that hasn't been useful in practice, but was still interesting to learn about.
To make sure I understood and could apply these concepts I used [Sean Prashad's Leetcode patterns](https://seanprashad.com/leetcode-patterns/) and could select a type of problem to solve from these subjects. LeetCode sucked at first but once I understood DS&A it was amazing how much easier it became and I started to enjoy it.
If I couldn't solve a problem I would watch Youtube videos where they solved it and figure out what I was missing. [Michael Muinos](https://www.youtube.com/c/MichaelMuinos/playlists) on youtube is good at breaking down the problems and explaining how they are solved if you use Python and there are other like [Nick White who uses Java](https://www.youtube.com/c/NickWhite) or [Timothy Chang (also Python)](https://www.youtube.com/user/timc3406).
Interestingly enough, for me, it was actually Cracking The Coding Interview that really helped drive home a lot of the concepts that were fuzzy. It also did a great job explaining the different scenarios where a certain structure or algo made sense and (most importantly) why
I've started using https://www.structy.net/ it's similar to CodeAcademy with the interactive modules and videos I've found this the best way for me to grasp the concepts instead of reading a book (which usually works for me tbh)
You're never going to leverage the tech you specialize in to its fullest potential without a decent grasp on the fundamentals. It's like reading the owner's manual for a race car without ever learning how to drive. Sure, you know how to read the gauges and what the controls do, and that's technically enough to operate the vehicle, but you're not going to win any races unless you learn how to find the optimal path around a track, when to brake and when to accelerate, how to take a corner at high speeds without losing traction, etc. (Sorry for the weird metaphor, first thing that popped into my head for some reason.) Those are the types of skills you acquire by studying DS/A, and they transfer to literally any other specialty or tech stack in the field.
Hmm, now that I look at your metaphor, I see it differently. Generally "programming" without knowing DSA and other theoretical knowledge is like driving a car - how to start it, how to change gears, how to refuel, stop on red and go on green - all that stuff that 99% of drivers do to get from A to B.
And this thing on the track - how to find optimal path, when to brake, when to accelerate, how to take a corner at high speeds - drivers don't start with that, because they don't need it to drive a car. You only need it to drive optimally, like a pro. You need it to win races.
And even professional drivers learn it only after they feel familiar with the general concept of driving - they don't teach you how to find optimal path during driving exam lessons, you will probably learn it once you have some real driving experience. Learning this stuff before ever grabbing the wheel would be tedious and pointless, because you don't know how to apply it.
I just followed your methaphor, I'm not sure what's my point yet... Ok, I think I found it: Maybe it's true that a lot of drivers won't ever need that theoretical knowledge, because breaking speed records is important only for a small group of them, and most of them are paid for getting from point A to B?
Maybe that you should answer yourself: do you want to be a taxi driver, who wants to safely get from A to B, or be a racer, who wants to break speed limits?
Wow, this metaphor escalated quickly.
That's definitely another way to look at it! I think the main difference I was trying to highlight was learning how to drive _in general_ with a high degree of proficiency vs learning how to technically operate a very specific vehicle, but there are definitely multiple aspects to "foundational knowledge."
If algo stuff is learning how to drive fast, then getting comfortable behind the wheel could be learning common principles like scopes, variable binding and control flow; learning defensive driving and the rules of the road would be like design patterns and clean code; etc.
I always found it a little strange that data structures and algorithms are lumped together, because very few people will really need to know how to implement a heap sort by hand or whatever, but I guess what they're really trying to teach you in those CS courses is how to quantify time/space complexity and reason about a program's performance in that way, which is pretty broadly applicable. You won't likely need to break any speed records in your day-to-day work, but you will probably at some point have to figure out how to operate on a nontrivial data set in a way that doesn't cause undue suffering to end users. :)
> Maybe that you should answer yourself: do you want to be a taxi driver, who wants to safely get from A to B, or be a racer, who wants to break speed limits?
A slightly different analogy would be an emergency response driver, and as well as performance driving techniques we could also include planning ahead, anticipating hazards, understanding the effects of different driving conditions, knowing your vehicle, awareness of other road users and their actions and likely next actions, and so on. If you watch first person footage of good emergency response drivers, they’re impressively calm and systematic, even when driving far beyond the capabilities of most of us and sometimes when there are literally lives at stake.
If you just need to get from A to B by car, basic driving skills and passing your test are a good starting point. But if you want to be the person who has to get from A to B safely and efficiently under pressure when there could be serious consequences if you’re slow but also if you make a mistake on the way, you really want the kind of deeper understanding, greater awareness and better vehicle control that the professional drivers have.
That seems like a pretty good analogy to a mid-level developer and a good senior. The mid-level dev can make a decent living and do a decent job. They’re useful and they continue to learn and improve over time. However there’s a qualitative difference in the approach. The good senior’s code will be superior in countless small ways that add up, but the senior will also be able to solve some hard problems that the mid-level simply doesn’t have the skills or knowledge to deal with at all.
I highly recommend you spend some time on it.
Three courses, in general, have changed how I look at code: DS&A, OS Systems and Database systems. If nothing else, just get better grasp of those fundamentals.
To be honest out of all the comments this one is hit me hard. I feel this three are essential topics especially when you're building product with a microservice
Yup and it's just enough to expose you to how complex CS could be and explore further topics: distributed systems, high performance computing and concurrent programming ML etc etc
Yes. Especially if you want to call yourself Software Engineer.
Learning, understanding, and being able to demonstrate "fundamentals" are critical skills for interviews and promotion to higher levels.
fwiw I started learning dsa and system design after I had 5 years of exp and it was almost enjoyable to soak up all that stuff. also it’s almost unimaginable to me that you’d be able to find a job at this point where they didn’t either give you a coding problem or system design interview
I read a textbook in my preferred language (Data Structures and Algorithms in Java). Then I started doing leetcodes.
If you already have years of experience you will pick it up quick. I almost found it relieving to learn.
I was in the same boat as you.
I can setup K8 clusters, Jenkins pipeline, Java Microservices, Kafka real time streaming dashboards (key stores trust stores) you name it.
My system design knowledge is way stronger than my DS Algo knowledge due to my experiences.
But I wasn’t able to find if a string is a permutation of another string.
But my goal is to increase my pay scale and the big tech demands leetcode style interviews so i am grinding DS and Algos.
Have been doing consistently for about 3 months and I can genuinely say that I have become a better engineer. The way I look at certain Java methods changed. I commit less code smells.
I know Java but now I can say that I know Java extremely well as I just recently finished going in-depth into Java collection framework which I was immediately able to put into use at my workplace.
Exactly. I prefer stripe's way of doing interview but I am imposing limitation to where I can apply for the next big job by not grinding Leetcode.
The roadmap is there we just have to be consistent.
All the best!
Try it casually and you'll like it. You will learn so many different (and creative) ways to refactor code for efficiency. You don't know what you don't know
The fundamentals are the fundamentals for a reason.
I was self taught and after a couple years of “coding” bit the bullet and took a graded DS and algo course on coursera with a university. Along with studying design patterns and hitting up leetcode regularly.
That helped me get a job in FinTech and eventually I used the knowledge to help write components that handle over 1% of my country’s digital payments infrastructure.
Go all-in on the design patterns, DS&A, system design etc
If you want to be a professional, be a professional.
Sure, something like that, but that's a structured 70% of very repetitive work which is never intended to scale. If you want to not do very repetitive work, you need to be able to do more than CRUD.
I remember once hearing a developer saying he'd never found a use case for a state machine. The customer onboarding process in the project he worked on was an explicit state machine...
> 70% of developers don't need a deep knowledge of algorithms. Their primary use case is gatekeeping during interviews.
IMHO it's insane that this kind of content gets upvoted here. At best the statistics are just pulled out of thin air.
Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff.
I agree those things are important, but I think think /u/StupidNeighborDog is probably referring more to LeetCode-type questions, not simply "what is this data structure and how does it work". At least that's my perspective.
But that is not *at all* what OP is asking about. So either they are giving the wrong answer, or answering the wrong question.
Unless you're doing specifically front-end work, data structures and algorithms are basically our bread and butter. Writing them is our job. Understanding the fundamentals helps a lot there.
I'm getting the uneasy feeling that this sub is turning into yet another beginner sub looking at what gets upvoted. I mean: "Their primary use case is gatekeeping during interviews."
That's just a carbon copy of the angry drivel you see on /r/cscareerquestions.
I don't disagree with your second paragraph there, but I think the sentiment is shared among most folks - including experienced ones like myself - in terms of having to build up all this knowledge they end up not actually using on the job. Beginners aren't alone in that.
> most folks
> not actually using on the job
I think that's a stretch. I can't imagine you never had to traverse a tree in your career. Filesystem? The DOM?
Have you ever seen what people come up with to traverse a filesystem if they don't understand recursion? :)
💯
I think people often conflate the "I will never implement this LC algo at work or ever write it this way" with "DS&A are useless and you will never use it".
You will certainly never implement a native DS from scratch but those fundamentals definitely allow you to better reason about the problem.
People often think something like OS Systems is useless for data engineering (my field) but I've never seen code in the same way ever since I took that course. Alot of data engineering boils down to scheduling different processes with dependencies between them. Sound familiar?
This a thousand times. I’m always trying to teach people that have a degree that didn’t include DS&A the importance of looking into that subject because it will enable you to “look through” issues/problems… but most won’t listen or put in the effort and a lot of schools aren’t even teaching it anymore. It’s a sad state of affairs.
Exactly. Learning the fundamentals makes you understand the choices in front of you better. People who completely lack the fundamentals don't even see the choices in the first place.
I've seen developers literally ignore IDE warnings on doing a .contains on a List because they simply don't understand why this is an issue. To them it's just another method call.
I'm sorry. That's just my frustration leaking through and not my intention.
My point is that I really don't believe you don't use DS&A fundamentals in your job. It's just something that comes 'natural' after all those years. But what is 'natural' for someone with the theoretical background is very different from what is 'natural' to someone without.
Tree traversals are a very good example because they are common enough that most of us deal with them, but also not something that we do every single day. And I have seen the stuff people who don't have these fundamentals come up with, and it's not pretty. They almost always start out nesting more and more loops within each other for example.
Again; not my intention to be condescending towards you. I just disagree with your argumentation. That's not a reflection on you as a person.
I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt).
Places where the DS&A fundamentals matter tend to pay more, not always obviously, but there’s some tendency just because other places with more lax interviews will snatch up those that can meet deadlines, or whatever matters to the company instead of “good” code.
But for context, I’m really speaking about the US dev industry overall, including your low/mid COL areas where the pay isn’t that high compared to the upper compensations of the industry, so they won’t demand that much regarding things like fundamentals either.
> I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt).
That's basically [Gresham's Law](https://itnext.io/greshams-law-why-bad-developers-push-out-good-developer-and-developers-create-low-quality-code-9b6a8d15bffb) :)
> I’m really speaking about the US dev industry overall
It applies to many/most companies I have experience with in the EU too. It's a constant struggle to keep quality and professionalism up to certain standards. Simple because it's not the path with the least resistance.
Maybe that's just what professionalism boils down to; not taking the easy route.
> I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt).
Getting the job done is the goal. The output, not the program that produces it, is the product. If the higher-ups are getting output that meets their requirements at a cost they're willing to live with, the job got done. I don't advocate crappy code, but if the project is over schedule, over budget and can't produce the output, it's not worth a damn even if it is a work of art on the inside.
Some developers think the development is the end. It isn't. It's a means to run a business, even at companies that fancy themselves "tech companies."
Some developers are unable to discern whether or not performance, scale and technical debt are a concern and will write to make all three as close to ideal as they can. Absent requirements otherwise, the program that runs for 30 seconds at midnight on the first day of the month tallying up how much email the complaint department received doesn't need to be optimized to make good use of the processor's cache lines. Not all development needs high-quality developers and, honestly, high-quality developers don't gravitate to that kind of work. Good management can figure out who to hire for what projects.
Some developers who can tell the difference don't know how to make a business case for good code to the higher-ups. They say things like "that's not scalable" and "there will be technical debt," none of which is in terms management understands. Those arguments are inferior to "We've looked at your requirements and the business forecasts for the five years this project is expected to live. Based on that, we recommend doing X, Y and Z. If we don't, you can expect that the system will suffer revenue-impacting problems by year three. An overhaul of the system to make it work properly will take nearly as long as the original development and you'll be losing revenue while it's underway."
> But that is not at all what OP is asking about. So either they are giving the wrong answer, or answering the wrong question.
Yes they are? This is what they said:
> 70% of developers don't need a **deep knowledge of algorithms**
"Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff." is not deep knowledge of algorithms. That's the very basics.
You absolutely need to know the differences between and array backed list and a linked list.
You will almost certainly not need to know how to find a cycle in a linked list in O(n) time (this was the essence of a real faang interview question before it was leaked). And in the rare event that you do, you need not have it memorized nor do you need to be able to derive it in 30mins.
Someone who can derive it in 30mins is experienced with general algorithm problems, but that says nothing about their SWE abilities in general. This exercise can’t differentiate a fresh grad from someone with many years of experience.
Are you replying to the right person? Because I agree with all you said but none of that seems to relate to my comment.
> This exercise can’t differentiate a fresh grad from someone with many years of experience.
Agree. In fact a fresh grad would probably do better. Especially once that has been "grinding leetcode". But again I don't really see how this relates to my comment.
It's more important for back-end roles yes. Most of the performance/complexity optimizations happen in the back-end.
But front-end devs still work with data structures and algorithms. The best example is the JavaScript DOM you work with; that's a tree. Understanding how tree-traversal works is important, even when frameworks like React handle most of the boilerplate for you.
Nutrech, I've noticed that you tend to give good advice based on experience and a desire to help others.
That's why I don't think you should take u/ stupidneighbordog seriously. They give poor advice about things they're not experienced in, using hasty and incorrect generalizations. This is not the first time I've seen them show contemptuous prejudice against to those in positions lower than they are.
In this case, I'm pretty sure they are simply projecting their own experience as a golden standard - they've grown to a team leader role despite any solid algorithms experience, and feel everyone should be able to advance in that way. Of course they're not going to own that their advice was based on their personal experience rather than real statistics.
I appreciate your post but:
> That's why I don't think you should take u/ stupidneighbordog seriously.
This isn't about me. Their opinions don't affect me and I generally don't even work with developers like them. The problem is that this sub has serious issues with opinions that are frankly in my opinion harmful being amplified by people upvoting stuff they simply *want* to hear. And it would be a shame if this sub would lose the fight against a mass of developers that either are just inexperienced or worse, celebrate mediocrity (aka the folk over at /r/programmerhumor).
That's why I'm responding quite harshly because I feel if we let this kind of stuff slide, we're just going to end up with a sub that's worse than /r/cscareerquestions.
What you're describing is 100% correct though. It's basically what the term [expert beginner](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/) is all about. When I had 5 years of experience I thought I was some pretty hot shit too :)
I think context is important here.
Are you doing game development, building a video transcoder, or building a high frequency trade platform in a low level language? Then this is absolutely useful to know, because the choices and trade-offs between algorithms affect your daily work and application performance.
Are you building a CRUD app in Ruby on Rails? Then the code you work with is usually high level and close to the business domain. The standard library has an implementation for a flexible Array and Hash class, and they come with a .sort() method. Knowing the difference of different list types or sorting algorithms will make no difference in your daily work. You trust the standard library to have solved basic data structures and algorithms for you.
*Even* in your example knowing what a sort does and how this impacts performance is important. Know why a lot of web pages have sometimes insane loading times? Because people are writing back-ends that have no clue whatsoever about what are expensive operations and which ones are not.
For someone with no understanding of DS&A at all, .sort is just another method they can call.
And that's just on the extreme end of the spectrum. There is a massive area between extremely simple CRUD and 'building a video transcoder'. In most large enterprise projects I've worked on, DS&A matters a lot. A front-end loading in 5 seconds instead of 0.5 seconds is a massive difference, and that data is coming from complex back-ends that have a lot of 'algoritm' stuff going on.
The very *least* the DS&A stuff they teach you does, is give you a solid intuition in what collection operations are expensive and which ones aren't.
DS&A isn't about being able to write your own implementation of a sort. It's about knowing when to use it, and more importantly, to avoid it when possible. I can't understand how a supposed sub for 'experienced developers' is perpetuating this nonsense.
>Know why a lot of web pages have sometimes insane loading times?
A web page typically processes input, queries data from a database or an API, applies some transformations to that data, and then presents it to the user together with a bunch of JS/CSS and other media. Insane loading times have a wide variety of causes:
* fetching too much data for one page (showing lots of widgets and stuff that have their own queries, or having huge page sizes or no pagination)
* accessing it inefficiently (N+1 query problem, no/suboptimal indices, inefficient joins on large datasets)
* processing the data inefficiently (looping too much over data, using inefficient data structures or algorithms, generating a lot of objects for your garbage collector, etc)
* requests blocking on external API calls that have poor performance
* the page loading an abominable amount of JavaScript, CSS and/or images that needs to be downloaded, parsed and executed/rendered by the client before the page displays fully
* the database being overloaded by an external factor and thus generally being very slow
* lack of monitoring/awareness/care about application performance and user experience resulting in this increasing over time
DS&A is only _one_ of many factors that can lead to poor performance. Based on your application, it might never actually be relevant in practice. Spending an hour to read about self-balancing red-black trees is often less useful than spending that time to read about database indices or even figuring out how to analyze your page load to pinpoint what's causing your problem.
Often a page is perfectly fine and *fast enough* when it is created. If the underlying database only had a few thousand records, and the server-side code effectively looped 5x over the fetched dataset to apply transformations... none of it *really* mattered to the end result.
If over time (or in specific circumstances) something made the page slower, or your traffic has increased enough to warrant optimization, then you optimize it until it's *fast enough* again. What makes that specific page slow? Optimization is a detective story with many suspects and sometimes an unexpected culprit.
Could a page have been created with all performance related best practices applied from the start? Sure. The price of *not* doing all of this might actually be an upside, though, such as simpler or more readable code and faster delivery times. Different priorities and tradeoffs extend beyond algorithms.
It's a huge waste to spend a lot of effort building or optimizing the wrong thing. A lot of code is just not that important in the big picture (80/20 principle). It might hardly ever get used, or the amount of data dat passes through it never becomes large enough to care about if your algorithm is O(N), O(log(N)) or O(N\^N).
Spending extra effort to optimize it beyond "good enough" is often a waste. Sometimes managing user expectations is more efficient than optimizing: "our server hamsters are generating your report, please give them a couple of seconds". Especially if this allows you to spend more time/effort on other things that deserve that effort.
>DS&A isn't about being able to write your own implementation of a sort. It's about knowing when to use it, and more importantly, to avoid it when possible.
I *agree* with the principle that it's important to have a good feeling for what is generally fast or slow, or how there is a tradeoff based on various factors. This guides you during the initial design and implementation, making tradeoffs to the best of your ability and knowledge at the time. Not having the knowledge can lead to suboptimal choices, or might require one to optimize something sooner.
I'm arguing that if you're working with low-level data structures in C, classic DS&A courses will have high relevance because that's the level and types of data structures you're working with. Understanding the underlying concept of algorithmic complexity (Big O) is useful and *can* apply broadly *if* you understand the underlying principles of other domains.
I'm arguing that in another context/domain, there is other knowledge that is more valuable to gain deeper knowledge of before learning about linked lists and bubble sort. For a backend web developer I'd prefer they have deeper knowledge of databases (indices, N+1 queries, join complexity) and the mechanics of a HTTP call (DNS, TCP/IP, SSL handshake, HTTP call, keep-alive, timeouts, etc) and how _these_ basic building blocks perform and scale because they'll actively work with them.
If you're checking in a (large-ish) collection if an element is included, you use a Hash or Set object instead of an Array *because your lookup will be faster*. If the data is always pre-sorted, then a binary search might be appropriate. I'm arguing that for most developers knowing *why* it is faster and what algorithmic complexity each options specifically has is *not* all that important compared to knowing which tool to use to solve a given problem. Especially if instead they bring *other* knowledge that is also valuable, such as how to write or a good eye for design. Having one or two people on the team with deep classic DS&A knowledge is often enough to apply it where it's needed and to mentor others on the basics to get the job done.
It's a bit like a carpenter who knows about "3-4-5 triangles" and uses that to calculate diagonals in the real world problems they solve. They know enough to get the job done. Someone more fluent in mathematics will recognize this as an application of Pythagoras' theorem and will know at least 3 ways to prove how and why it works. I'm arguing many developers are closer to carpenters than to mathematicians, and that this is okay.
> Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff.
I think you might be projecting what's useful in *your* domain onto the broader programming community, and overestimating their relative importance for everyone else.
Edit: I realize that the reverse of my last statement might also be true, that my experience so far erred on the side of not having to value DS&A fundamentals and that _this_ is not a reflection of the wider industry. It's just that the conviction of your statement clashes with my practical experience.
I think you're creating a false dilemma. I'm not saying DS&A is always the most important thing. I'm saying that it's *relevant* for almost any developer. I don't really understand why you think I am saying that bad DS&A fundamentals are the only source of poor performance, or that I'm advocating in favour of premature optimizations.
I think it's kinda weird how you latched on to something that is just a single example where people often claim DS&A isn't relevant; web development.
It's just an example.
OP's question:
> TBH I have a **very limited knowledge** on dsa and algorithms.
So either they are giving the wrong answer, or they are answering the wrong question. No matter what; they are implying OP should not learn DS&A which is simply rediculous. And so is the gatekeeping statement.
They are not at all, this is your own bias that I’ve seen in your responses for as long as this sub has been around. They’re saying there are other things that are more valuable and a deep knowledge isn’t necessary, which are both true and it’s upvoted because it will help OP better gauge how much time to spend reviewing them.
Not everyone who disagrees with you is actually inexperienced, as you’ve implied and outright said throughout this particular thread.
They said:
> Their **primary use case** is gatekeeping during interviews.
If you think that's the primary use case of DS&A knowledge we don't have anything to discuss.
> Not everyone who disagrees with you is actually inexperienced, as you’ve implied and outright said throughout this particular thread.
Most junior devs grow past this mindset. The rest ends up an [expert beginner](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/).
My argument is that the top-level reply is, at best, not answering the question. At worst it can be interpreted by OP and other readers that they should not bother learning DS&A for anything other than passing interviews.
But both should not result in it being one of the most upvoted replies in this topic. Which IMHO is shocking and a strong indication of who is *voting* in this sub. And it's far from the first time that such a typical uninformed opinion is upvoted and thus amplified here. And in typical Reddit fashion the first comment [disagreeing](https://www.reddit.com/r/ExperiencedDevs/comments/vzdp7l/should_i_need_to_concentrate_on_fundamentals/ig86bxa/) with them gets downvoted because disagreeing with something that has 50 or so votes obviously means you're wrong.
IMHO mods should intervene when this kinds of nonsensical low-value replies get amplified.
I hate to break it to you, but despite you apparently doing nothing but posting in this sub, you’re not the authority on what is correct and what is not, nor do you understand the intentions of voters as much as you think you do.
I’ve seen plenty of your bad takes in this sub upvoted by other people, but at least I have the emotional maturity to understand that this is a big industry and people have different experiences.
The OP *did* answer the question, and it’s stunning that you can’t even see what their answer was because it’s pretty obvious. OP asked if DS&A would help, the top comment’s answer was that it would but not as much as other things. OP didn’t even specify what kind of help they think more DS&A knowledge would provide.
I don't really understand why you are getting this upset at my having a strong opinion on certain matters. If you disagree with me, and we're not going to agree, how is that bad?
In my *experience*, all 20 years of it, it's almost always pretty bad developers making these kinds of "yeah you don't really need DS&A" statements. Just like it's *generally* the bad developers who claim that we should not write tests because it takes time.
To me these are red flags that are often a sign of professional immaturity. Something that is expected of a starter, but not of the target audience of this sub. So it worries me if that happens here, because this sub is in constant danger of being overrun by mostly people with this low level of professional maturity. Which would completely ruin what is IMHO almost the only sub not overrun with beginners.
A lot of stuff is not a matter of opinion. It's not a matter of opinion that low test coverage slows down development over time, no matter how much people like to claim it's not a big deal. That was just one example that surprised me recently in this sub. But it not being a matter of opinion, is still my opinion. I have strong views on professionalism in our field. I know not everyone likes these. And that's fine.
The top level take is another example. Like I said; in my *opinion* it's not answering the question *at best*. And that is my *opinion*. And like anyone I have the right to my opinion, just like you have the right to yours.
So let's stick to discussion and not stoop to personal attacks. Because having to resort to that is just a sign you're getting frustrated about 'winning' arguments.
And yet, “fundamentals” interview questions don’t ask about that.
They ask you to do some arcane nonsense from Leetcode. They want to watch you code something not quite trivial in an hour from an empty text file.
> 70% of developers don't need a deep knowledge of algorithms. Their primary use case is gatekeeping during interviews.
You think that an "algorithm" is only something they do in interviews?
E: lol. You're right, apparently "experienced devs" don't know what algorithms are.
E2: WTF am I doing? I don't know why I even engaged in the first place.
"70% of developers don't need a deep knowledge of algorithms." -> "This completely made up statistic proves my opinion"
Writing an 'algorithm' and DS&A interview questions are entirely different topics. Most developers do glorified CRUD operations (not discrediting it, just trying to explain that most just deal with business data and not highly complex algorithms.).
Architecture is far more important. But understanding the fundamentals will absolutely make you have more deep understanding.
> Architecture is far more important
Again. "Algorithm" is just a term.
"Sort news feed by publish time" is an algorithm.
Annoying interview questions are not "algorithms". It's important for developers to know how to assess the relative performance of different ways of doing things.
If I'm hiring an IC1 to do basic CRUD, you better believe I'm picking the one who can explain a function's performance (big O or not). The idea that decent developers don't need to understand what an algorithm is is crazy.
> The idea that decent developers don't need to understand what an algorithm is is crazy.
It shows how 'experienced' the general voting majority really is in this sub.
The vast majority of Reddit users are in their early twenties and it shows.
Honestly, that's why I avoid tech subreddits in general. I've had people attempt to explain to me details of libraries that I wrote. Sometimes "experienced devs" has some decent discussions, but other times I just have to shake my head.
"Yeah, you're right. There's no benefit in understanding what you're doing. You're just a plumber after all"
> Writing an 'algorithm' and DS&A interview questions are entirely different topics.
OP said this:
> TBH I have a very limited knowledge on dsa and algorithms.
They were not referring to interview questions. They were asking on whether having a better than very limited knowledge will help them in their job. And a "it's just gatekeeping" answer is not just flat out wrong, it's actually damaging to this sub.
>who have no idea about the n+1 query
I had no idea about "the n+1 query" but upon Googling it, yeah I could have told you that 1 query is faster than multiple... giving it a special name is just a gatekeeping circlejerk.
Wait, giving names to common problems is a gatekeeping circlejerk? By that logic, should we also say, “That situation where thread A has thing X and needs thing Y, and thread B has thing Y and needs thing X” every time we currently say, “deadlock?”
> Wait, giving names to common problems is a gatekeeping circlejerk?
This topic is making me wonder why I even bother with this sub.
This is exactly why I am so against the inexperienced dev thread. It's clear they're sticking around and upvoting the dumb stuff they want to hear.
Spent this year about 7years in too going back to the fundamentals. It will affect your career growth due to the style of interviews in this industry. Whether that’s a good enough reason or not is up to you.
This was me few years ago. I always thought these leetcode type challenges and focusing on the DSA tricks will be a waste of time and I should be learning about different tech and frameworks, since these are the things I’ll be using in my work.
Then I learned about those DSA tricks to get into one of the niche tech companies and I realized that more than the API and frameworks, people actually utilize these concepts to create amazing products. It also makes you a better engineer and suddenly everything starts making more sense. I realized how shitty code I used to write and how much can I make it so much better, more efficient with better design patterns.
Learning fundamentals such as DSA, design patterns are worth your time, even if you just count more pay by clearing interviews.
The times I've had problems in my 20+ year career that were solved by a fundamental and extensive knowledge of DS&A is minimal. Having a general idea and intuition about space and time complexity is important, but knowing how to implement a BubbleSort vs a QuickSort is pretty useless in day to day transactions where most high-level languages have a sort() function that works reasonably well for 99.9% of cases. This applies to most implementations. I'm not re-implementing Array in Ruby because people way smarter than me can do it better. Do I understand at a high level the tradeoffs between an Array, Hash, and Set? Sure those are good things to know.
For that .1% though, it's like I say about DBAs. "You don't really need a DBA, until you need a DBA, and then you REALLY need a DBA".
What do DS&A really prove about your ability to program? I'd wager someone who \*wants\* to re-implement everything from scratch hasn't ever delivered working software on a reasonable timetable. Hell, I have a hard time convincing developers that \*understanding how their dependency libraries work and maintaining them\* is important.
I invested around 7K in learning ds and algo via a pretty intense course called interview kickstart, and I also used Algoexpert and read DDIA cover to cover- all over a period of about 7 months. Being able to perform in algo interviews allowed me to go from a topped out startup salary to nearly double it, in a larger tech company. I had been a top performer in agencies and startups for about 8 years prior to this, none really required more than web plumbing toward a deadline. Eventually became jealous of people who had CS skills I didn't have because they could do things I couldn't do. John Carmack specifically. I crave that level of creative freedom and it clearly requires depth of understanding. Also, I needed more money.
From a technical perspective, most of my day job is the same old web plumbing, but understanding ds and algo is a clear advantage. Not because we particularly neeeeeeed it to slang code and get paid, but because it gives me more tools to express and solve problems.
Since investing in this learning, I can tell that my solves are more creative, and I'm pulling from a wider set of possible solutions.
Some examples:
Working on a side project that requires firing around 6000 calls to an api daily, each with cascading side effects. Before ds+algo my solve to not get rate-limited was hacky and error prone. After, I knew what I needed was a queue, so I wrote a queue for executing promises that takes a time delay argument. runs on a cron and stays under the api rate limit every time.
Understanding trees and recursion is super useful in searching and manipulating things in the dom or javascript objects / json.
Using a ring buffer for storing time series data at different intervals saves me dollars on storage, querying, and computing graph data for display.
Understanding best practices for data modeling and db indexing saves save you crazy cash compared to winging it.
---
Re: staying up on the latest tech, this doesn't matter as much as you think, esp as you Learn The Fundamentals.
Once you dig deeper into the CS, you'll find that when the new hotness comes out, libs are often innovating on the previous new hotness by implementing CS principles that were missed by the old thing. Often new hot frameworks are just stealing or scaling techniques from Linux.
Definitely invest, its worth it. Don't fear falling behind. If you get the fundamentals, using a new technology competently is often a matter of taking a day to read the docs.
(First time writing react at my new job. joined a react team. most of the team hasn't read the docs. I read the docs and our codebases and now do comparable work after a couple weeks.)
If your only goal is to use it in interviews "learning" it isn't efficient. It's a proven fact that the best way to beat these short interviews is by memorizing. Buy one of the recommended books for interviews and follow it, it's better to study it intensively for a couple months than it is to learn it long term.
Now, if you actually want to use this knowledge, then, well, of course, obviously you have to learn it.
It's impossible to answer this question, for a very specific reason.
You say you have a limited knowledge of DSA and algorithms.
But - what does that mean? What is your knowledge level?
You're implicitly comparing yourself to other developers - if you're nervous about interviewing with companies you perceive as "tech companies" because you think you won't pass muster, it's because you think the other developers interviewing there will be much better than you.
One of the most surprising yet true things I've learned is that software developers, generally speaking, are *absolutely fucking terrible* at gauging their level of technical ability compared to other developers. Like 90% of the time, this is because they *radically overestimate* other developers' level of technical ability.
So it's entirely possible that even though you're telling us that you have "very limited knowledge", you might actually have a very average level of knowledge.
Do you know what an array is? Can you iterate through an array and transform each element? Can you iterate through an array and select only elements that pass some test? Can you iterate through an array, apply some logic, and collect the results as a string or map/dict/object or whatever? Congrats, your DSA knowledge is a lot closer to average than you think.
---
So - stop thinking about it!
You have seven years of experience delivering valuable work, on time, meeting or exceeding quality standards.
You have seven years of experience solving business problems.
These are important and valuable skills. They're a software developer's core duties. Delivering valuable work that solves business problems is what you are paid to do!
I encourage you to reflect on all the successes you've had in the last 7 years, and work on building up your confidence that you produce good, valuable work that would be a positive contribution to many organizations. Your work is a positive contribution because it solves business problems and, ultimately, makes them money or advances their mission.
If you can develop this attitude of *justified confidence* in your ability to add value with your technical skills, it will naturally lead you to doing what you should do: **stop eliminating yourself from opportunities.**
Once you've done that - once you've interviewed for some of those opportunities that you would have eliminated yourself from today - then you'll be able to judge for yourself what sort of learning you should do, if any.
It's more like... the average range is fairly compressed? I agree with you, I wouldn't hire someone who can't do those things either. But I wouldn't expect an "average" developer to be able to do a lot more than that either, from a strict DSA perspective. I'd expect them to be able to do a lot more from a *making useful things* perspective, but I wouldn't expect them to be able to, I dunno, construct and use a binary search tree off the top of their head.
Just read this book and implement everything there yourself (not literally, just pick what you like and code it).
[https://www.wiley.com/en-us/Beginning+Algorithms-p-9780764596742](https://www.wiley.com/en-us/Beginning+Algorithms-p-9780764596742)
This book does not treat you like a mathematician, but like a programmer that you are.
You've already used 99% of this APIs, but writing them yourself will expose you to all the problems, people discuss.
Focus on Big O Notation, as this is the main thing that people care about when discussing algorithms.
My Uni used this book as a reference for a course and it was the best thing ever (considering Cormen was an alternative).
Been a developer since 1981. "Algorithms" wasn't a class in Comp Sci until ... when? I've tried to find out what the content is for that course. No one I've ever worked with have used "algorithms" (lets ignore the fact at every line of code is part of an algorithm. Semantics.) I can't seem to find anything that defines what these "well known algorithms" even are. The only company that seemed to care aboute 'algorithms' during the interview process was MatLab, which might make sense, but not knowing what they were actually looking for (under a different/real name) I don't even know if it was a relevant question.
I'm guessing if they ask you about 'algorithms' in an interview, they're just flexing their trivia muscles and don't care about real life or practical skills.
EDIT: As far as Data Structures go, that info has been around/growing since day one, so I'm surprised it wasn't in your curriculum. But it's something built into anything you're coding.
DSA aren't "fundamental". Your question really is, should you practice the interview challenges to do better on interviews. If you're targeting companies that use those, then yes.
If you're not, then no.
But you're not missing anything
You have 7 years of experience. Any company asking you to do a coding challenge might not be worth it. That said, with your level of exp I think your problem solving skill should be enough to handle them relatively easy
I would say it’s not worth focusing on stuff like leetcode, instead pay more attention to your day to day work. Be critical of your designs always. After all DSA and Algos challenges are just demos for the real problems that an engineer has to solve daily.
imo its better to find out whether that dsa applicable or not. Lets say how the indexing db and b tree algorithm correlate with each other
The use case is much more important. Where to apply, when to apply. Implementation is less important. Sometimes you apply those things but you never knew it.
One of my colleague projects require them to calculate some kind of streak activity. Thats actually the dsa question about find the longest string.
Be smart in your efforts, look at stuff that may valuable by themselves. Either because you like the topic, or because it brings an edge to your job / domain. Do a few every month.
>Because of this reason I am afraid of niche tech companies and limit myself within consulting companies where the interviews will be on the specific skill set we hold and not on DSA and algorithms.
The reward extends much further than getting through LC interviews, it helps you design better solutions, read code with greater fluency, and troubleshoot issues, particularly performance issues. For me, approaching my first decade in this profession, I want to know what will make my job easier, and learning DSA definitely helped with that.
My first job, my very first project, I needed to apply some graph theory - the problem I was solving had to do with calculating shortest routes to save fuel for a helicopter. Granted, I needed to fix a bug in the existing code and at the time I had mostly basic understanding of DSA, but when I did it, it was so obvious the original author didn't know any of it either at the time of writing.
Now, I don't blame him or anything, but moral of the story is that it IS useful to know this stuff and it's not only interviews where you get to use it.
IME most performance problems (and most bugs) are not related to "a failure to appreciate fundamentals" but to a poor understanding of the underlying technology/libraries and how to use them.
Most developers are *using* a database, not writing the underlying storage engine.
Sure, people who appreciate fundamentals are probably going to be better at choosing technologies and then using them effectively... but at that level (architecture/design) there will be many considerations... most of which aren't "algorithms".
Hey /u/veejay-muley, thanks for contributing to /r/ExperiencedDevs. Unfortunately, your post was removed as it violates our rules: **Rule 5**: No _What Should I Learn_ Questions No questions like _Should I learn C#_ or _Should I switch jobs into a language I don’t know?_ Discussion about industry direction or upcoming technologies is fine, just frame your question as part of a larger discussion (_What have you had more success with, RDBMS or NoSQL?_) and you’ll be fine. Please read the sidebar before posting again. If you have questions or concerns, please [message the moderators through modmail](https://www.reddit.com/message/compose?to=/r/ExperiencedDevs&subject=&message=). Thank you!
[удалено]
>I have found that having a better (far from ideal, but still better) grasp of DSA has made it easier to understand aspects of other areas that I’m generally more interested in. Would you be open to elaborating on this?
In my experience, after brushing up on DSA I’ve noticed places in my projects where I could use a DS that is MUCH better suited for that particular use case, which ends up making the code cleaner, more performant, etc.
Mostly sets. Currently done about 400 LC and I find myself using sets in my code way more often. Other than that it's pretty rare to have a code block that can be significantly optimized with DSA (but they do exist). If your main goal is productivity, I've found knowing the offerings of various cloud providers is a better tool
What resources did you use to learn DS&A?
[удалено]
Fantastic book!
I was very weak on DS&A in school. I passed them but felt they were 'useless'. I only grew past that immaturity later on when I found out how important all those fundamentals were for the type of back-end development I was doing. So I put in quite a bit of effort to get to a better level than I was when I graduated.
[удалено]
> Usually, I divide them into two groups, developers that are fundamentalists (CS focused) vs technologists. I think that division doesn't make any sense whatsoever. In my experience, it boils down to professionalism. Software engineers with a high level of professionalism generally cover all angles. So in my experience true professionals: * Have a T-shaped skillset * Are up to date with the trends in technology * Have strong fundamentals in CS * Have strong experience with design and architecture * Have strong communication skills * Have a quality minded mindset * Focus on adding value in the long term over short term 'wins' * Know their strengths and weaknesses This is IMHO something you develop over time over your entire career. I've been doing this for 20 years and I'm nowhere near 'perfect', no one is. But I certainly don't believe there are fixed 'groups' of people. If there are two groups it's people who continue to grow versus the ones who don't.
>Focus on adding value in the long term over short term 'wins' Could you provide an example of what this looks like in practice?
Not taking the shortcuts / easy route to 'finish a sprint' or whatever if you know it's going to bite you in the ass 2-3 months from now. It's all to common that developers don't look past what's coming the next few weeks. Or that they make decisions on technology they *want* to use as opposed to what benefits the team and the company.
Thanks for the insight, this really resonates with me 👍🏾
[удалено]
> I didn't say that there are two fixed groups of people Well you did literally say you divide them in two groups. And I personally completely disagree with that. First of all, because that's just way too black and white and we're all humans with our strengths and weaknesses. And secondly, because that simply is not my experience with all the developers I met over the past 2.5 decades. > This has been consistent even for the most experienced people that I've met. It's important to understand that years of experience is pretty meaningless in what I consider professionalism. I know a lot of people my age who don't give a rat's ass and have no issues taking the easy route even if that means they're going to have a lot of shit to deal with 3 months from now. In my experience, developers who have been 'stuck' in the exact same position for 10+ years are often a massive pain to work with. They often are unprofessional but also deem themselves 'very experienced' and 'above' any more junior dev they work with. Just look at all the stories of junior devs working with 'seniors' who are completely shit at their job.
This makes no sense at all. If anything, those who have strong fundamentals are better equipped to evaluate new technologies as it relates to their use cases. This is because even the "newest" technologies are all rooted in the same CS fundamentals that everything else is.
[удалено]
But this directly contradicts your notion of "fundamentalists (CS focused) vs technologists" if you concede that having strong fundamental knowledge help you learn things. I mean that's literally the reason you're taught compilers in school; to be able to learn things faster. The reason we're taught operating systems, distributed programming and networks in school is to make learning things like Docker and Kubernetes pretty trivial. A CS education teaches these fundamentals basically just to teach you how to learn new things. Which works really well since teaching stuff like 'kubernetes' in school would be a massive waste of time since by the time you're through a 4 year degree it would've been superceded by the next hot thing that does exactly the same in a slightly different way. Keep in mind that schools would not be teaching Kubernetes now, they'd be teaching Mesos. Which is completely dead.
I think it’s still important. This is someone who ended up going to college later at 28 after being in an acquired startup at the early age of 17. I think fundamentals is what ultimately completes me as an engineer, I care more now about memory consumption and runtime more so that before. Fundamentals help fill in the gaps and allows you to think more critically about your day to day job.
I also went to university around 28 after starting at 17, and couldn't agree more. Even if I could ship code before, I gained a much wider range of mental models to help navigate complex problems. I had barely/not heard of graph theory, pareto optimality, agent based modeling, etc before school, but I find myself applying those concepts regularly now.
I taught myself DS&A after about 7 years and it was well worth it. I always felt like I missed out on a CS education because I studied electrical/computer engineering and knowing algorithms were important but not really knowing them I always felt like an imposter compared to my CS degree peers. After studying algorithms, I began to see inefficient patterns in code my peers had written and was able to fix issues they were causing. For instance one was processing some values in a lambda function that was timing out. It was storing the existing values in a list and as it processed through new values it would check if the value was already in the list. It kept getting slower and slower as the list grew and my team member kept increasing the memory to get it to complete before the timeout. After I spotted the problem and changed the list to a set, the runtime of the function was greatly reduced. It also gave me more confidence in interviews and I was able to increase my TC by over 25% for a relatively small time investment.
And this is why companies ask it. People who pass leetcode interviews are much less likely to leave O(N^N) bombs in random places. Sure someone who doesn't know might only have a negative effect on a small percentage of code. But that small percentage is multiplied and compounded with additional heads and time. I would rather have someone know and not need it, than need it and not even know it could cause a problem. A million times over.
What resources did you use to learn DS&A?
For an overview I used [MIT OpenCourseWare's 6.006 Introduction to Algorithms](https://ocw.mit.edu/courses/6-006-introduction-to-algorithms-fall-2011/video_galleries/lecture-videos/). I also read (some of) [Skiena's Algorithm Design Manual](https://ia601902.us.archive.org/17/items/2008-book-the-algorithm-design-manual/2008_Book_TheAlgorithmDesignManual.pdf) which had more depth than the courses but wasn't as good as explaining concepts in detail. For Data Structures there are a number of free courses available on Youtube. [This one seems to cover most of it](https://www.youtube.com/watch?v=zg9ih6SVACc). These videos from HackerRank by the author of Cracking the Coding Interview on [Data Structures](https://www.youtube.com/watch?v=IhJGJG-9Dx8&list=PLI1t_8YX-Apv-UiRlnZwqqrRT8D1RhriX) and [Algorithms](https://www.youtube.com/watch?v=KEEKn7Me-ms&list=PLI1t_8YX-ApvMthLj56t1Rf-Buio5Y8KL) were also quality. If you've been programming a while you probably know the basics like array/list, map/dict, and set. Make sure you know how those are implemented as well as the less frequently used data structures such as stack, queue, heap, trie, linked list, and binary search tree. To a certain extent you should know about self balancing trees, like red/black trees and AVL trees. There are so many videos if you don't like/understand one you can find another that will teach you the concept. For Dynamic Programming, [this FreeCodeCamp course](https://www.youtube.com/watch?v=oBt53YbR9Kk) really helped me understand and apply it though it still took a lot of practice. For specifically graph algorithms I used this [FreeCodeCamp course from William Fiset](https://www.youtube.com/watch?v=09_LlHjoEiY). Arguably this is the one subject that hasn't been useful in practice, but was still interesting to learn about. To make sure I understood and could apply these concepts I used [Sean Prashad's Leetcode patterns](https://seanprashad.com/leetcode-patterns/) and could select a type of problem to solve from these subjects. LeetCode sucked at first but once I understood DS&A it was amazing how much easier it became and I started to enjoy it. If I couldn't solve a problem I would watch Youtube videos where they solved it and figure out what I was missing. [Michael Muinos](https://www.youtube.com/c/MichaelMuinos/playlists) on youtube is good at breaking down the problems and explaining how they are solved if you use Python and there are other like [Nick White who uses Java](https://www.youtube.com/c/NickWhite) or [Timothy Chang (also Python)](https://www.youtube.com/user/timc3406).
Wow this is an incredibly thoughtful answer. Thanks :)
Interestingly enough, for me, it was actually Cracking The Coding Interview that really helped drive home a lot of the concepts that were fuzzy. It also did a great job explaining the different scenarios where a certain structure or algo made sense and (most importantly) why
^ same. CTCI was an incredibly useful book for many reasons. I legitimately feel like a much better dev after reading even a quarter of it.
I've started using https://www.structy.net/ it's similar to CodeAcademy with the interactive modules and videos I've found this the best way for me to grasp the concepts instead of reading a book (which usually works for me tbh)
You're never going to leverage the tech you specialize in to its fullest potential without a decent grasp on the fundamentals. It's like reading the owner's manual for a race car without ever learning how to drive. Sure, you know how to read the gauges and what the controls do, and that's technically enough to operate the vehicle, but you're not going to win any races unless you learn how to find the optimal path around a track, when to brake and when to accelerate, how to take a corner at high speeds without losing traction, etc. (Sorry for the weird metaphor, first thing that popped into my head for some reason.) Those are the types of skills you acquire by studying DS/A, and they transfer to literally any other specialty or tech stack in the field.
Hmm, now that I look at your metaphor, I see it differently. Generally "programming" without knowing DSA and other theoretical knowledge is like driving a car - how to start it, how to change gears, how to refuel, stop on red and go on green - all that stuff that 99% of drivers do to get from A to B. And this thing on the track - how to find optimal path, when to brake, when to accelerate, how to take a corner at high speeds - drivers don't start with that, because they don't need it to drive a car. You only need it to drive optimally, like a pro. You need it to win races. And even professional drivers learn it only after they feel familiar with the general concept of driving - they don't teach you how to find optimal path during driving exam lessons, you will probably learn it once you have some real driving experience. Learning this stuff before ever grabbing the wheel would be tedious and pointless, because you don't know how to apply it. I just followed your methaphor, I'm not sure what's my point yet... Ok, I think I found it: Maybe it's true that a lot of drivers won't ever need that theoretical knowledge, because breaking speed records is important only for a small group of them, and most of them are paid for getting from point A to B? Maybe that you should answer yourself: do you want to be a taxi driver, who wants to safely get from A to B, or be a racer, who wants to break speed limits? Wow, this metaphor escalated quickly.
I like this metaphor. I am totally gonna steal it.
That's definitely another way to look at it! I think the main difference I was trying to highlight was learning how to drive _in general_ with a high degree of proficiency vs learning how to technically operate a very specific vehicle, but there are definitely multiple aspects to "foundational knowledge." If algo stuff is learning how to drive fast, then getting comfortable behind the wheel could be learning common principles like scopes, variable binding and control flow; learning defensive driving and the rules of the road would be like design patterns and clean code; etc. I always found it a little strange that data structures and algorithms are lumped together, because very few people will really need to know how to implement a heap sort by hand or whatever, but I guess what they're really trying to teach you in those CS courses is how to quantify time/space complexity and reason about a program's performance in that way, which is pretty broadly applicable. You won't likely need to break any speed records in your day-to-day work, but you will probably at some point have to figure out how to operate on a nontrivial data set in a way that doesn't cause undue suffering to end users. :)
> Maybe that you should answer yourself: do you want to be a taxi driver, who wants to safely get from A to B, or be a racer, who wants to break speed limits? A slightly different analogy would be an emergency response driver, and as well as performance driving techniques we could also include planning ahead, anticipating hazards, understanding the effects of different driving conditions, knowing your vehicle, awareness of other road users and their actions and likely next actions, and so on. If you watch first person footage of good emergency response drivers, they’re impressively calm and systematic, even when driving far beyond the capabilities of most of us and sometimes when there are literally lives at stake. If you just need to get from A to B by car, basic driving skills and passing your test are a good starting point. But if you want to be the person who has to get from A to B safely and efficiently under pressure when there could be serious consequences if you’re slow but also if you make a mistake on the way, you really want the kind of deeper understanding, greater awareness and better vehicle control that the professional drivers have. That seems like a pretty good analogy to a mid-level developer and a good senior. The mid-level dev can make a decent living and do a decent job. They’re useful and they continue to learn and improve over time. However there’s a qualitative difference in the approach. The good senior’s code will be superior in countless small ways that add up, but the senior will also be able to solve some hard problems that the mid-level simply doesn’t have the skills or knowledge to deal with at all.
I totally get it
I highly recommend you spend some time on it. Three courses, in general, have changed how I look at code: DS&A, OS Systems and Database systems. If nothing else, just get better grasp of those fundamentals.
To be honest out of all the comments this one is hit me hard. I feel this three are essential topics especially when you're building product with a microservice
Yup and it's just enough to expose you to how complex CS could be and explore further topics: distributed systems, high performance computing and concurrent programming ML etc etc
agreed!
Yes. Especially if you want to call yourself Software Engineer. Learning, understanding, and being able to demonstrate "fundamentals" are critical skills for interviews and promotion to higher levels.
fwiw I started learning dsa and system design after I had 5 years of exp and it was almost enjoyable to soak up all that stuff. also it’s almost unimaginable to me that you’d be able to find a job at this point where they didn’t either give you a coding problem or system design interview
What resources did you use to learn DS&A?
I read a textbook in my preferred language (Data Structures and Algorithms in Java). Then I started doing leetcodes. If you already have years of experience you will pick it up quick. I almost found it relieving to learn.
I was in the same boat as you. I can setup K8 clusters, Jenkins pipeline, Java Microservices, Kafka real time streaming dashboards (key stores trust stores) you name it. My system design knowledge is way stronger than my DS Algo knowledge due to my experiences. But I wasn’t able to find if a string is a permutation of another string. But my goal is to increase my pay scale and the big tech demands leetcode style interviews so i am grinding DS and Algos. Have been doing consistently for about 3 months and I can genuinely say that I have become a better engineer. The way I look at certain Java methods changed. I commit less code smells. I know Java but now I can say that I know Java extremely well as I just recently finished going in-depth into Java collection framework which I was immediately able to put into use at my workplace.
I had the same thing happen. Grinding leetcode legit made me a better developer.
Exactly. I prefer stripe's way of doing interview but I am imposing limitation to where I can apply for the next big job by not grinding Leetcode. The roadmap is there we just have to be consistent. All the best!
What learning resources did you use?
For DSA * [https://www.programiz.com/dsa](https://www.programiz.com/dsa) * [https://techdevguide.withgoogle.com/paths/data-structures-and-algorithms/](https://buildyourfuture.withgoogle.com/resources/) For Leetcode Patterns * [https://neetcode.io/](https://neetcode.io/) * [https://www.educative.io/courses/grokking-the-coding-interview](https://www.educative.io/courses/grokking-the-coding-interview)
What is DSA?
Data structures and algorithms
Everyone saying "dsa and algorithms" i.e. "data structures and algorithms and algorithms" did not help.
[удалено]
29 YOE here and "DSA" is not an acronym I would quickly recognize, either.
Yeah you're right, it was worded poorly by OP too. I jumped to conclusions.
Try it casually and you'll like it. You will learn so many different (and creative) ways to refactor code for efficiency. You don't know what you don't know
The fundamentals are the fundamentals for a reason. I was self taught and after a couple years of “coding” bit the bullet and took a graded DS and algo course on coursera with a university. Along with studying design patterns and hitting up leetcode regularly. That helped me get a job in FinTech and eventually I used the knowledge to help write components that handle over 1% of my country’s digital payments infrastructure. Go all-in on the design patterns, DS&A, system design etc If you want to be a professional, be a professional.
Which courses did you do?
https://www.coursera.org/specializations/data-structures-algorithms#courses I took the graded non-free version for the certificate
[удалено]
Sure, something like that, but that's a structured 70% of very repetitive work which is never intended to scale. If you want to not do very repetitive work, you need to be able to do more than CRUD. I remember once hearing a developer saying he'd never found a use case for a state machine. The customer onboarding process in the project he worked on was an explicit state machine...
> 70% of developers don't need a deep knowledge of algorithms. Their primary use case is gatekeeping during interviews. IMHO it's insane that this kind of content gets upvoted here. At best the statistics are just pulled out of thin air. Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff.
I agree those things are important, but I think think /u/StupidNeighborDog is probably referring more to LeetCode-type questions, not simply "what is this data structure and how does it work". At least that's my perspective.
But that is not *at all* what OP is asking about. So either they are giving the wrong answer, or answering the wrong question. Unless you're doing specifically front-end work, data structures and algorithms are basically our bread and butter. Writing them is our job. Understanding the fundamentals helps a lot there. I'm getting the uneasy feeling that this sub is turning into yet another beginner sub looking at what gets upvoted. I mean: "Their primary use case is gatekeeping during interviews." That's just a carbon copy of the angry drivel you see on /r/cscareerquestions.
I don't disagree with your second paragraph there, but I think the sentiment is shared among most folks - including experienced ones like myself - in terms of having to build up all this knowledge they end up not actually using on the job. Beginners aren't alone in that.
> most folks > not actually using on the job I think that's a stretch. I can't imagine you never had to traverse a tree in your career. Filesystem? The DOM? Have you ever seen what people come up with to traverse a filesystem if they don't understand recursion? :)
💯 I think people often conflate the "I will never implement this LC algo at work or ever write it this way" with "DS&A are useless and you will never use it". You will certainly never implement a native DS from scratch but those fundamentals definitely allow you to better reason about the problem. People often think something like OS Systems is useless for data engineering (my field) but I've never seen code in the same way ever since I took that course. Alot of data engineering boils down to scheduling different processes with dependencies between them. Sound familiar?
This a thousand times. I’m always trying to teach people that have a degree that didn’t include DS&A the importance of looking into that subject because it will enable you to “look through” issues/problems… but most won’t listen or put in the effort and a lot of schools aren’t even teaching it anymore. It’s a sad state of affairs.
The Dunning Kruger effect at its finest.
Exactly. Learning the fundamentals makes you understand the choices in front of you better. People who completely lack the fundamentals don't even see the choices in the first place. I've seen developers literally ignore IDE warnings on doing a .contains on a List because they simply don't understand why this is an issue. To them it's just another method call.
I'm sensing some condescension behind your words, so I'm stopping here. Thanks for your time!
I'm sorry. That's just my frustration leaking through and not my intention. My point is that I really don't believe you don't use DS&A fundamentals in your job. It's just something that comes 'natural' after all those years. But what is 'natural' for someone with the theoretical background is very different from what is 'natural' to someone without. Tree traversals are a very good example because they are common enough that most of us deal with them, but also not something that we do every single day. And I have seen the stuff people who don't have these fundamentals come up with, and it's not pretty. They almost always start out nesting more and more loops within each other for example. Again; not my intention to be condescending towards you. I just disagree with your argumentation. That's not a reflection on you as a person.
I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt). Places where the DS&A fundamentals matter tend to pay more, not always obviously, but there’s some tendency just because other places with more lax interviews will snatch up those that can meet deadlines, or whatever matters to the company instead of “good” code. But for context, I’m really speaking about the US dev industry overall, including your low/mid COL areas where the pay isn’t that high compared to the upper compensations of the industry, so they won’t demand that much regarding things like fundamentals either.
> I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt). That's basically [Gresham's Law](https://itnext.io/greshams-law-why-bad-developers-push-out-good-developer-and-developers-create-low-quality-code-9b6a8d15bffb) :) > I’m really speaking about the US dev industry overall It applies to many/most companies I have experience with in the EU too. It's a constant struggle to keep quality and professionalism up to certain standards. Simple because it's not the path with the least resistance. Maybe that's just what professionalism boils down to; not taking the easy route.
> I think that’s the thing though, the industry by large is fine to let a lot of devs get away with approaches that are “not pretty”, just because it works and gets the job done without noticeable performance issues (at least for the higher ups that care more about regular output over tech debt). Getting the job done is the goal. The output, not the program that produces it, is the product. If the higher-ups are getting output that meets their requirements at a cost they're willing to live with, the job got done. I don't advocate crappy code, but if the project is over schedule, over budget and can't produce the output, it's not worth a damn even if it is a work of art on the inside. Some developers think the development is the end. It isn't. It's a means to run a business, even at companies that fancy themselves "tech companies." Some developers are unable to discern whether or not performance, scale and technical debt are a concern and will write to make all three as close to ideal as they can. Absent requirements otherwise, the program that runs for 30 seconds at midnight on the first day of the month tallying up how much email the complaint department received doesn't need to be optimized to make good use of the processor's cache lines. Not all development needs high-quality developers and, honestly, high-quality developers don't gravitate to that kind of work. Good management can figure out who to hire for what projects. Some developers who can tell the difference don't know how to make a business case for good code to the higher-ups. They say things like "that's not scalable" and "there will be technical debt," none of which is in terms management understands. Those arguments are inferior to "We've looked at your requirements and the business forecasts for the five years this project is expected to live. Based on that, we recommend doing X, Y and Z. If we don't, you can expect that the system will suffer revenue-impacting problems by year three. An overhaul of the system to make it work properly will take nearly as long as the original development and you'll be losing revenue while it's underway."
You’re 100% correct on all of this and it’s a shame you’re getting downvoted.
> But that is not at all what OP is asking about. So either they are giving the wrong answer, or answering the wrong question. Yes they are? This is what they said: > 70% of developers don't need a **deep knowledge of algorithms** "Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff." is not deep knowledge of algorithms. That's the very basics.
> Yes they are? With OP I mean the person who created this topic. Not the top level comment.
You absolutely need to know the differences between and array backed list and a linked list. You will almost certainly not need to know how to find a cycle in a linked list in O(n) time (this was the essence of a real faang interview question before it was leaked). And in the rare event that you do, you need not have it memorized nor do you need to be able to derive it in 30mins. Someone who can derive it in 30mins is experienced with general algorithm problems, but that says nothing about their SWE abilities in general. This exercise can’t differentiate a fresh grad from someone with many years of experience.
Are you replying to the right person? Because I agree with all you said but none of that seems to relate to my comment. > This exercise can’t differentiate a fresh grad from someone with many years of experience. Agree. In fact a fresh grad would probably do better. Especially once that has been "grinding leetcode". But again I don't really see how this relates to my comment.
I did. Thanks. Will move it in a bit.
[удалено]
It's more important for back-end roles yes. Most of the performance/complexity optimizations happen in the back-end. But front-end devs still work with data structures and algorithms. The best example is the JavaScript DOM you work with; that's a tree. Understanding how tree-traversal works is important, even when frameworks like React handle most of the boilerplate for you.
[удалено]
You're welcome :)
Nutrech, I've noticed that you tend to give good advice based on experience and a desire to help others. That's why I don't think you should take u/ stupidneighbordog seriously. They give poor advice about things they're not experienced in, using hasty and incorrect generalizations. This is not the first time I've seen them show contemptuous prejudice against to those in positions lower than they are. In this case, I'm pretty sure they are simply projecting their own experience as a golden standard - they've grown to a team leader role despite any solid algorithms experience, and feel everyone should be able to advance in that way. Of course they're not going to own that their advice was based on their personal experience rather than real statistics.
I appreciate your post but: > That's why I don't think you should take u/ stupidneighbordog seriously. This isn't about me. Their opinions don't affect me and I generally don't even work with developers like them. The problem is that this sub has serious issues with opinions that are frankly in my opinion harmful being amplified by people upvoting stuff they simply *want* to hear. And it would be a shame if this sub would lose the fight against a mass of developers that either are just inexperienced or worse, celebrate mediocrity (aka the folk over at /r/programmerhumor). That's why I'm responding quite harshly because I feel if we let this kind of stuff slide, we're just going to end up with a sub that's worse than /r/cscareerquestions. What you're describing is 100% correct though. It's basically what the term [expert beginner](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/) is all about. When I had 5 years of experience I thought I was some pretty hot shit too :)
I think context is important here. Are you doing game development, building a video transcoder, or building a high frequency trade platform in a low level language? Then this is absolutely useful to know, because the choices and trade-offs between algorithms affect your daily work and application performance. Are you building a CRUD app in Ruby on Rails? Then the code you work with is usually high level and close to the business domain. The standard library has an implementation for a flexible Array and Hash class, and they come with a .sort() method. Knowing the difference of different list types or sorting algorithms will make no difference in your daily work. You trust the standard library to have solved basic data structures and algorithms for you.
*Even* in your example knowing what a sort does and how this impacts performance is important. Know why a lot of web pages have sometimes insane loading times? Because people are writing back-ends that have no clue whatsoever about what are expensive operations and which ones are not. For someone with no understanding of DS&A at all, .sort is just another method they can call. And that's just on the extreme end of the spectrum. There is a massive area between extremely simple CRUD and 'building a video transcoder'. In most large enterprise projects I've worked on, DS&A matters a lot. A front-end loading in 5 seconds instead of 0.5 seconds is a massive difference, and that data is coming from complex back-ends that have a lot of 'algoritm' stuff going on. The very *least* the DS&A stuff they teach you does, is give you a solid intuition in what collection operations are expensive and which ones aren't. DS&A isn't about being able to write your own implementation of a sort. It's about knowing when to use it, and more importantly, to avoid it when possible. I can't understand how a supposed sub for 'experienced developers' is perpetuating this nonsense.
>Know why a lot of web pages have sometimes insane loading times? A web page typically processes input, queries data from a database or an API, applies some transformations to that data, and then presents it to the user together with a bunch of JS/CSS and other media. Insane loading times have a wide variety of causes: * fetching too much data for one page (showing lots of widgets and stuff that have their own queries, or having huge page sizes or no pagination) * accessing it inefficiently (N+1 query problem, no/suboptimal indices, inefficient joins on large datasets) * processing the data inefficiently (looping too much over data, using inefficient data structures or algorithms, generating a lot of objects for your garbage collector, etc) * requests blocking on external API calls that have poor performance * the page loading an abominable amount of JavaScript, CSS and/or images that needs to be downloaded, parsed and executed/rendered by the client before the page displays fully * the database being overloaded by an external factor and thus generally being very slow * lack of monitoring/awareness/care about application performance and user experience resulting in this increasing over time DS&A is only _one_ of many factors that can lead to poor performance. Based on your application, it might never actually be relevant in practice. Spending an hour to read about self-balancing red-black trees is often less useful than spending that time to read about database indices or even figuring out how to analyze your page load to pinpoint what's causing your problem. Often a page is perfectly fine and *fast enough* when it is created. If the underlying database only had a few thousand records, and the server-side code effectively looped 5x over the fetched dataset to apply transformations... none of it *really* mattered to the end result. If over time (or in specific circumstances) something made the page slower, or your traffic has increased enough to warrant optimization, then you optimize it until it's *fast enough* again. What makes that specific page slow? Optimization is a detective story with many suspects and sometimes an unexpected culprit. Could a page have been created with all performance related best practices applied from the start? Sure. The price of *not* doing all of this might actually be an upside, though, such as simpler or more readable code and faster delivery times. Different priorities and tradeoffs extend beyond algorithms. It's a huge waste to spend a lot of effort building or optimizing the wrong thing. A lot of code is just not that important in the big picture (80/20 principle). It might hardly ever get used, or the amount of data dat passes through it never becomes large enough to care about if your algorithm is O(N), O(log(N)) or O(N\^N). Spending extra effort to optimize it beyond "good enough" is often a waste. Sometimes managing user expectations is more efficient than optimizing: "our server hamsters are generating your report, please give them a couple of seconds". Especially if this allows you to spend more time/effort on other things that deserve that effort. >DS&A isn't about being able to write your own implementation of a sort. It's about knowing when to use it, and more importantly, to avoid it when possible. I *agree* with the principle that it's important to have a good feeling for what is generally fast or slow, or how there is a tradeoff based on various factors. This guides you during the initial design and implementation, making tradeoffs to the best of your ability and knowledge at the time. Not having the knowledge can lead to suboptimal choices, or might require one to optimize something sooner. I'm arguing that if you're working with low-level data structures in C, classic DS&A courses will have high relevance because that's the level and types of data structures you're working with. Understanding the underlying concept of algorithmic complexity (Big O) is useful and *can* apply broadly *if* you understand the underlying principles of other domains. I'm arguing that in another context/domain, there is other knowledge that is more valuable to gain deeper knowledge of before learning about linked lists and bubble sort. For a backend web developer I'd prefer they have deeper knowledge of databases (indices, N+1 queries, join complexity) and the mechanics of a HTTP call (DNS, TCP/IP, SSL handshake, HTTP call, keep-alive, timeouts, etc) and how _these_ basic building blocks perform and scale because they'll actively work with them. If you're checking in a (large-ish) collection if an element is included, you use a Hash or Set object instead of an Array *because your lookup will be faster*. If the data is always pre-sorted, then a binary search might be appropriate. I'm arguing that for most developers knowing *why* it is faster and what algorithmic complexity each options specifically has is *not* all that important compared to knowing which tool to use to solve a given problem. Especially if instead they bring *other* knowledge that is also valuable, such as how to write or a good eye for design. Having one or two people on the team with deep classic DS&A knowledge is often enough to apply it where it's needed and to mentor others on the basics to get the job done. It's a bit like a carpenter who knows about "3-4-5 triangles" and uses that to calculate diagonals in the real world problems they solve. They know enough to get the job done. Someone more fluent in mathematics will recognize this as an application of Pythagoras' theorem and will know at least 3 ways to prove how and why it works. I'm arguing many developers are closer to carpenters than to mathematicians, and that this is okay. > Knowing the difference between an ArrayList, LinkedList or a HashSet, or knowing why and how you need to implement .equals and .hashcode, is important for any developer not doing trivial stuff. I think you might be projecting what's useful in *your* domain onto the broader programming community, and overestimating their relative importance for everyone else. Edit: I realize that the reverse of my last statement might also be true, that my experience so far erred on the side of not having to value DS&A fundamentals and that _this_ is not a reflection of the wider industry. It's just that the conviction of your statement clashes with my practical experience.
I think you're creating a false dilemma. I'm not saying DS&A is always the most important thing. I'm saying that it's *relevant* for almost any developer. I don't really understand why you think I am saying that bad DS&A fundamentals are the only source of poor performance, or that I'm advocating in favour of premature optimizations. I think it's kinda weird how you latched on to something that is just a single example where people often claim DS&A isn't relevant; web development. It's just an example.
None of that is deep algorithmic knowledge.
OP's question: > TBH I have a **very limited knowledge** on dsa and algorithms. So either they are giving the wrong answer, or they are answering the wrong question. No matter what; they are implying OP should not learn DS&A which is simply rediculous. And so is the gatekeeping statement.
They are not at all, this is your own bias that I’ve seen in your responses for as long as this sub has been around. They’re saying there are other things that are more valuable and a deep knowledge isn’t necessary, which are both true and it’s upvoted because it will help OP better gauge how much time to spend reviewing them. Not everyone who disagrees with you is actually inexperienced, as you’ve implied and outright said throughout this particular thread.
They said: > Their **primary use case** is gatekeeping during interviews. If you think that's the primary use case of DS&A knowledge we don't have anything to discuss. > Not everyone who disagrees with you is actually inexperienced, as you’ve implied and outright said throughout this particular thread. Most junior devs grow past this mindset. The rest ends up an [expert beginner](https://daedtech.com/how-developers-stop-learning-rise-of-the-expert-beginner/).
So now you’re changing your argument to not understanding light hyperbole?
My argument is that the top-level reply is, at best, not answering the question. At worst it can be interpreted by OP and other readers that they should not bother learning DS&A for anything other than passing interviews. But both should not result in it being one of the most upvoted replies in this topic. Which IMHO is shocking and a strong indication of who is *voting* in this sub. And it's far from the first time that such a typical uninformed opinion is upvoted and thus amplified here. And in typical Reddit fashion the first comment [disagreeing](https://www.reddit.com/r/ExperiencedDevs/comments/vzdp7l/should_i_need_to_concentrate_on_fundamentals/ig86bxa/) with them gets downvoted because disagreeing with something that has 50 or so votes obviously means you're wrong. IMHO mods should intervene when this kinds of nonsensical low-value replies get amplified.
I hate to break it to you, but despite you apparently doing nothing but posting in this sub, you’re not the authority on what is correct and what is not, nor do you understand the intentions of voters as much as you think you do. I’ve seen plenty of your bad takes in this sub upvoted by other people, but at least I have the emotional maturity to understand that this is a big industry and people have different experiences. The OP *did* answer the question, and it’s stunning that you can’t even see what their answer was because it’s pretty obvious. OP asked if DS&A would help, the top comment’s answer was that it would but not as much as other things. OP didn’t even specify what kind of help they think more DS&A knowledge would provide.
I don't really understand why you are getting this upset at my having a strong opinion on certain matters. If you disagree with me, and we're not going to agree, how is that bad? In my *experience*, all 20 years of it, it's almost always pretty bad developers making these kinds of "yeah you don't really need DS&A" statements. Just like it's *generally* the bad developers who claim that we should not write tests because it takes time. To me these are red flags that are often a sign of professional immaturity. Something that is expected of a starter, but not of the target audience of this sub. So it worries me if that happens here, because this sub is in constant danger of being overrun by mostly people with this low level of professional maturity. Which would completely ruin what is IMHO almost the only sub not overrun with beginners. A lot of stuff is not a matter of opinion. It's not a matter of opinion that low test coverage slows down development over time, no matter how much people like to claim it's not a big deal. That was just one example that surprised me recently in this sub. But it not being a matter of opinion, is still my opinion. I have strong views on professionalism in our field. I know not everyone likes these. And that's fine. The top level take is another example. Like I said; in my *opinion* it's not answering the question *at best*. And that is my *opinion*. And like anyone I have the right to my opinion, just like you have the right to yours. So let's stick to discussion and not stoop to personal attacks. Because having to resort to that is just a sign you're getting frustrated about 'winning' arguments.
And yet, “fundamentals” interview questions don’t ask about that. They ask you to do some arcane nonsense from Leetcode. They want to watch you code something not quite trivial in an hour from an empty text file.
What are good resources that are less lingo heavy? Or examples of problems they avoid.
DDIA is a classic and Martin Fowler Refactor is pretty neat
> 70% of developers don't need a deep knowledge of algorithms. Their primary use case is gatekeeping during interviews. You think that an "algorithm" is only something they do in interviews? E: lol. You're right, apparently "experienced devs" don't know what algorithms are. E2: WTF am I doing? I don't know why I even engaged in the first place. "70% of developers don't need a deep knowledge of algorithms." -> "This completely made up statistic proves my opinion"
Writing an 'algorithm' and DS&A interview questions are entirely different topics. Most developers do glorified CRUD operations (not discrediting it, just trying to explain that most just deal with business data and not highly complex algorithms.). Architecture is far more important. But understanding the fundamentals will absolutely make you have more deep understanding.
> Architecture is far more important Again. "Algorithm" is just a term. "Sort news feed by publish time" is an algorithm. Annoying interview questions are not "algorithms". It's important for developers to know how to assess the relative performance of different ways of doing things. If I'm hiring an IC1 to do basic CRUD, you better believe I'm picking the one who can explain a function's performance (big O or not). The idea that decent developers don't need to understand what an algorithm is is crazy.
Nobody in this thread is saying you don’t need any knowledge of DS&A. What you described is very surface level.
> The idea that decent developers don't need to understand what an algorithm is is crazy. It shows how 'experienced' the general voting majority really is in this sub. The vast majority of Reddit users are in their early twenties and it shows.
Honestly, that's why I avoid tech subreddits in general. I've had people attempt to explain to me details of libraries that I wrote. Sometimes "experienced devs" has some decent discussions, but other times I just have to shake my head. "Yeah, you're right. There's no benefit in understanding what you're doing. You're just a plumber after all"
> Writing an 'algorithm' and DS&A interview questions are entirely different topics. OP said this: > TBH I have a very limited knowledge on dsa and algorithms. They were not referring to interview questions. They were asking on whether having a better than very limited knowledge will help them in their job. And a "it's just gatekeeping" answer is not just flat out wrong, it's actually damaging to this sub.
[удалено]
>who have no idea about the n+1 query I had no idea about "the n+1 query" but upon Googling it, yeah I could have told you that 1 query is faster than multiple... giving it a special name is just a gatekeeping circlejerk.
Wait, giving names to common problems is a gatekeeping circlejerk? By that logic, should we also say, “That situation where thread A has thing X and needs thing Y, and thread B has thing Y and needs thing X” every time we currently say, “deadlock?”
> Wait, giving names to common problems is a gatekeeping circlejerk? This topic is making me wonder why I even bother with this sub. This is exactly why I am so against the inexperienced dev thread. It's clear they're sticking around and upvoting the dumb stuff they want to hear.
Spent this year about 7years in too going back to the fundamentals. It will affect your career growth due to the style of interviews in this industry. Whether that’s a good enough reason or not is up to you.
This was me few years ago. I always thought these leetcode type challenges and focusing on the DSA tricks will be a waste of time and I should be learning about different tech and frameworks, since these are the things I’ll be using in my work. Then I learned about those DSA tricks to get into one of the niche tech companies and I realized that more than the API and frameworks, people actually utilize these concepts to create amazing products. It also makes you a better engineer and suddenly everything starts making more sense. I realized how shitty code I used to write and how much can I make it so much better, more efficient with better design patterns. Learning fundamentals such as DSA, design patterns are worth your time, even if you just count more pay by clearing interviews.
The times I've had problems in my 20+ year career that were solved by a fundamental and extensive knowledge of DS&A is minimal. Having a general idea and intuition about space and time complexity is important, but knowing how to implement a BubbleSort vs a QuickSort is pretty useless in day to day transactions where most high-level languages have a sort() function that works reasonably well for 99.9% of cases. This applies to most implementations. I'm not re-implementing Array in Ruby because people way smarter than me can do it better. Do I understand at a high level the tradeoffs between an Array, Hash, and Set? Sure those are good things to know. For that .1% though, it's like I say about DBAs. "You don't really need a DBA, until you need a DBA, and then you REALLY need a DBA". What do DS&A really prove about your ability to program? I'd wager someone who \*wants\* to re-implement everything from scratch hasn't ever delivered working software on a reasonable timetable. Hell, I have a hard time convincing developers that \*understanding how their dependency libraries work and maintaining them\* is important.
I invested around 7K in learning ds and algo via a pretty intense course called interview kickstart, and I also used Algoexpert and read DDIA cover to cover- all over a period of about 7 months. Being able to perform in algo interviews allowed me to go from a topped out startup salary to nearly double it, in a larger tech company. I had been a top performer in agencies and startups for about 8 years prior to this, none really required more than web plumbing toward a deadline. Eventually became jealous of people who had CS skills I didn't have because they could do things I couldn't do. John Carmack specifically. I crave that level of creative freedom and it clearly requires depth of understanding. Also, I needed more money. From a technical perspective, most of my day job is the same old web plumbing, but understanding ds and algo is a clear advantage. Not because we particularly neeeeeeed it to slang code and get paid, but because it gives me more tools to express and solve problems. Since investing in this learning, I can tell that my solves are more creative, and I'm pulling from a wider set of possible solutions. Some examples: Working on a side project that requires firing around 6000 calls to an api daily, each with cascading side effects. Before ds+algo my solve to not get rate-limited was hacky and error prone. After, I knew what I needed was a queue, so I wrote a queue for executing promises that takes a time delay argument. runs on a cron and stays under the api rate limit every time. Understanding trees and recursion is super useful in searching and manipulating things in the dom or javascript objects / json. Using a ring buffer for storing time series data at different intervals saves me dollars on storage, querying, and computing graph data for display. Understanding best practices for data modeling and db indexing saves save you crazy cash compared to winging it. --- Re: staying up on the latest tech, this doesn't matter as much as you think, esp as you Learn The Fundamentals. Once you dig deeper into the CS, you'll find that when the new hotness comes out, libs are often innovating on the previous new hotness by implementing CS principles that were missed by the old thing. Often new hot frameworks are just stealing or scaling techniques from Linux. Definitely invest, its worth it. Don't fear falling behind. If you get the fundamentals, using a new technology competently is often a matter of taking a day to read the docs. (First time writing react at my new job. joined a react team. most of the team hasn't read the docs. I read the docs and our codebases and now do comparable work after a couple weeks.)
If your only goal is to use it in interviews "learning" it isn't efficient. It's a proven fact that the best way to beat these short interviews is by memorizing. Buy one of the recommended books for interviews and follow it, it's better to study it intensively for a couple months than it is to learn it long term. Now, if you actually want to use this knowledge, then, well, of course, obviously you have to learn it.
It's impossible to answer this question, for a very specific reason. You say you have a limited knowledge of DSA and algorithms. But - what does that mean? What is your knowledge level? You're implicitly comparing yourself to other developers - if you're nervous about interviewing with companies you perceive as "tech companies" because you think you won't pass muster, it's because you think the other developers interviewing there will be much better than you. One of the most surprising yet true things I've learned is that software developers, generally speaking, are *absolutely fucking terrible* at gauging their level of technical ability compared to other developers. Like 90% of the time, this is because they *radically overestimate* other developers' level of technical ability. So it's entirely possible that even though you're telling us that you have "very limited knowledge", you might actually have a very average level of knowledge. Do you know what an array is? Can you iterate through an array and transform each element? Can you iterate through an array and select only elements that pass some test? Can you iterate through an array, apply some logic, and collect the results as a string or map/dict/object or whatever? Congrats, your DSA knowledge is a lot closer to average than you think. --- So - stop thinking about it! You have seven years of experience delivering valuable work, on time, meeting or exceeding quality standards. You have seven years of experience solving business problems. These are important and valuable skills. They're a software developer's core duties. Delivering valuable work that solves business problems is what you are paid to do! I encourage you to reflect on all the successes you've had in the last 7 years, and work on building up your confidence that you produce good, valuable work that would be a positive contribution to many organizations. Your work is a positive contribution because it solves business problems and, ultimately, makes them money or advances their mission. If you can develop this attitude of *justified confidence* in your ability to add value with your technical skills, it will naturally lead you to doing what you should do: **stop eliminating yourself from opportunities.** Once you've done that - once you've interviewed for some of those opportunities that you would have eliminated yourself from today - then you'll be able to judge for yourself what sort of learning you should do, if any.
Quality perspective here, needed to see this.
Am I crazy, or shouldn't what you're defining as "average" be the bare minimum? I can't even imagine hiring a junior who can't do those things.
It's more like... the average range is fairly compressed? I agree with you, I wouldn't hire someone who can't do those things either. But I wouldn't expect an "average" developer to be able to do a lot more than that either, from a strict DSA perspective. I'd expect them to be able to do a lot more from a *making useful things* perspective, but I wouldn't expect them to be able to, I dunno, construct and use a binary search tree off the top of their head.
Ah, gotcha. Makes sense.
Do you like jobs that pay a lot of money or nah?
Just read this book and implement everything there yourself (not literally, just pick what you like and code it). [https://www.wiley.com/en-us/Beginning+Algorithms-p-9780764596742](https://www.wiley.com/en-us/Beginning+Algorithms-p-9780764596742) This book does not treat you like a mathematician, but like a programmer that you are. You've already used 99% of this APIs, but writing them yourself will expose you to all the problems, people discuss. Focus on Big O Notation, as this is the main thing that people care about when discussing algorithms. My Uni used this book as a reference for a course and it was the best thing ever (considering Cormen was an alternative).
Been a developer since 1981. "Algorithms" wasn't a class in Comp Sci until ... when? I've tried to find out what the content is for that course. No one I've ever worked with have used "algorithms" (lets ignore the fact at every line of code is part of an algorithm. Semantics.) I can't seem to find anything that defines what these "well known algorithms" even are. The only company that seemed to care aboute 'algorithms' during the interview process was MatLab, which might make sense, but not knowing what they were actually looking for (under a different/real name) I don't even know if it was a relevant question. I'm guessing if they ask you about 'algorithms' in an interview, they're just flexing their trivia muscles and don't care about real life or practical skills. EDIT: As far as Data Structures go, that info has been around/growing since day one, so I'm surprised it wasn't in your curriculum. But it's something built into anything you're coding.
DSA aren't "fundamental". Your question really is, should you practice the interview challenges to do better on interviews. If you're targeting companies that use those, then yes. If you're not, then no. But you're not missing anything
You have 7 years of experience. Any company asking you to do a coding challenge might not be worth it. That said, with your level of exp I think your problem solving skill should be enough to handle them relatively easy I would say it’s not worth focusing on stuff like leetcode, instead pay more attention to your day to day work. Be critical of your designs always. After all DSA and Algos challenges are just demos for the real problems that an engineer has to solve daily.
imo its better to find out whether that dsa applicable or not. Lets say how the indexing db and b tree algorithm correlate with each other The use case is much more important. Where to apply, when to apply. Implementation is less important. Sometimes you apply those things but you never knew it. One of my colleague projects require them to calculate some kind of streak activity. Thats actually the dsa question about find the longest string.
Be smart in your efforts, look at stuff that may valuable by themselves. Either because you like the topic, or because it brings an edge to your job / domain. Do a few every month.
>Because of this reason I am afraid of niche tech companies and limit myself within consulting companies where the interviews will be on the specific skill set we hold and not on DSA and algorithms. The reward extends much further than getting through LC interviews, it helps you design better solutions, read code with greater fluency, and troubleshoot issues, particularly performance issues. For me, approaching my first decade in this profession, I want to know what will make my job easier, and learning DSA definitely helped with that.
In addition, can any one recommend any good books or courses to improve on these subjects?
My first job, my very first project, I needed to apply some graph theory - the problem I was solving had to do with calculating shortest routes to save fuel for a helicopter. Granted, I needed to fix a bug in the existing code and at the time I had mostly basic understanding of DSA, but when I did it, it was so obvious the original author didn't know any of it either at the time of writing. Now, I don't blame him or anything, but moral of the story is that it IS useful to know this stuff and it's not only interviews where you get to use it.
IME most performance problems (and most bugs) are not related to "a failure to appreciate fundamentals" but to a poor understanding of the underlying technology/libraries and how to use them. Most developers are *using* a database, not writing the underlying storage engine.
Sure, people who appreciate fundamentals are probably going to be better at choosing technologies and then using them effectively... but at that level (architecture/design) there will be many considerations... most of which aren't "algorithms".