On Technical Interviews: It Was Never About the Code

career10 min

byLucas Santos

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

In more than a decade working in tech, I’ve done my share of interviews, for tiny companies, medium companies, big companies and absurdly big companies. Both at home and abroad.

But it was when I sat on the other side, as the interviewer (a few dozen times since), that I noticed how different everything looked.

I think it’s time I wrote about how both us devs and recruiters are reading this whole thing wrong. This one’s going to be pretty informal, with a lot of my own opinions, and I’d love to hear what you think too!

💬

Hit me up on my Twitter and tell me what you think and what your own take on this is!

Technical interviews#

Since I started working, I’ve always been scared of interviews, especially the technical ones (behavioral interviews, I’ve actually always liked), at first I had a lot more of that fear, these days it’s become much simpler, especially with a faster-moving market where, as a dev, the average time we stay at a job is one to two years, but back then I always thought people would judge me and that if, for some reason, I didn’t pass the interview, that would invalidate every bit of work I’d done in my life up to that point. I was a fraud!

But it’s not really like that…

Over time I started noticing that technical interviews weren’t just “unpaid freelance work”, or “some jerk who wants you to fail”. Sure, bad interviews are like that, but good interviews go way beyond the code.

Types of interviews#

Let’s start by telling apart the stages of these interviews and the shapes they can take, but first I want to paint a picture of an interesting type of interview: the logic test.

💡

I’ll use examples of what I’ve seen here (in Sweden) as being the most common, but this can vary a lot 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 anything else, but it’s very common to have a basic logic test, something like:

“what is the next shape given these three shapes”

The point of this test, from what I’ve always noticed, was to filter out people who wouldn’t stand a chance in the next stages, the ones that would require a lot of logical reasoning, think of it as a cutoff score, nothing more.

This kind of test isn’t a technical interview at all, to the point that it usually happens before any interview, generally right after an initial call, which is a chat between you and whoever’s running the process (the recruiter) just to make sure you’re a real person and you meet the minimum requirements for the role.

Proficiency tests#

This is the type of test most people are used to. A test the company hands you to solve. It can come in different shapes and happen in a bunch of different ways, let’s go over a few I’ve been through myself:

  1. Take-home assignment: The test is sent by the company through an email, a zip file, or anything you can read at your own pace, solve, and send back. These are usually longer exercises, with more steps, but you get a lot more time to do them and there’s no pressure of being watched.
  2. Pair programming: Can be done in person or on a call, it’s the same idea as the take-home exercise, except you do it live, with someone talking to you. Ideally you’re not supposed to feel pressured, but even when the other person isn’t directly judging you, it’s still a pretty stressful environment. These exercises usually start with a simple question that gradually escalates.
  3. Code review: A middle ground between the two previous ones, and personally my favorite, when you have a stage where you do a technical exercise, send it back, but then get live feedback and review the code together with the more technical people on the other side, that takes some of the pressure off, but a lot of the time both parts happen with a long gap in between and that can throw off the resolution.
  4. Architecture interview: An interview focused on designing an architecture for a given solution, the goal here isn’t to code the solution, but to explain how it would work and how you’d architect the whole project. At least where I am, both are done in the same process for a role.
  5. Algorithms: This type of interview is the one where you get a link to a platform like Codility, HackerRank, etc. It’s an exercise focused purely on the technical resolution of a theoretical problem, for example: “Find the smallest number in a list”.

I even ran a poll on Twitter asking which one people liked most and, no contest, the most voted was the take-home exercise:

And there’s a very simple reason for that.

Interviews are never about the code#

There are good tests and bad tests. Good tests are complex enough to be a real challenge, but simple enough not to be impossible. And here’s the important part: the code doesn’t matter.

What matters in this kind of test is the path taken to solve the problem, sure, there are nuances to how someone writes code, how the person documents that code, how performance gets evaluated, but you notice that the question isn’t really about the code itself, it’s about how you think through code.

The challenges I consider bad are exactly the algorithm challenges, they’re entirely about the code, you’ll rarely have to solve a problem like that in real life, let alone under pressure with some ticking clock. Turning an interview into a patience and stress test doesn’t add much value and, more often than not, that’s exactly why people fail.

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

Unless your job is to live in constant stress with absurdly short deadlines for whatever you need to get done, I’d say that’s maybe not a great company to be at…

Beyond that, focusing only on the code, and nothing but the code, doesn’t let you look at other traits of the job, like communication, teamwork, problem solving…

Code is just 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 every detail about every paint roller out there.

Good interviews#

I, personally, like a sequence of interviews that don’t focus only on the technical side, a lot of the time the technical part isn’t even the most important one (at least not to me when I’m the interviewer), simply because you’re going to spend substantially more time interacting with the team and other people than actually coding.

That doesn’t mean the technical part can be completely ignored, quite the opposite, it’s an integral part of the whole that makes up the job, a really bad technical interview will sink a hire, for sure. But a really good non-technical interview can be the deciding factor between getting the offer or not, even if the other parts weren’t so great.

To me, the ideal process is:

  1. Start with an initial interview, non-technical, focused only on getting to know the person applying. This interview is usually done with whoever owns the role, probably someone from the hiring area. The goal here isn’t to technically evaluate anyone, but to understand the person’s background and where they’re at, to see if they’d fit in well, it should be short, 20 to 30 minutes tops.
  2. Then we go through a behavioral interview, the behavioural interview, which is focused on the non-technical side of things. It runs for an hour and the questions are usually about the past, how the person worked on something, how they solved a given problem, what were the main lessons they took from it. To me this is the main interview, if the person can’t show they’ll get along with the team or that they don’t share the company’s mindset, they’re rejected on the spot, while you could do so-so on 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, more on that in the next paragraph.
  4. At the end we may or may not have an architecture interview, that depends a lot on the role, I don’t believe they add that much depending on the seniority expected.

Now, which technical tests do I think are actually worth applying?

Good technical tests#

To me a good technical test is one that does a good job replicating the actual work environment and, at the same time, shows how the person thinks, which is the important part.

I’d rather not run algorithm tests for the reasons I mentioned before, I don’t think they’re fair. They don’t show how someone solves a problem, only that someone can solve that specific problem.

Beyond that I’m not a fan of surprise tests where you know nothing beforehand. That’s not realistic, you’re never going to join a company where the product you need to build just magically shows up ready for you out of nowhere, there’s always a whole process of getting to know that project first.

To me the best tests are the ones sent to the person with a set amount of time (days, not hours) to finish, using whatever resources they want. The test is then sent back and the technical interview itself becomes a review of and questions about that code.

I think this is a much fairer process because you’re evaluating code that person actually produced, against a challenge set by the company. A lot of the time the base of the test already comes ready and you need to meet certain requirements, add others, and so on.

Another type of test I find interesting is sending a finished application for the person to look over, usually a day before, and the next day the interview becomes a series of questions to add new features to that application. I believe that’s the closest you can get to an actual day in the life at the company, because 99% of the time we’re not building anything from scratch, we’re maintaining what already exists and adding new things to it, and on top of that this kind of approach also lets us see the person’s thought process. Which is the part that matters most.

And it doesn’t matter if the person finishes the test, or even part of it, what matters is knowing whether they’d be able to finish it, or whether the way they think and communicate would be on the right track. Remember, it’s not about the code.

Conclusion#

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

My plan is to expand more on this topic with videos on my channel and go deeper into each part of the process, but making videos is a whole process and I wanted to make sure there’s actually people interested in the subject.

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