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.

## 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.

# The insanely common algorithms mistake you’re probably making in interviews

Key Results

Using ambiguous technical language when talking algorithms in interviews can zap a lot of your credibility.

## Introduction

,

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.

## 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.

## Book a demo to start reviewing top engineering candidates today.

Get started hiring great software engineers with Triplebyte now