Technical interview is a skill in itself

Being good at technical interview and being a good developer are two very different things. They have become two different skills. And not only for large companies anymore. But why? And how to be well prepared for it?

Root

In order for you to understand the absurd situation you are in today, we need to discuss its origin. As is often the case in the tech world, our story begins with the giants. Facebook, Amazon, Apple, Netflix, Google, Microsoft and all the others. To go faster I’ll talk about “FAANG”, the acronym from the stock market that everyone uses.

We are at the beginning of the 2000s, FAANGs are young (Facebook 2004) but already very prestigious. They are known worldwide for their products, but also for their job interviews. Interviews out of the ordinary.

Tests of algorithms and data structures were already present, but to a lesser extent. These giants recruited mainly by asking completely crazy questions. Infernal puzzles in the form of riddles. We’ve all heard about these famous questions.

How much do you estimate the cleaning of all the windows in Manhattan? How many golf balls can a school bus hold? How do you get 4 liters from two bottles of 3 and 5 liters?

In the mid/late 2000s, these questions were then completely banned. They were considered too complicated. The technical interview at FAANG evolves almost exclusively towards these famous extreme data structure and algorithm interviews.

This new era is moreover “officialized” by the release of the world-famous book “cracking the code interview“. This radical shift will have an impact on the rest of the industry.

Optimization

Do you want to join FAANG today? It’s hell. Hang on, you’re not ready.

First, you need to get an interview. With the number of resumes they get, it’s a bottle in the sea. Even with your outstanding resume. Most people get an interview through an employee who refers.

Did you get an interview? It’s nice, the second step is a technical test by videoconference. The recruiter will put you in front of a google doc and ask you a hell of a question. A kind of crazy puzzle based on algorithms and advanced data structures.

You will have to solve this puzzle in conditions that will make you feel comfortable.

• With a countdown
• In a google doc
• Without internet
• Explaining your reasoning in real time

Here is a realistic reproduction of what awaits you.

I don’t know about you, but personally it would take me months of preparation just to have a chance at this second stage. Did you pass? You’re too good. We can move on to the difficult part.

This time, they make you come all expenses paid directly to them. They’re going to torture you with 4 to 5 puzzle tests of advanced algorithmic infernal puzzles. This time it will be on a whiteboard and with the same principle of limited time and real-time explanation.

Note that if you fail any of these tests, you are unlikely to be called back. And I’ll be honest, I think all this hell is very justified for these giants.

Welcome to Facebook

These technical interviews are intentionally extremely complicated. It is their way of “degreasing” the mass of candidates. Even a very talented senior developer has to spend months of hard work to have a chance at these ruthless interviews.

How many are willing to make these efforts?

Moreover, with the volume and traffic they handle, their need for scaling is staggering. A thorough knowledge of data structures and algorithms to maximize optimizations is vital to them. Not to mention the fact that an extremely optimized solution will save them a lot of money. Hiring a profile that can do this easily is mandatory.

Finally, we’re not going to lie to each other, even if you can get away with it (my humble opinion) by spotting patterns in puzzles, it’s also an IQ test. So what’s the problem?

The problem starts when the rest of the tech takes inspiration from these giants and do the same kind of technical interview.

Pandemic

A disease gradually affect all companies that recruit developers. I named this disease “we are the best too“. The epidemic uses a transmission mode that goes through a very common way of thinking.

“The best companies use this to get the best people. But we’re the best too, right? We’re going to do the same thing!”

The infection initially affected all the companies in silicon valley. Gradually the medium sized companies and startups in the United States were affected. Then Europe and finally the whole world. The WHO has classified this epidemic as a global pandemic around the year 2015. And that’s until today.

So I have several things to clarify before you start insulting me.

• It doesn’t concern 100% of the companies. The more “prestigious” the company is, or thinks it is, the more chances you’re getting it.
• FAANG is the extreme example. The boss at the end of the level. Nobody would be hired anywhere else.
• Often the companies don’t even know they’re giving you this kind of test. These tests are done via platforms like CoderByte. We’ll talk about it later.
• Some companies was already doing that in the past. It has become a standard everywhere recently.

The result of all this is that we find ourselves with the same type of technical interviews reserved for developers everywhere. It creates situations that shouldn’t exist.

Dual skills

Recently, a developer friend of mine was rejected for a job made for him in a startup. Objectively, he is very good in React and Javascript in general. He was asked to implement a merge sort for a Frontend React developer position during a videoconference. Do you see where I’m going with this?

I’ll give you another concrete example. I know the Dijkstra algorithm. I can determine the shortest path between two points in a graph. I learned this during my master’s degree in computer science. In 10 years of professional work, I have never used it. Never. It has never served me and it doesn’t make me a better developer.

But in technical interview it does. In technical interview, if I’m asked to determine the shortest path in a graph, it makes me a god. And it makes the person who doesn’t know the algo a sub-human. And that, no matter how expert he is at doing the job in question.

I fully understand that knowing the basics of data structures and some algorithms is quite beneficial. I agree and I preach it too. But is it really necessary for all positions? And where to put the difficulty bar?

Another example: a friend of mine just had six interviews for a NodeJS developer position for a well-known company. Four of them were technical and based on data structure and algorithms. She was never told about Node or about the actual tasks of the company.

