Why several companies ask for Computer Science fundamentals in job interviews — and why a programmer should care about those
By just googling “programming interview questions”, one can get a ton of resources about questions that usually apply to most interviewing process. Data structure questions, algorithm complexity (the infamous “Big O notation”), system fundamentals and paradigm principles (usually Object Orientation patterns and best practices — since most of the jobs nowadays are to develop OO-based systems).
However (and I confess that I had a certain level of astonishment when I first saw it) it’s very common that people applying for those jobs complain on social media about the amount of effort needed to learn these, according to them, “useless concepts”. It seems to me people miss the point on the importance of this, and that leads to this type of confusion. Then, after reading the tenth complain about this type of interview requirement, I decided to write down the reasoning behind. Usually materials on the Internet focus on how to be succeeded in programming interviews, but I don’t know a structured definition of why they are like that, and why they’re efficient on getting good programmers.
First, however, the “how”: what are we talking about when we say “Computer Science fundamentals”?
Everybody that prepared himself for a developer interview with a little care heard about “Cracking the Coding Interview”, a book designed as a guide for self-study when preparing yourself for acing programming interviews and getting hired. Even new Engineering Managers, Tech Recruiters and the like tend to rely on those ideas to form their recruiting processes (which makes the book content, at worst case scenario, a “self-fulfilling profecy”). If we look at its table of contents, it basically lists the basics needed for a coding interview — which can be grouped in the following structure:
- Big O notation (Time complexity, space complexity, log(n) runtimes, recursive runtimes)
- Data structures (Arrays, strings, linked lists, stacks, queues, trees and graphs)
- Algorithmic problem solving (Solving techniques, best conceivable runtime, good coding organization, bit manipulation, math/logic puzzles, recursion, dynamic programming, sorting and searching, language-specific optimizations)
- Systems architecture (object-oriented design, testing — including scalability and memory limits — , databases, threads and locks)
This is a very good summary of things people look in the coding interviews. One could argue it’s more and more common to talk specifically about Design Patterns and OO architectural concepts like GRASP and SOLID, but I‘m assuming this under “object-oriented design” — although the book doesn’t cover this in a deep enough level, in my opinion.
OK, but why is this important?
The main point the people who complain about these steps in recruiting processes seem to miss is that those things are being evaluated for a reason. Of course this doesn’t happen because these people are “stupid” (which is a wording that doesn’t even make sense), but because they’re just evaluating from the perspective of their previous jobs.
The reasoning behind these four pillars are different, but nonetheless fundamental for that. Let’s discuss the practical perspective of those. Just be aware that, to measure importance of a knowledge/ability to a programmer, we need to remember that a programmer job is basically measured by three drivers: speed of delivery, quality of code delivered, and level of innovation inside the code.
Big O Notation
Algorithm complexity is the nightmare of most undergrad students. When I taught this class in the two Universities I worked as a professor, for many years I was frustrated by the fact that, no matter how better my indexes were, the approval rate of those classes were never higher than 60% (which was way better than the 20–30% rate of several of my colleagues, but still far for what I considered ideal). I raised these numbers basically bringing more practical examples and usages to the classroom discussions. In the industry, I often hear from people that “I didn’t know how useful this is until working in this project/company”, and that “University professors should approach this in a more practical sense in the classroom” — which I agree, but goes beyond the point of this argument.
And be aware: no one in the industry is going to ask you to write a report proving that sorting is Omega(n.log(n)) by 5pm on their desk. However, understanding what does it mean in terms of computing time that an method “is” O(n), and what does imply calling it O(n²) times, leads to better development decisions — and not knowing it implies on losing time finding why your app is so slow before fixing it.
This complete understanding of complexity — and hence efficiency — is particularly important for two different reasons. One, the amount of data we’re processing these days. There is virtually no software product nowadays that doesn’t evaluate and interpret a ton amount of information, and then efficiency starts to become more and more important on all the data manipulation projects around this product. On top of that, we have nowadays more and more smaller computers being available at cheaper and cheaper prices (and cheaper specs) — we call them “cell phones” — , and those need to have more efficient apps or they won’t run.
Knowing the fundamentals behind algorithm efficiency measurement makes your decisions while programming better — and by that your development delivery with better quality and speed.
Data Structures
Data structures are basically the way we use to organize data inside our code. From the simplest array of integers anyone learns in a 101 class, to non-linear trees with variable amount of children and non-obvious operations to ensure an apparent arbitrary definition of balance, there is virtually no application that doesn’t rely on those.
The usual argument I hear against we covering this knowledge in interviews is that all common data structures are already implemented in all major languages (which is true). The reason why we need to understand how they internally work is similar, in the sense that by knowing that we can make better decisions — and even implement those concepts in an environment where the data is not structured the way the default implementations need, or using partially the concept (or it correctly).
Imagine, for instance, you have a situation where you need a data structure that removes the three smallest indexes at every operation. Of course a min-heap should show in your mind as a possible solution to the problem (if this wasn’t obvious for you, then my argument on why you should study data structures is simpler: you don’t think of a min-heap even in the classical example of “a data structure that removes the smallest element”). However, one question arises: should I store the elements as triplets, or should I call removing one element three times when I need to remove them all? If storing as triplets, how to ensure that the three in the top are the smallest? Is there any other data structure that solves this problem better — an innovation that could deliver code with better quality?
Of course, one could counter-argue here by stating: “OK, I need to know how it works internally, but why do I need to implement this during an interview?”. Well, if you can’t deliver algorithms you know fast enough (and “enough” here depends on the business of the company, the tech stack, the seniority level et cetera, of course), that’s a common indicator that you can’t deliver with enough speed.
Algorithmic problem solving
This one is pretty straightforward, and I see less people complaining about it. If you’re going to work as a programmer, one needs to know how to write code to solve problems correctly and efficient (to provide quality) and preferably quick enough (to provide speed).
One thing that people complain about this type of assessment in hiring interviews, however, is that for some problems one apparently need to “find the trick”, like it was a lucky guess or something. It can be, but it’s virtually impossible to be lucky enough in all projects (and that’s one reason that makes recruiting processes to have multiple steps — but this is a subject for another text).
But, if it’s not luck, what are we measuring? The ability to solve this type of problem. The main result we can get from a challenge question is how quick can the person deliver the result using techniques that we usually do in actual projects. So, it is something that comes with ability, but also experience on solving analogue problems (and, depending on the seniority of the job role, finding this ability is way more relevant than considering things like amount of years that the person works in a similar role — because the role naming changes significantly from company to company, and sometimes a “mid developer” in one company is way more senior than a “senior developer” in another company).
Systems Architecture
At this point, I believe most people understand why we do architectural tests in tech hiring interviews. All of those things before are important, but no one makes sense if a code in the end looks unintelligible and hard to maintain/update (reducing the speed of the whole team, not just the developer who made it).
This, however, has a catch: the ideal way of testing this is to ask to implement a full project, and this has a few problems. First of all, it takes too much time; second, it takes too much toll of the candidates, along with making the recruiting process way longer. So, some people ask for a prototype (and “pay the cost” of having an extra week just to check the results — and the refusal of some candidates that are in multiple processes), some limit this to check the knowledge of the fundamentals in an interview. That’s why having a good knowledge of the fundamentals, the jargon and the definitions is paramount to have success in this type of evaluation.
But should everyone follow this rules?
The answer, straightforward and for both “sides”, is no. But, in different perspectives, there’s a price to pay in choosing going away with that.
Candidates: a recruiting process is also a place for you to choose where to work
The world is huge. I see so many developers firmly believing that the industry has just the size of their personal experiences. My main motivation in writing this post was a guy on LinkedIn that, frustrated he didn’t passed in a FAANG recruiting process (welcome to the club, bro), decided that their process was “unreal” because, among other reasons, “no one uses Big O notation in the actual world” — which is not just plain false, but very naive.
Particularly, be aware about what does it mean to be a “senior developer” in a company, and understand that some companies call “senior” what other companies would call a “junior” — i.e., there’s no standardization of roles. Also, time matters little. I remember interviewing a guy with 12 years of experience in development, using the same tech stack I was looking for. Great communication, great energy, until we got to the technical questions. He said to me “I never used this type of things in my current job”. I could offer a junior position, but the salary wouldn’t make sense to him, so we thanked each other for their time, and moved on.
On top of that, if there’s something in the above list you simply don’t want to learn, there will still be some jobs for you. For instance, you really don’t need Big O notation if all you’re doing are (fancy) CRUD systems, and there are several companies hiring to do fancy CRUD systems. Just accept some of the jobs available are not for you. You decide what barriers make sense to overcome, which ones make sense to leave there. Don’t fall for the foolish advice of overcoming all barriers. There’s no right or wrong here.
And, in the end, realize this: most of the people “on the other side of the table” are doing their best to hire great people as soon as possible. There are some ill-intended people, of course, but most of them are just looking for a new colleague to add to the team. I was talking to a mentoree once, and he said that the recruiting processes in Europe where “designed for people to fail”. This simply doesn’t make sense, and just five minutes later with a conversation similar to this he realized that. Of course, if somebody has the expectations of hiring a very senior person with a very small salary, it will be hard to accomplish — but if the company is hiring and bringing new developers (which you can check with a very simple LinkedIn search), then they’re finding what they’re looking for.
Recruiters/Managers: make sure you fit whatever you need to evaluate in the smallest time possible — and no less than that
I work as a consultant for recruiting processes and team performance evaluation for more than a decade now (and my first experience as a team manager comes back to 2005). The main mistake I see people make is that they simply apply so-called “industry standards” in the recruiting process, without looking at the particularities of the company, the process, and the role needed.
We can shorten the time of a recruiting process whenever we find multiple things we can evaluate in each step of the process. Also, every step of the recruiting process should have a set of objective goals to reach, so it’s very clear what you should consider as a green flag and a red flag.
Also, be aware of the importance of evaluating tech skills as soon as possible — but I could never talk this better than Joel Spolsky and Jeff Atwood already did, so just go there and read their essays, they’re gold.
Of course, on top of the technical interviews, many other things should be considered, from basic soft-skills to cultural fit — but this is probably a topic for another text.
This is my first attempt writing a text in Medium. I believe it’s visible English is not my first language, and my main motivation here is also practice my writing. Please let me know any new topics related to work, employment, management and team evaluation, that you would like me to talk about. And I really appreciate the sharing.