(Reworked on 16 Jun 2022)

I’ve been meaning to write an article about computer science fundamentals and how it can improve a programmer’s career for a long time, but I always had trouble finding a good way of introducing this topic. The reason I’d like to talk about this is first that, well, I really like this field and I feel that most of my programming ability today is a result of having studied this, but also because I feel like there’s a lot of misinformation around this topic and I’ve been hoping I could address that in a way that could be convincing even for those who can’t stand hearing the word “algorithms” anymore.

The context, for those who are unaware, is that part of the tech community despises this topic so much that they actively fight against it. The reason for that is due to how the interview process of large companies like Google is shaped; When regular-sized companies hire programmers, they usually look for people to perform a specific role on a specific platform (for example, iOS Developer). In this case, it’s very common for the interview processes to focus on the practical aspects of these platforms, such as understanding how the platform works, the details of certain APIs, and the person’s overall ability to work with that specific platform.

Traditional large companies, however, focus more on the theory of programming, asking questions not about what you can do in a specific platform, but about your understanding of the building blocks that allow such platforms to exist in the first place. This includes understanding the functionality of basic data structures like Arrays and Sets, your ability to predict, often in an academic fashion, the performance of your code, and your knowledge of fundamental algorithms like a binary search in the shape of a programming puzzle. The knowledge used in those puzzles comes from a field that has multiple names, with the most common ones being Algorithms and Data Structures and CS Fundamentals.

The thing though is that these companies tend to run puzzles that are so hard that not even extremely competent engineers are able to answer them. They often require you to have extensive knowledge of very specific pieces of theory that are almost always completely unrelated to the position being interviewed for, and while people used to be relatively unbothered by this in a past where we had way fewer layers of abstractions and the only way you could learn engineering was by going to a traditional college that would quite literally force you to study those concepts, this practice became considered unfair and outdated in the modern world where most people tend to learn from bootcamps and work with way higher layers of abstractions, and is now heavily frowned upon by the tech community.

Bruno, it looks like you agree that this is an outdated practice. So what is it that needs to be addressed?

The problem is that the community often misplaces this hate in problematic ways. The negativity around this interview format became so large that you can now often find people feeling resentment towards the theory itself, which is something that has nothing to do with obscure programming puzzles. Although on one side this is a really funny misunderstanding, this became so popular of a thing that nowadays it’s almost impossible to mention a programming concept at an abstract level without someone immediately derailing the conversation into a flame war about interview practices, which is something I believe to be hurtful not only for these conversations but also for the individual careers of engineers who are being told to stay away from this knowledge for reasons that are not logical.

I believe it’s very important for the community to separate the knowledge from the interview practices. As an attempt to solve this misunderstanding, I’d like to use this article to give you some information on what the theory is truly about. We’ll first look at a short introduction to the field of algorithms and data structures, proceed by visualizing how this knowledge is applied in practice using an analogy, use that information to clarify why large companies care about this knowledge (despite the fact that they unfortunately do it very badly), and finally wrap-up by using what we learned to see how we can write better interview processes. I hope that this will give you the tools to better separate in your head the field itself from these companies’ bad practices, allowing you to not only understand why this knowledge can be useful, but also to help you determine if this is something you should be studying to achieve your personal goals.

Separating the knowledge from the bad practices

Here are some common complaint points you hear in discussions about fundamentals:

• Theory doesn’t reflect what the person will actually do in their job.
• Knowledge of the theory is not indicative of the person’s skill in a given practical role.
• Theory, in general, is pointless. Why does an iOS developer need to know what a graph is?

People who feel this way then claim that this field is something that only academics should worry about, and practical programmers should not have to deal with this as part of their daily jobs.

I think anyone can see why someone would have these views. If you have never been introduced to this field, it can definitely look like it’s all about pieces of obscure knowledge that aren’t relevant to the actual role. They are called fundamentals, but you can learn how to code without them. Are they really that fundamental?

What’s important to be aware of is the role this knowledge plays in your programming ability. Let’s take a look at the third point again:

• Theory, in general, is pointless. Why does an iOS developer need to know what a graph is?

Many people today believe that the purpose of theory is to teach you extremely specific structures and techniques that are pointless for the majority of engineers. As mentioned before, I believe it’s imperative for you to separate the concept of programming theory from how the infamous interview processes require you to be able to recite unrelated obscure knowledge from the top of your head. This belief is popularly perceived as being true because of a misleading assumption that these are one and the same, while in reality theory has nothing to do with solving problems in obscure ways.

The role the theory plays in practice is by being a reference for someone to determine how a certain piece of code they’re writing should be designed. If this sounds familiar to you, then it’s because that’s how most of programming works! This is certainly something you do all the time, with the difference being just what you’re using as a reference. To put in other words, people don’t study generic structures and algorithms so that they can go and start literally adding them to their projects like the interview processes like to imply — they do it because most of the problems we face today are solved by writing code that is essentially an abstracted version of those same fundamentals, and being able to notice that can give you many insights on how your code can be designed and behave.

This implicitness gives people the impression that the fundamentals are useless, while in reality, they’re using them all the time! I cannot tell you how many times I’ve heard an iOS developer say “I can safely tell you that never in my job I needed to use a graph” and then proceed to happily talk about something interesting they worked with