Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

The Insanely Common Algorithms Mistake You’re Probably Making in Interviews

By Joseph Pacheco on Jun 24, 2020

The Insanely Common Algorithms Mistake You’re Probably Making in Interviews

Joseph Pacheco is a software engineer who has conducted over 1,400 technical interviews for everything from back-end 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.

There's one class of mistake I've seen more than any other in the algorithms section of the Triplebyte interview. It crushes my heart every time, because even candidates who I would personally guess understand the material lose points on a regular basis. It's not even necessarily an issue with the content itself. What I’m talking about is the use of ambiguous technical language — and it happens with algorithms constantly. Here’s how to make sure you get full credit when talking about algorithms in interviews (and also how to make sure you actually understand what you're talking about thoroughly).

Casual English + Algorithms = Disaster

Abstractions can be hard to talk about. An algorithm is not just your average thing in the world like a person or a frying pan. It’s a high-level idea that applies to a lot of different things and situations. When discussing concrete problems, it’s common to be loose with language. Words and phrases can be used interchangeably and still communicate clearly, because the context of the problem itself fills in the gaps. People still know what you’re talking about. With algorithms, vocabulary choice can make or break an answer. Each word refers to something very specific, and swapping it for another can come across as very awkward at best – or outright wrong at worst.

It may be tempting, for example, to refer to a “binary search tree” as a “binary tree.” In casual English, it’s natural to refer to something by a shortened name. In this case, however, we are talking about two different things, albeit with overlap. A binary tree is a tree such that each node has at most two children. A binary search tree, however, is a binary tree with some additional rules: Each node has at most two children, such that the left node (and every node beneath it) is less than the current node, while the right (and every node beneath it) must be greater than or equal. The additional rules of the latter make it capable of a world of additional applications than the former, and so it’s really not appropriate to use the terms interchangeably. Furthermore, “binary search” is not the same as a “binary search tree.” The former is a process that can be done without the latter. Binary search, for example, can be applied to a sorted array of data. A binary search tree is just a way of making binary search easier, effectively pre-sorting the data into a tree structure for binary search. They are, however, two distinct concepts that are, again, not interchangeable.

You need to think about the names of algorithms with the same rigor as you would name your classes in code: every character is intentional and matters for the meaning. Respecting those nuances when you think and speak about algorithms will help you at every stage of learning and with every topic. If you indulge the habits of casual conversation, it will lead to confusion and disorganized thinking about this material. All you need to do is compartmentalize. When you put your algorithms hat on, be conscious of the fact that you have to think and speak with more attention paid to the technical details and resist common language shortcuts. This will allow your algorithm knowledge to balloon into a well oiled machine of algorithmic detail.

Don't Mix and Match Terms

Now, on some level, the above examples may seem trivial. After all, an interviewer could follow-up with a clarifying question and easily discern what the candidate actually meant. But that only brushes the surface; imprecise vocabulary choice can get way more confusing. Consider the following definition of a BST:

A binary search tree is a tree such that the root has two leaves, the left less than the right.

This is a very common definition given by candidates, and it’s legitimately problematic for a few reasons. First, while the terms “node” and “vertex” can indeed refer to any item in the tree, the terms “leaf” and “root” have very specific definitions. A leaf is a node with no children, while the root is the top most node in the tree (i.e., there’s only one per tree). In this case, it’s really hard for an interviewer to determine if the candidate actually understands the concept. Many are probably just using the terms “root” and “leaf” as equivalents to “parent” and “child” respectively. That said, there are just as many who simply don’t understand the definition. We have seen candidates confirm they believe only the root has two children, or are unsure whether this constraint applies to some or all of the nodes. Some interviewers are more forgiving and may give the benefit of the doubt. Others may be legitimately confused or hold you accountable for a definition that is in fact technically wrong. It’s best to avoid the situation entirely. Always be conscious of the terms you are using both when answering a question and thinking about algorithms. If you’re unsure of a particular term, quickly Google to double-check you are using it correctly. If not, course-correct and perform this kind of house-keeping on every single term until you are up to speed.

Lack of Thoroughness ⇒ Wrongness

There’s also something else that’s wrong with that definition. Let’s swap in the correct (or at least better) vocabulary:

A binary search tree is a tree such that the parent has two children, the left less than the right.

First of all, what do we mean by the parent? Do we mean the parent of the entire tree? In that case, the term “root” would actually have been more appropriate. Do we mean “a given parent”, that is, each node in the tree that happens to be a parent? If so, which nodes are parents and which aren’t? Also, what do we mean when we say “the left less than the right”? Strictly speaking, we are saying the left node is less than the right node, which is only partially correct. What about their relationship to the parent node? It’s possible for the left node to be less than the right node while both are less than the parent node. That, however, would not be a binary search tree.

image (3).png

The point is that there is a certain level of thoroughness that needs to be reached in order for the definition of a given algorithm to be correct. And this is not just about being arbitrarily nit-picky. If you miss one of these details, then the algorithm can’t do what it was designed for. It’s like removing a line of code from a function. For a binary search tree, you need to specify details like “the parent’s value is between its two child values,” because that’s a key feature that allows it to be used for binary search. If you’re unsure whether you’ve reached the correct level of detail for a given algorithm, check a few different resources to see what’s missing. Even better, identify the purpose of the algorithm, then think through your definition. If it can’t achieve its purpose, then you have to go deeper.

Fundamental Takeaway

Candidates lose points on algorithm assessments all the time because their answers lack the correct level of precision and detail. This is so common because the rules of casual English allow for this kind of flexibility in basically every other area of communication. Taking shortcuts reduces mental burden and makes speaking feel more natural. The problem is that algorithms are structured like machines, not human minds. Their names and properties are just as rigorously defined as any piece of code. You must both speak and think about algorithms with this same level of precision. This will not only save you points in interviews, but it will markedly help your actual understanding. The more organized your algorithmic knowledge is, the more accurately you will be able to apply in interviews and anywhere else.

Get offers from top tech companies

Take our coding quiz


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

Triplebyte’s Way-Too-Long Technical Interview Prep Guide

By Triplebyte on Apr 29, 2020

A running collection of technical interview preparation resources that we've collected at Triplebyte.

Read More

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