Technical Interviews, Part 1: Knowledge

Technical interviews can be daunting, especially if you’re new to the process. I remember being flustered in my first few interviews—I had no idea what to expect and I sometimes didn’t understand what my interviewer was looking for. Now that I’ve been on both sides of a few dozen interviews, I’m hoping to share some advice so that you won’t need to make as many mistakes as I did.

In this three part series, we’ll go over a high-level overview of what you should expect during a technical interview. The aim of these posts is to give you some familiarity with software engineering interviews. Hopefully, some insight into what we expect as interviewers will help you be more comfortable. Additionally, you can figure out what you might want to brush up on before an interview.

As a disclaimer, these posts are largely based on the interview process here at Yext. There might be some differences between the process and topics described in these posts and the process and topics you’ll encounter in interviews with other companies. Still, regardless of where you interview, we hope you’ll be able to find something useful.

Let’s get started!


In today’s post, we’ll first cover knowledge—the various topics you’ll need to be familiar with coming into an interview.

The first and most important thing that we want to see in a candidate is how knowledgeable they are. We want to see that you know your basics. Ideally, we want to see that you have a variety of tools in your software engineering toolbox and that you know how to use each tool.

For an entry-level engineer, this will mostly involve knowing about data structures and algorithms. These topics are typically presented in algorithms classes.

Data Structures

First up, data structures. An understanding of data structures is crucial for good programming, and almost every interview question you’ll get will use a data structure. Commonly, solving an interview problem will require understanding and/or tweaking a data structure.

The main data structures you’ll use are lists, maps, sets, and trees. Sometimes you’ll use stacks, queues, or some other data structure. However, these less common structures can usually be represented by modifying one of the main data structures.

Naturally, the important part about these data structures are their properties. Or more precisely, how their properties differ. Multiple data structures can often serve the same purpose, but a particular data structure is often the most suitable. Bowls and bathtubs both hold liquids, but you wouldn’t eat soup from a bathtub or take a bath in a bowl. Choose appropriate data structures!

As a simple example, lists store duplicate entries while sets do not. If we wanted to know how many times we needed to roll a die before rolling the number 5, a list would be more suitable. If we wanted to know how many different values we rolled before rolling the number 5, a set would be more suitable. In both cases we can store all of our rolls in the chosen data structure, but the information we get back differs based on the choice of structure.

Make sure you know the common operations for each data structure—typically search, insertion, deletion, and (depending on the structure) sorting. You should have an understanding of both the complexity of these operations as well as how you might implement each operation. These operations differ between data structures, and even between different implementations of the same structure—such as between an ArrayList and a LinkedList in Java.


Before we can talk about algorithms, we have to talk about complexity. Complexity is the metric we use to determine how good an algorithm is; you should know how to determine the complexity of any algorithm or piece of code that you write.

The language we use to describe complexity is Big O notation. Typically, algorithms classes ask you to compute the complexity of various snippets of code with respect to an abstract variable or argument.

When calculating complexity for interview questions, you need to be able to specify which input(s) are being used to determine complexity. That is, you’ll still describe an algorithm as O(n), O(n^2), etc., but you need to also specify what n is.

This is usually intuitive; it’s often specified in the problem. It’s worth noting that this unit doesn’t have to be a primitive (like a char) or a typical computer-related unit (like a kilobyte). For example, if I wanted to talk about how big a book is or how quickly I could read it, I might talk about complexity in terms of the number of pages in the book.

Most candidates are familiar with determining complexity when it comes to classifying how long an algorithm takes to run. However, we can also talk about space complexity—the amount of memory an algorithm uses. As a rule of thumb, the unit(s) you are using to describe time will be the same unit(s) that you’re using to describe space.

An important part to being able to quickly compute complexities is knowing the complexities of the individual steps of your algorithm. In particular, know the complexities for various data structure operations. For example, searching for an element in a list is linear in terms of the number of elements in the list.

Finally, as a sanity check, most complexities that you’ll deal with in an interview will be one of the following: O(1), O(n), O(n^2), O(n^3), O(log n), or O(n log n).


There are a few different ways your algorithms knowledge might be tested.

The simplest way is to ask you to recall, use, and/or implement a basic algorithm. These algorithms usually involve searching, sorting, or tree traversal.

Alternatively, they may give a question that involves modifying an existing algorithm, which may or may not be explicitly given to you. This shows how well you understand its nuances.

As an example, suppose you want to write an algorithm that sorts a list of Rectangle objects by a chosen metric, such as width, height, or area. Rather than writing three different versions of your chosen sorting algorithm, you can write a single algorithm that varies in how it compares two rectangles.

The last main way of testing algorithms knowledge is to have you design a completely new algorithm. Unlike modifying algorithms, the algorithm you need to create here is usually for a fairly specific problem.

Your familiarity with algorithms and your problem solving ability are probably the biggest factors when it comes to how well you do on this last category of algorithms questions. However, there are some techniques that you can use if you get stuck.

  • Consider a simpler problem. Reduce the problem’s size or consider edge cases. After you have an idea how to do a simpler problem, try to generalize back to the original problem.
  • Figure out what you’re missing. Often times, you might feel as if you’re lacking some piece of information needed to solve a problem. You probably are—you’ll need to make some kind of realization about the problem’s structure that will help you solve the problem. For example, to determine whether two numbers in a set sum to zero, all you need to determine is whether or not two elements in the set have the same absolute value.
  • Work through an example. If you don’t have a solid grasp on a problem, try working through some example cases. You’ll probably make some kind of intuitive realization; you just need to formalize it.

Algorithms problems tend to require some creativity, and as a result can be fairly challenging. One of the best ways to get better at algorithms is to just do a lot of problems. There are plenty available online.

Language-Specific Knowledge

A final category of questions that come up on interviews covers how well you know the nuances of a language. Although there are a myriad of possible things you could be asked about a language, these questions are typically oriented towards more significant/common details of a language.

Here are some examples:

In general, being familiar with a language’s syntax is a good way to prepare for these types of questions.

That’s it for this first article—check out part 2, where we cover the coding portion of interviews.

We’d love to know how well this post reflects your interviewing experiences. Let us know in the comments or on Twitter!


Vincent Le

Hi! I've been at Yext for nearly 7 years and I currently work on our fulfillment systems. When I'm not thinking about code, I enjoy playing games or having a nice cocktail.

Read More