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.

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.