SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

What Data Structures Should You Know as a Developer or Software Engineer?

There are many data structure across the whole of computer science. As a developer, you only use a small handful for the majority of your work. A large handful are important enough to know about off the top of your head. The majority can be considered exotic and can be looked up when you need to.

This is a list trying to answer the question “What Data Structures Should You Know?” by bucketing them into roughly the categories above.

Caveats

This is a general recommendation based on decades of engineering experience across a wide array of fields and industries, from semi-conductor to healthcare. Your industry will have different priorities. Graphs and ZDDs/BDDs become more important in if you work with maps, geo-coordinates, etc.

In some languages, certain data structures are more important. If your language’s native, internal implementation of an “array” is a linked list, you better know that linked lists take a relatively long time to count the elements in it.

As a hiring manager, Senior engineers typically shift up a level. the Must Knows become “Know it like I know how to spell my name” and the Should Knows become Must knows. For Hobbyists or Early Career Engineers the should knows tend to be more of a Lookup When You Need It. The Must Knows are always Must Knows. At any level, there is nothing that will disqualify you faster in a technical interview than using an array when you should be using a map.

This list is primarily geared towards getting day to day work done as an average engineer. It is unfortunately not sufficient for interviewing. Interviews are broken. If a company asks you to implement a red-black tree from scratch, I hope you are interviewing to work on complier or database internals or something, because that is rarely a useful question to ask.

The List

Lastly, when we say “know” we don’t mean you need to know how to implement them from scratch. 1

Here are the general guidelines (barring any job/industry specific requirements):

Must Know

“Know” means you should understand how they are used, what kind of problems they solve and have a rough sense of big O for time/memory/space for typical activities such as insertion, removal, retreival, search, etc.

Should Be Familiar With

“Be Familiar With” is having an understanding of the basic usage and properties of a given data structure. For example, Being Familiar With a stack mean a simple understanding of how a it works (LIFO array) and that push and pop are O(1) operations.

Most of the items in the “Be Familiar With” category aren’t that common with respect to day to day usage, but are fairly important when you need them. As a homeowner, you may not use a vice or clamp that often, but there aren’t a lot of good options if you really need one. It’s also likely that they are used under the hood of much of the tools and libraries you do use often.2

Lookup When You Need It

  • sorted/weighted variants/alternatives to any of the above
  • crypto
  • CRDTs
  • exotic tree varaints
  • Tries
  • Specific types of Graphs
    • Binary Decision Diagrams
    • DAGs (Directed acyclic graphs)

You may have noticed that the Caveat section is longer than the list itself. It’s quite subjective, but I’ve tried to focus on doing day to day engineering work. Feel free to hit me up on twitter @amattn if you have any feedback or suggestions.


Footnotes:

  1. It must be said however, that implementing a data structure from scratch is one of the best ways to learn that data structure.
  2. In the words of a dear friend, these are “shit you’ll use occasionally but damn well better understand because they’re not that complicated and are conceptual underpinnings of so much important shit”.


in lieu of comments, you should follow me on twitter at twitter/amattn and on twitch.tv at twitch.tv/amattn. I'm happy to chat about content here anytime.


the fine print:
aboutarchivetwittertwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2021 / all rights reserved