I recently had an interview for a DevOps role in which I was asked the following: what is the runtime of insertion into a heap? The answer, for the record, is O(log n), but I have a more important answer, which is: who cares?

It’s already well known that a computer science degree often has little to do with software engineering (which makes one question the value of a CS degree for most people who get one). Few courses in a traditional CS program are devoted to skills and tools that are actually useful in the industry; far more are devoted to skills and tools that appear on interviews, which can often end up being trivia competitions. In that case, then, is a CS degree just a degree in interview preparedness? I wouldn’t go quite that far, as the latter half of a CS degree (in my experience, a limited sample size of 1) tends to focus on more specialized (and industry-relevant) skills, while the former half tends to focus on the fundamentals of programming. Still, there is a huge disconnect between the degree and the practice; at the end of the day, a CS degree is essentially a theoretical math degree (for more on this, see this essay or this one).

So, back to that interview question. To all the software engineers reading this, let me ask you: when did the success of your work depend upon you remembering the runtime of an operation upon a data structure? When you, for whatever reason, had to work based on the runtime of some operation, I’ll bet you googled it. And that’s good! That’s nothing to be ashamed of. Programming is a field built upon the shoulders of those who came before us. There is no need to reinvent the wheel; when you need to use a priority queue, why make a min heap-based implementation yourself? That’s not efficient, it’s not intelligent. Almost no one writes their own assembler anymore; and why would you? When I’m making an application, I don’t start by writing my own kernel and building an OS. I use the already extant tools. My favorite shell command is man, because I can generally figure out whatever I need to know with that. So what if I can’t remember the thousand different flags you can pass grep? Man will tell me.

So: why ask interview questions about data structures? What purpose does it serve? If your questions can be answered by a single google search, they probably aren’t good questions. On another note, why ask a devops engineer in particular a question like that? When are you going to implement a heap in Terraform, or in a Jenkins CI/CD pipeline? What does that actually test?

Needless to say, I didn’t get the job.

For my current role, I won’t give specifics, but I had, easily, the best interviews I’ve ever had. I met the people I now work with, talked about some ways we could make things better, and moved on from there. We didn’t talk about algorithm runtimes. We didn’t talk about data structures. We talked about problems actually germane to the job.

And as a result? I’m excited to start work.