Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

Confused by Algorithms? Introducing ‘Math Speak’: The Secret Language Nobody Told You About

By Joseph Pacheco on May 21, 2020

Confused by Algorithms? Introducing ‘Math Speak’: The Secret Language Nobody Told You About

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.

Algorithms have a steep learning curve — so the story goes. This isn’t because algorithms are inherently hard. They’re just couched in stuffy, academic language that’s akin to humans trying to make sense of assembly code. This article is about understanding the basics of that stuffy language, what I call “Math Speak,” so you can finally make progress. It’s like a secret handshake all the algorithms wiz-kids know that nobody thinks to share explicitly. Once you’ve internalized it, studying for interviews is going to feel a heck of a lot smoother.

Here’s Why You’re Confused

Here’s the good news: Math Speak isn’t actually that hard to understand. And if the math and CS worlds were better at teaching, this article wouldn’t be necessary. But don’t take my word for it. Dr. Leslie Lamport (the 2013 Turing Award winner) explains:

Why is 'two plus two equals four' considered simple but a logical operation like 'an element of' is hard to understand for most people? ...Why should 'element of' seem frightening when 'plus' seems so easy? It's just a matter of not being familiar with it, and this is not all your own fault—mathematicians are terrible at teaching it.

To walk you through a full example of this language at work in algorithms, let’s take a look at the Algorithm Design Manual by Steven S. Skiena, one of my favorite resources. Consider the following excerpt on graphs:

Graphs are one of the unifying themes of computer science — an abstract representation that describes the organization of transportation systems, human interactions, and telecommunication networks. That so many different structures can be modeled using a single formalism is a source of great power to the educated programmer.

Based on this, you might be wondering what they even mean by “graph.” This doesn’t sound like any graph most of us have ever seen, namely one with an x-axis, a y-axis, and a plot of values. Turns out, it’s related (but only distantly). It’s best to think of this as a whole other perspective on the term “graph” that has little to do with the definition we’re all familiar with. Skiena continues:

More precisely, a graph G = (V, E) consists of a set of vertices V together with a set E of vertex pairs or edges. Graphs are important because they can be used to represent essentially any relationship. For example, graphs can model a network of roads, with cities as vertices and roads between cities as edges... Electronic circuits can also be modeled as graphs, with junctions as vertices and components as edges.

Now while that may make graphs seem like impressive things, there’s only one sentence in this entire introduction that defines a graph itself:

...a graph G = (V, E) consists of a set of vertices V together with a set E of vertex pairs or edges.

If you’re struggling to make sense of that, you’re not alone. In order to get anything from this book, you need to already have an understanding of the language that mathematicians and computer scientists use to discuss these kinds of formal concepts. And though courses like Discrete Math exist in CS degree programs, I've seen first-hand how even those supposed entry level curricula can gloss over the entire idea of explaining Math Speak ... and get right into using it to confuse you. We don’t expect high school freshmen to read the Odyssey in Greek without learning the language, but we expect CS students and self-taught coders who want to pick up algorithms to read things like the above without teaching them the basics of Math Speak.

Here’s How Math Speak Works

Math Speak is just a way to describe concepts purely in terms of other mathematical (or CS) concepts. To understand something like a graph in CS, you just need to understand the other ideas being referenced. Skiena’s definition is given in terms of mathematical sets. A set is just a collection of distinct items, and, according to this definition, a graph is just a thing that consists of two such sets: one of “vertices” and one of “edges”. This math-style definition can be represented visually like so:

image (2).png

A vertex (singular of vertices and also known as a “node”) is just a fancy way of referring to a thing in a graph, and an edge is just a relationship between two of these things. These things can be pretty much whatever data point you want: numbers, people, words, locations on a map, ideas, etc. Likewise, the “relationships” between them can be whatever is meaningful for what we want to represent with the graph. For example, we could have a graph where the vertices/nodes are cities and the edges/relationships are the distances between those cities. Let’s update our visual to represent this example:

image (1).png

If you think about it, this makes a lot of sense. When we want to see how a bunch of things relate to one another, we use a graph. The graph consists of the things themselves along with the ways they do in fact relate to one another. It’s really that simple. It just sounds weird upon first glance because of the math-style way we talk about it. This style is really just closer to how we might represent a graph in code (e.g. an array of things and an array of relationships). But it does feel a bit robotic to think of something so simple in terms of distinct sets, which is why we usually represent graphs visually as follows:

image.png

This gets right to the point by focusing on the things and their relationships in a much more intuitive way. But it is nonetheless the exact same thing: a set of vertices in blue and a set of relationships in red. And there you have it, something that at first seemed esoteric, but which is in fact nothing more than common sense.

Here’s How Math Speak Is Written

Now, there is an additional layer that trips people up: how this is all written. You may also have noticed what appear to be functions and variables thrown into the graph definition. Math Speak has this habit of adding labels to each of the things it’s talking about. The labels tend to be single letters (but not always), and introduced immediately after the thing being discussed is introduced. For example, after “a set of vertices” is mentioned, the label “V” is immediately inserted as a shorthand for that set of vertices. This peppering of additional detail can make it hard to parse sentences in math speak, but one does eventually get used to it. If your brain shuts down on contact (like mine used to), try to read the sentence first without the labels so its more like natural English.

Annotation 2020-05-21 210148.png

Sometimes, the labels can be a bit more complex. For example, after “a graph” is introduced, it is followed by “G = (V, E)”. This is just a mathematical way of labeling the graph and then giving more detail about what it is. “G” is the single-letter label for some graph we have in mind, while “(V, E)” is what the graph consists of. The fact that “V” and “E” are in parentheses together simply means the thing represented by “V” and the thing represented by “E” are part of the same overall thing (in this case, the graph). Again, it's a whole lot of complexity that means something very simple. The labels are just there to create a shorthand for referencing each thing later.

Key Insight: Comment Algorithms Like Code

Math Speak is great for encapsulating a ton of information in really concise, ultra-precise language, but which is anything but intuitive at first. When you encounter it, you have to translate and expand it into more natural, readable terms. Think of this like writing good comments for your code. Every line of code does something, but describing it in paragraph form is often critical for making sense of what it actually does. Do this for every algorithmic topic you encounter, and even the most high-minded books and advanced topics will start to seem a lot less scary — because you’ll finally be able to see them for what they actually are.

The bottom line: Do not be intimidated by stuffy, academic, math-style language when studying algorithms. It sounds like it was written by robots for robots, but once you understand the basic rules (and build some habits with them), everything will start to make a lot more sense. It’s well within your reach to understand.

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