How To Get Good At Interview Challenges: Part 1

You know when you find a new programming subject that you have no idea how to do but it makes you curious and excited? Maybe it is machine learning or a chess engine or genetic algorithms. You have no idea what you are doing but it is awesome. You become a googling machine, a human on a quest for learning. You wake up in the morning excited to learn more.

Interview challenges are mysterious like that, but they are NOT awesome, they are not exciting, they are not fun. All the curiosity is killed by the pressures, the anxieties, the time limits. Instead of getting excited your brain panics.

I have never seen this before. And I have no idea what I'm doing. And I'm going to fail

I hate interviews. I hate them so so so so much. They take what I enjoy a ton and turn it into a stressful, nerve–racking experience. Before an interview I will pace and my heart will race. Doing them is like driving on an icy road on a mountain at night in a blizzard. I know how to drive just fine, I love driving scenic roads, but driving in a blizzard isn't fun no matter how pretty the trees are. Interviews turn programming from fun into an exhausting drive.

I have cried after interviews

Programming is fun. Interviews are terrible.

Interview challenges could be fun. Interview challenges can become exciting, fun, and drive your curiosity like any other programming task. Solving interview challenges can become more like programming. You just need to learn how to approach them.

Interview challenges seem hard and mysterious, but that is just because they are a very different type of programming problem than we are used to. Real world problems are things we are used to breaking down into tiny solvable parts every day, but interview challenges are an entirely different than real world problems (that is probably a bad thing but that is a topic for another time). We know how to for example, breakdown a frontend UI problem; into React components, build configurations, reducers, generators etc. Interview challenges are hard because we have no idea how to break the problem down into tiny parts we can solve.

Interview challenges are meant to test one subset of programming knowledge that most people like to refer to as CS fundamentals. They really deal with one core type of knowledge, that of common data structures and common algorithms. Basically the stuff you usually let a library handle, interviews have you do manually. For example, in an interview challenge, instead of reversing an array by calling array.reverse you might need to implement a swap algorithm.

The vast majority of every day programming tasks involve using a very small subset of data structures and algorithms. We don't need to know how to efficiently reverse an array, the stdlib does it for us. Instead of memorizing the algorithms, we memorize the API of standard libraries and frameworks.

Getting good at interviews is nearly as simple as just learning what your standard library does for you. If you can implement your language's standard library you are a long way towards mastering interviews.

When everything is a duck

You use the stuff in interview challenges every day, it is just hidden by layers and layers of abstraction. In a modern dynamic language different data structures are made to have similar APIs. For example, in Ruby if we had a SortedSet and an Array, and we wanted to sort them, we would call the same method sort on either type. It looks exactly the same but internally the algorithms that do the sort can be very different.

Most of us don't have to think about data structures and algorithms to get work done. A library will decide for us whether InsertionSort, MergeSort or QuickSort is better for sorting our data. It is all magical and awesome and allows us to be super productive. But when everything is a duck, you don't know how anything works.

It's All About The Data

You need to find the max value in a list of integers. What selection algorithm do you use? Actually first, before you figure out that, what sorting algorithm do you use? Impossible to answer without knowing more about the data. How long is the list? How big are the numbers? Are they completely random or are segments of the data already sorted?

What if you knew the list was already sorted? Then what you need is simple. It is just nums[nums.length - 1]. Boom. Max value found.

Max Steel was a terrible movie btw.

If you want to get good at interview challenges all you have to do is start learning data structures. You don't need to focus on memorizing algorithms, because the algorithms you use are determined by the data. Once you get good at unpacking the data in challenges, the algorithms will jump at you.

If you want to get good at interviews you have to learn to breakdown the problem into the data structures that make up the inputs, the outputs, and any state. Once you can do that, your other programming skills will kick in. Once you know the data structures cold, everything will become obvious and less mysterious.

Let's learn some data structures!

tl;dr

  1. Learn data structures
  2. Learn how your standard library actually works
  3. Everything else will reveal itself

Resources