Algorithm Interviews Don't Make Sense

Rule 5. Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. — Rob Pike

Rule 5 is often shortened to “write stupid code that uses smart objects”.

Given all the importance that algorithms get in the news, movies, TV series, and coding interviews, one would think that the job of a programmer consists mostly on knowing and implementing algorithms. Perhaps with small modifications to make them faster or get them to fit to the current problem being solved. But this is far from the truth. A coder’s main job is to model the slice of reality in question and decide how to structure the data properly for the job. Once the data is stored and structured, both in long and short-term memory -variables and databases-, what is left is choosing the right algorithms. Often, there is no need to write a new algorithm. And, of course, it’s never needed to memorize its implementation.

I will give some rough estimates. Outsiders believe that when programmers think about how to write a program, they focus 90% on the processing of data (algorithm) and 10% on how the data will be modeled (data structures, database design, etc). But competent programmers spend more like 90% on choosing and designing data structures to hold the data in a way that’s both easy to process for the computer and easy to understand for humans. Well, actually, not for humans but for other coders, or for themselves in the future.

In 1970, Edgar Frank “Ted” Codd invented the relational database while working for IBM. It allows to store information structured in tables (columns and row) with keys that can link to other tables creating relationships between tables. Over 50 years later, it’s still the most popular way to store data in software. How the programmers design (and name) the database dictates what data it is possible to store, which in turn determines what the algorithms can do when they process said data. But database design also matters because, when the tables are well-defined, they are easier to reason about, leading to fewer errors. For example, if I have a table full of users and I call it “people”, and then I add the table “customers”… well, aren’t they people too? You can see that this can quickly become messy. Programmers still spend large swaths of time designing database schemas. Often times it’s worth it.

So why do interview questions focus so much on implementing algorithms? My theory: because getting algorithms to work is hard, so you get stronger filter. This is also the reason you should avoid trying to re-implement them manually. One common internet meme is that Google often asks their candidates to “invert a binary tree”, that is, to write the algorithm to go from one data structure to another. It’s not important whether Google is still doing this sort of questions, the fact is that many companies are, and it has little to do with what the job requires. What the job requires is often figuring out that using a binary tree is a wise choice for the kind of data being handled, and then looking up how to reverse it if needed. System design is more important than memorizing trivia questions.

I’m not saying that interviewing for data structure knowledge will yield better results, but at least it would be more aligned with the job requirements. I have seen programmers who like writing algorithms from scratch a little too much and end up creating complex data structures, which they then parse with more complex algorithms.

Granted, software developers sometimes have to write custom code for algorithms, or even invent new ones. For example, if they work with lower-level languages and need to speed things up, or if they are doing something avant-garde. The vast majority of programmers, though, should focus on keeping their algorithms very simple. If I start coding and I see things are getting complex, I try to spend more time on the design phase and there’s usually a solution that doesn’t involve re-writing an algorithm.

Understanding that system modelling is more important than writing code matters especially now. A common misconception is that of the key activity of software developers is to write code. If that is the case, they can be quickly replaced by LLMs such as Claude and ChatGPT, which can write code faster. But the job, especially at the higher levels, is more about designing the system and deciding exactly how it should behave given the ever-present pull of requirements and constraints. If you can do this properly, you will have to write to less code, and maybe you won’t even have to invert that binary tree.