About Technical Interviews - It Was Never About the Code

career10 min

byLucas Santos

This page was machine translated. Read original / Suggest a fix

For over a decade working in IT, I’ve done my share of interviews across very small companies, medium companies, large companies, and absurdly large ones. Both nationally and internationally.

But it was when I found myself on the other side, as an interviewer (some dozens of times later), that I noticed how different everything was…

I think it’s time I write about how both we as developers and recruiters are understanding things differently. This article will be quite informal, with many of my opinions, and I’d love to hear what you have to say too!

💬

Hit me up on my Twitter and tell me what you think and what your opinions are on this topic!

Technical Interviews#

Since I started working, I’ve always been afraid of interviews, especially technical ones (I actually always liked behavioral interviews). Initially I was more afraid, but nowadays it’s become much simpler, especially in a faster-paced market where, as a dev, the average time we stay at a job is one to two years. At first I always thought people would judge me, and if for some reason I didn’t pass the interview, it would invalidate all the work I’d already done in my life up to that point. I was a fraud!

But that’s not quite how it is…

Over time I realized that technical interviews weren’t just “unpaid freelance work” or “someone acting like a jerk who wants you to fail”. Sure, bad interviews are like that, but good interviews go far beyond the code.

Types of Interviews#

Let’s start by differentiating the stages of these interviews and the types that can appear to you, but first I want to touch on an interesting type of interview. The logic test.

💡

I’ll use examples of what I’ve seen here (in Sweden) as being more common, but this can vary from place to place

Logic Test and “Initial Interview”#

I don’t even call this an interview, which is why I’m putting it before everything else, but it’s very common to have a basic logic test, something like:

“what’s the next figure given these three figures”

The purpose of this test, from what I always noticed, was to cut out people who wouldn’t have any chance in the next stages that would require a lot of logical knowledge. Think of it as a cutoff score, that’s it.

This type of test is so much not a technical interview that it usually happens before any interview, usually after an initial interview, which is a call between you and the person managing the process (recruiter) just to make sure you’re a real person and meet the minimum requirements of the position.

Proficiency Tests#

This type of test is what most people are used to. A test that is delivered by the company for you to solve. It can have different types, and can happen in various ways. Let’s talk about some I’ve already gone through:

  1. Take-home assignment: It’s the test sent by the company via email, zip, or anything you can read calmly, solve, and return. These are usually longer exercises with more stages, but with much more time to complete them and also no pressure of being watched.
  2. Pair programming: It can be done in person or on a call. It’s the same as the take-home exercise, except you do it live with someone talking to you. Ideally it’s not to make you feel pressured, but even if the person isn’t directly judging you, it’s still a very stressful environment. These exercises usually start with a simple question that gradually escalates.
  3. Code review: It’s halfway between the two previous ones, and personally my favorite. When you have a stage where you do a technical exercise, return it, but receive feedback live and review the code with more technical people on the other side, this takes some of the pressure off. But many times both happen with a very long time between one and the other, and this can hinder the resolution.
  4. Architecture interview: An interview focused on creating an architecture for a given solution. The goal here is not to code the solution, but to explain how it would work and how you would architect the entire project. At least here, both are done in the same process for a position.
  5. Algorithms: This type of interview is where you receive a link to a platform like Codility, HackerRank, etc. It’s an exercise whose focus is solely on the technical resolution of a theoretical problem, for example: “Find the smallest number in a list”.

In fact, I did a thread on Twitter with a survey about which one people like the most, and without a doubt, the most voted was the take-home exercise:

And that has a very simple reason.

Interviews are Never About Code#

There are good tests and bad tests. Good tests are complex enough to be challenging, but simple enough not to be impossible. And the most important part: The code doesn’t matter.

What matters in this type of test is the path to solving the problem. Of course there are nuances in how someone writes code, how a person documents that code, how performance is evaluated, but you notice that the question isn’t about the code itself, but how you think about the code.