Technical interviews became is a skill in itself. To be a developer, you have to know how to develop functional and maintainable applications. To pass the developer interview, you have to master a mind-boggling mass of data structures and increasingly advanced algorithms.

Things that you will rarely use in real life. When you do, you’ll be using solutions that are already made and optimized. Solutions you can find in seconds on Google. This mass of data structures and algorithms specifically for technical maintenance is growing more and more over the years. Which brings us inevitably to today’s reality.

Today’s reality

Even a very talented senior developer has to spend weeks or even months of work to have a chance at these interviews. It doesn’t matter where you come from or what you have accomplished. Forgot this algorithm you never used ? Get the fuck out here!

And that’s the problem. This “second skill” must be maintained or caught up before your technical interview. When was the last time you reversed a binary tree at work? But if you can’t do it from head to toe in a technical interview, you suck.

Everyday work as a developer doesn’t prepare you for these types of technical interviews, which are becoming more and more popular. It’s absurd.

And then you’re going to tell me “the problem comes from the company that does these kinds of tests”. Have you had an interview recently? There was a time when this kind of test was very rare in a so-called “non-prestigious” company. What is rare today is not to get it, no matter the company. It’s related to the pandemic I was talking about, but also to another reason.

Your interview has become a business

If there is a money to be made, you can be sure that someone will make it. Automated platforms for testing developers are available to companies today. It’s so easy to set up that they all do it. HackerRank, Codingame, Codility, Coderpad, Coderbyte, CodeSignal and more. It’s all data structures and algorithms. A real slaughterhouse for developer who hasn’t worked on his second skill.

We no longer try to test you on what the company does. No more context with real everyday tasks. You are sent to a sanitized place where everyone goes through the same mold.

Can’t you delete a node in a binary tree? You’re a bad developer. Nobody care if you’re a Javascript expert for a web dev position.

Developers are so afraid of these technical interviews that other businesses have specialized in their preparation. Entire businesses such as LeetCode, AlgoExpert or TechInterviewPro are based on this reality. The people behind these platforms are literally becoming millionaires because the demand is so huge. And if it’s making money, that means it’s not going to stop.

You never had a technical interview like this before? Congratulations, you’ve passed through the net of a tightening system. I invite you to apply to a company with a little-known name to test this system.

In short, it’s easy to complain about all this, as I do in this article. You can also accept the situation and prepare yourself accordingly, as I do the rest of the time.

How to be well prepared

My first piece of advice to prepare for all this is to start by understanding what we’re talking about. If you come from a traditional computer science background, it’s going to be a lot of revision. If you come from a shorter background, it’s going to be a lot of discovery. I’ve already talked about data structure and algorithms, you can start there. There are also plenty of resources on the internet.

I strongly advise you the undisputed bible of technical interviews: “Cracking the code interview“. Beyond all the problems of real interviews inside, it’s especially for Gayle’s way of explaining that I recommend this book. She has an ability to simplify complicated concepts that makes everything simpler. That’s what I try to do with the technical articles of this blog. Unfortunately, I’m far from reaching her level.

My second piece of advice is to practice on free platforms I was telling you about earlier. Leetcode or Hackerank can be used outside of paid programs. They are platforms that allow you to practice real interview questions in an online IDE.

Priorities for your dual skills

The crucial thing to understand is that there’s no point in throwing yourself into Leetcode the day before the interview. It’s best to do this regularly. Practice from time to time when you feel like it for maximum efficiency.

Personally I use the free version of Leetcode. I advise you to start with the questions marked easy. When I first started Leetcode, I had trouble with the easy ones. Then, after a while, it became easy.

I switched to the medium and likewise, I was having much trouble. But by doing it from time to time, mediums became feasible. I continue and I try a hard from time to time.

I think that’s what will help you the most to maintain this second skill. The more you work on this second skill, the more you will be able to go where you want. Obviously for a FAANG goal, theory and Leetcode is not enough. People who have a chance in the giants are way more prepared than that.

For young developer I see a lot of recursion, memoization (e.g. factorial) and pointer management, especially with linked lists. I don’t know why, they love to make you return linked lists or validate palindromes with two pointers. Try to work on that first (with the rest) because it’s really 80% of the interviews for young people.

For intermediate, in addition, I see a lot of research on graph. I’m talking about DFS and BFS. The great classico is a story of a labyrinth to be traveled. You will also come across sorting algorithms.

For the more experimented, in addition, you’ll see dynamic programming. I’ll be honest, I find the program for the intermediates intense. So the program for experimented developer is very hard. You’re going to have a lot of architectural questions as well.

Finally, the big mistake is to think that a technical interview is just code. A technical interview is never just technical. It’s first of all an interview between humans. They will openly criticize your code and see how you react. I’ll do an article on that later, but you have to think about that too.

Epilogue

The technical interviews are like our job, complicated and hard to master without practice. They have evolved in the past and will evolve in the future. Data structures and algorithms are not necessarily a bad idea if the difficulty is adapted to the job. Otherwise, the candidate could be tested on real tasks that he or she will perform for the job. On an IDE and with an internet connection. Just like in real life. I know, my idea is crazy.