I see new learners asking about “DSA” a lot. Data Structures and Algorithms are of course important: considered broadly, they are the two ingredients that make up all programs. But in my opinion, “DSA” as an abstract field of study is over-emphasized.

I understand why people focus on DSA: it’s a concrete thing to learn about, there are web sites devoted to testing you on it, and most importantly, because job interviews often involve DSA coding questions.

Before I get to other opinions, let me make clear that anything you can do to help you get a job is a good thing to do. If grinding leetcode will land you a position, then do it.

But I hope companies hiring entry-level engineers aren’t asking them to reverse linked lists or balance trees. Asking about techniques that can be memorized ahead of time won’t tell them anything about how well you can work. The stated purpose of those interviews is to see how well you can figure out solutions, in which case memorization will defeat the point.

The thing new learners don’t understand about DSA is that actual software engineering almost never involves implementing the kinds of algorithms that “DSA” teaches you. Sure, it can be helpful to work through some of these puzzles and see how they are solved, but writing real code just doesn’t involve writing that kind of code.

Here is what I think in-the-trenches software engineers should know about data structures and algorithms:

• Data structures are ways to organize data. Learn some of the basics: linked list, array, hash table, tree. By “learn” I mean understand what it does and why you might want to use one.
• Different data structures can be used to organize the same data in different ways. Learn some of the trade-offs between structures that are similar.
• Algorithms are ways of manipulating data. I don’t mean named algorithms like Quicksort, but algorithms as any chunk of code that works on data and does something with it.
• How you organize data affects what algorithms you can use to work with the data. Some data structures will be slow for some operations where another structure will be fast.
• Algorithms have a “time complexity” (Big O): how the code slows as the data grows. Get a sense of what this means.
• Python has a number of built-in data structures. Learn how they work, and the time complexity of their operations.
• Learn how to think about your code to understand its time complexity.
• Read a little about more esoteric things like Bloom filters, so you can find them later in the unlikely case you need them.

Here are some things you don’t need to learn:

• The details of a dozen different sorting algorithms. Look at two to see different ways of approaching the same problem, then move on.
• The names of “important” algorithms. Those have all been implemented for you.
• The answers to all N problems on some quiz web site. You won’t be asked these exact questions, and they won’t come up in your real work. Again: try a few to get a feel for how some algorithms work. The exact answers are not what you need.

Of course some engineers need to implement hash tables, or sorting algorithms or whatever. We love those engineers: they write libraries we can use off the shelf so we don’t have to implement them ourselves.

There have been times when I implemented something that felt like An Algorithm (for example, Finding fuzzy floats), but it was more about considering another perspective on my data, looking at the time complexity, and moving operations around to avoid quadratic behavior. It wasn’t opening a textbook to find the famous algorithm that would solve my problem.

Again: if it will help you get a job, deep-study DSA. But don’t be disappointed when you don’t use it on the job.

If you want to prepare yourself for a career, and also stand out in job interviews, learn how to write tests:

• This will be a skill you use constantly. Real-world software means writing tests much more than school teaches you to.
• In a job search, testing experience will stand out more than DSA depth. It shows you’ve thought about what it takes to write high-quality software instead of just academic exercises.
• It’s not obvious how to test code well. It’s a puzzle and a problem to solve. If you like figuring out solutions to tricky questions, focus on how to write code so that it can be tested, and how to test it.
• Testing not only gives you more confidence in your code, it helps you write better code in the first place.
• Testing applies everywhere, from tiny bits of code to entire architectures, assisting you in design and implementation at all scales.
• If pursued diligently, testing is an engineering discipline in its own right, with a fascinating array of tools and techniques.

Less DSA, more testing.