Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

Algorithms in Interviews: Hazing Ritual or Valuable Vetting Technique?

By Joseph Pacheco on May 7, 2020

Algorithms in Interviews: Hazing Ritual or Valuable Vetting Technique?

Joseph Pacheco 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.”

Get offers from top tech companies

Take our coding quiz

Discussion

Liked what you read? Here are some of our other popular posts…

How to Pass a Programming Interview

By Ammon Bartram on Apr 29, 2020

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More

Bootcamps vs. College

By Ammon Bartram on May 19, 2016

Programming bootcamps seem to make an impossible claim. Instead of spending four years in university, they say, you can learn how to be a software engineer in a three month program. On the face of it, this sounds more like an ad for Trump University than a plausible educational model.

But this is not what we’ve found at Triplebyte. We do interviews with engineers, and match them with startups where they’ll be a good fit. Companies vary widely in what skills they look for, and by mapping these differences, we’re able to help engineers pass more interviews and find jobs they would not have found on their own. Over the last year, we’ve worked with about 100 bootcamp grads, and many have gone on to get jobs at great companies. We do our interviews blind, without knowing a candidate's background, and we regularly get through an interview and give a candidate very positive scores, only to be surprised at the end when we learn that the candidate has only been programming for 6 months.

Read More