This article first appeared on the Triplebyte blog and was written by Joseph Pacheco. Joseph is a software engineer who has conducted over 1,400 technical interviews for everything from backend, to mobile, to low-level systems, and beyond. He’s seen every quirk, hiccup, and one-of-a-kind strength you can think of and wants to share what he’s learned to help engineers grow.
Academic algorithms tests on interviews can really put people off. Their presence is often considered a pointless hurdle, a relic of a bygone era of traditional testing techniques that are no longer relevant. And with the rise of bootcamps and other resources, an ever-increasing number of engineers lack a traditional computer science (CS) background. So why do companies rely on them so heavily? Here are a few reasons that might surprise you.
It’s Not About Reinventing the Wheel
Before we get to the juicy stuff, we need to address the elephant in the room: Companies don’t ask you to implement a BFS because they expect you to do so on the job. They know most programmers don’t touch academic data structures and algorithms on a daily basis. Every modern programming language in the world has marvelously crafted performant implementations of pretty much anything you can think of at your disposal. Except in rare, niche circumstances, you are never going to implement a binary search tree from scratch as part of production code. In fact, you’d be a fool to do so. Reinventing the wheel is a waste. It’s inimical to productive, high-value software engineering. We’re all on the same page about this.
They’re a Lingua Franca
Candidates come from myriad backgrounds. They have differing strengths and know a breadth of differing technologies. The one common denominator among most candidates is CS fundamentals. They offer a structured, widely available universe of knowledge that acts as a microcosm of software problem-solving. At the very least, companies need to know you can solve problems, and academic algorithms can test that very effectively. Using this material as a base, interviewers can create problems of limited, digestible scope that require zero knowledge of any particular platform, technology, or engineering philosophy. And even if you’ve never been in a CS class, it’s something you can pick up (and easier than you think – Triplebyte has put together some free algorithm educational resources to check out here.
In a way, this actually creates a level playing field. It allows interviewers to wade through the noise and get a look at how different people solve exactly the same problems. It’s by no means without limitations, but it’s amazingly convenient that the same exact material can reveal strengths in candidates with wildly different backgrounds.
They Test for Intellectual Elasticity
Besides, companies are often not interested in candidates who only know and care about one thing. They want to see flexibility in the breadth of material you can tackle as business needs change and technologies evolve. Academic algorithms are often outside the scope of your daily routine – something you don’t specialize in. If you can master them, and keep that skill fresh, it’s not crazy to think you can master other things outside of your comfort zone. At any point, changes in the market could demand a paradigm shift in the way you’re approaching a project or some novel approach for a sneaky problem only your users have encountered. The more you can take a step back and utilize every possible resource or path, the more you can deliver results.
They Make You a Better Engineer
When it comes to algorithms, nuance matters a lot. Engineers who notice these nuances and manage them correctly tend to notice nuances in other areas of engineering. And this might indicate an ability to avoid the kinds of mistakes that can arise from less organized technical thinking. While that’s obviously helpful for companies looking to build great teams, it’s also convenient that simply learning this material can help you become more precise in your own thinking. It’s a two-way street that helps you just as much (if not more).
Aside from that, they force you to think about efficiency and space. Of course, some companies will need you to be highly conscious of this depending on what you’re doing, particularly the mammoth companies that build all their tools from scratch. But even if your specialty doesn’t usually demand this kind of thinking, it has unexpected, positive side-effects on the way you write code. Let’s say you’re a mobile developer. Most of the time, you don’t even deal with data large enough to have to worry about efficiency. Brute force is fine most of the time. But suddenly, you’re getting reports that your app is crashing. Having even a rough understanding of time and space complexity, particularly how they apply to the foundational data structures on your system, could save hours of downtime and your app’s reputation. The academic stuff, while it may seem far off and distantly relevant, has this way of being useful when you least expect it.
They Even Reveal Character
A candidate’s reaction to being asked algorithms questions can also be very revealing. It is baffling how many think it’s a good idea to lecture their interviewer on the pointlessness of asking one question or another, and that often comes up during algorithms assessments because of their controversial nature. Being unwilling to accept the situation for what it is says a lot about how you will carry yourself on the job. Are you going to be a team player, or are you going to dig in your heels when your ego has been hurt? Are you going to do what’s needed to solve problems, or complain about why those problems shouldn’t be happening? It’s natural to feel resistance when you think your dignity is being threatened. It’s also natural to push back against inefficiency and indeed noble to fight for optimization. But don’t forget how important it is to exercise a habit of humility and be willing to assume best intentions.
Embrace What Is
In lieu of a more sophisticated way of measuring your technical strengths directly — which, by the way, Triplebyte happens to be working on — algorithm tests can be great and highly accessible ways to peer into key skills in a structured, replicable manner. And for the foreseeable future, they aren’t going anywhere. Even Triplebyte’s CEO agrees:
I fundamentally do not believe that good programmers should have to learn special interviewing skills to do well on interviews. But the status quo is what it is ... A startlingly high percentage of interview questions reduce to breadth-first search or the use of a hash table to count uniques. You need to be able to write a BFS cold, and you need to understand how a hash table is implemented.
The interview algorithm testing process is far from ideal, but it’s also not pointless. Attempting to see how it might be valuable, even advantageous with the right mindset, will help you get the jobs you really want. In the words of Marcus Aurelius, “What stands in the way becomes the way.” And even better stated by Ryan Holiday, “The obstacle is the way.”
Triplebyte helps engineers assess and showcase their technical skills and connects them with great opportunities. You can get started here.
Top comments (9)
How about we explore a bit the other side: what do those pesky devs who "lecture their interviewer" think about the pointless tests you guys are promoting at Triplebyte?
Well, then why are you checking if someone is able to reinvent the wheel in the first place?
Yeah, but you're hiring for a specific position. What you should really care about is if the candidate is able to do his/her daily tasks and how much value it brings to your customer's (or your own) company. This goes triple for seniors. More than that, writing competition-like algorithms and writing real life programs are two very different things. You can excel at one and be mediocre or worse at the other.
So does learning this by heart: Advanced Programming in the UNIX Environment. Should we do that, too? 3rd edition is only 1000 pages long.
Thing is, in the unlikely event (s)he'll ever need to implement a state of the art algorithm, (s)he'll research it first. That's how all of this works in real life. Here's an idea for Triplebyte: how about you test the ability of reading and understanding documentation at different levels? That would actually be valuable.
I agree. If I'd interview someone and he/she wouldn't object being asked pointless questions, I'd be disappointed. I don't know about you guys, but I like to work with productive/proactive/ people not with zealots or robots. You know, people that actually bring value to my company.
Unfortunately, even large companies take this path sometimes. In 2015 Max Howell, the creator of Homebrew was rejected by Google because he was not able to revert a graph on a whiteboard.
This guy built a fully functional, highly efficient package manager. No, he built the package manager for macOS. Let that sink in.
This practice needs to stop and I advise prospective candidates to think twice before applying to any company that throws a low-effort quiz as the first step in their selection process. It just shows how much the interviewer prepared for the interview (yes, surprise, as an interviewer you need to prepare as well)
You got a point on the cases that require a candidate to play with things that'll never be relevant on the job, but I also see many developers simply unaware of complexity (big-O), CPU and memory-wise, which can seriously harm a product after MVP phase and broad adoption.
These problems are addressed by classic algorithms and, in this sense, they are much useful skills.
This comment is the best thing about this article.
... because we've allowed it to become what it is.
Leetcode is the industry standard because developers continue to humor this stupid hazing ritual. That is what it is.
Let's not pretend that real-world developers don't spend 75% of their time Googling how to do X on the job.
Let me use Google on a technical interview if you actually want to test my ability to solve problems in the real world. That's what your developers are going to be doing day in and day out. They're not going to be regurgitating D&S textbooks for brownie points.
"Oh, you had to Google that? I have my entire D&S lecture notes memorized."
Companies (unicorns in particular) rarely do let you use resources during a tech interview. They're looking to see if you're willing to endure the Leetcode grind. If you are, great! You're more than ready to become yet another cog in the FAANG wheel.
Especially if you frequently move from project-to-project and language/framework-to-language/framework, you now how to solve the problem but you probably need a refresher on the specifics of how to implement it in the language or framework you're being asked to use. Let's face it: if you didn't know how to solve the problem, any useful Google searche-results would be nearly blind-luck.
Asking about BFS is cool for new grads. My first interview, I got among other things a cute IQ test which was pretty fun since I do enjoy puzzle games. Apparently other candidates voiced the absurdity of the test, which I guess proves a point of their character? It's a fun test why be so serious right?
For professionals in the industry who probably worked on massive code bases or contributed to billion dollar companies? I don't know, I'd feel like the interviewer didn't do their homework when they called them in for an interview lol
I mean I guess if they aren't really the right fit, they can go right on to the competitors or something.
I rather agree with @rad_val_ and @aleksandrhovhannisyan comments than with the article itself.
I have faced the algorithm question at two interviews and both times failed it after 40+ minutes, because guess what? I'm self-taught. And at that time it almost gave me an impostor syndrome. Despite my previous experience. So thanks for that.
I tried to go and solve challenges on leetcode, hackerrank and other sites. No luck - easy and medium level is somewhat solvable, but hard ones are insane. I started to think "Maybe developing isn't my thing? Or I'm a trash web monkey?". Luckily I believed in myself and still happily coding.
And now I can't think anything but "Do you really solve those kind of problems as daily tasks?" about algorithm-question-interview companies. And if so, then I'll pass. If not, then like, seriously, why on Earth would you ask me that? And not one of six paragraphs in this article answers that question.
Cool article.
Cool, awesome article.