Challenges I consider bad are exactly algorithm challenges. They’re entirely about code. You’ll rarely have to solve a problem like that in real life, much less under pressure with a specific timeframe. Turning an interview into a test of patience and stress is something that doesn’t bring much value, and often the reason for failure is exactly because of that.

But that’s a way to evaluate how you behave under stress

Unless your job is to constantly be under stress with absurdly short deadlines for what you need to do, I’d say that maybe that’s not a good company to be at…

Furthermore, the direct focus on code, and only on code, doesn’t let you analyze other characteristics of development, like communication, teamwork, problem-solving…

Code is one of the tools. For example, you need to know how to use a paint roller if you’re a painter, but you don’t need to know all the details about every paint roller that exists.

Good Interviews#

I, in particular, like a sequence of interviews that focus not only on the technical part. Often the technical part isn’t even the most important part (at least not for me when I’m the interviewer), simply because you’ll spend substantially more time interacting with the team and with other people than actually coding.

This doesn’t mean the technical part can be completely ignored. On the contrary, it’s an integral part of the whole that makes up the job. A very bad technical interview will undermine the success of the position for sure. But a very good non-technical interview can be the difference between being accepted or not, even if other parts weren’t as good.

For me, the ideal process is:

  1. Start with an initial interview, which is not technical, and focuses solely on getting to know the person who is applying. This interview is usually done with the person who knows about the position, probably the hiring department. The goal here is not to technically evaluate anyone, but to understand the person’s moment and background to see if they will have a good integration. It should be short, at most 20 or 30 minutes.
  2. Then we move to a behavioral interview, called a behavioural interview, which is an interview focused on the non-technical part of things. It lasts 1 hour and usually the questions are related to past things, like how the person worked with something, how they solved a certain problem, what were the main lessons they took from it. For me this is the main interview. If the person can’t show that they’re someone who will get along well with the team or doesn’t have the same idea as the company, they’re instantly rejected, while you might not do as well in a technical interview and still pass. Once again: it was never about the code.
  3. The third step would be the technical interview itself, focused on a specific challenge. Let’s see more about it in the next section.
  4. At the end we may or may not have an architecture interview. This depends a lot on the position. I don’t believe they contribute as much depending on the expected level.

Now, which are the technical tests I think are worth applying?

Good Technical Tests#

For me, a good technical test is one that can replicate the work environment well and, at the same time, show what the person’s thought process is like, which is the most important.

I prefer not to apply algorithm tests for the reasons I mentioned before. I don’t think they’re fair. They don’t show how someone solves a problem, but rather that someone can solve that particular problem.

Furthermore, I don’t like surprise tests where you don’t know anything beforehand. That’s not real. You’ll never enter a company where the product you need to develop will simply appear ready for you out of nowhere. There will be a whole process of learning that project.

For me, the best tests are those that are sent to the person and they have a certain amount of time (days, not hours) to complete, using all the resources they can. The test is then sent back and then the technical interview itself is about reviewing and asking questions about that code.

I think this is a much more valid process because you’re evaluating code that was written by the person for a challenge imposed by the company. Often the test base comes ready and you need to meet some requirements, add others, etc.

Another type of test I find interesting is to send a ready-made application for the person to analyze, usually a day before. The next day the interview would be a series of questions to add new features to that application. I believe this is the way to get closer to what a typical day at the company would be like, because 99% of the time we’re not going to create anything new, but maintain what exists and add new things. Plus, this type of approach allows us to also see a person’s thought process, which is the most important part.

And it doesn’t matter whether the person finishes the test or not, or part of a test. What matters is knowing whether they could or couldn’t finish it, or whether their way of thinking and communicating would be correct. Remember: it’s not about the code.

Conclusion#

This post was a way to share a bit of what I’ve learned from hundreds of interviews both as a candidate and as an interviewer, and having seen a little more about how all this works from a technical point of view as a dev.

My idea is to expand more on this topic with videos on my channel and talk more about each part of the process, but creating videos is a complex process and I wanted to make sure there are people interested in the topic.

So, if you find this idea interesting, hit me up on twitter and tell me what you found most interesting and what I can focus more on in this topic! I’d love to hear your feedback!