The flaws of the interview process

10 min read
fix me

Photo by magnetme on Unsplash

Over the years there have been changes in the way interview processes are handled, which I believe are causing interviews to evolve into something unnecessarily complicated.

This observation, generally called "the broken process of job interviews", I wouldn’t personally call it broken as companies are still hiring, but! I won’t ignore there’s a lot of room for improvement.

Although every company develops its own custom interview process, there are common patterns in how the whole process is split. For that particular reason, I will divide this article into two different parts, one referring to the non-technical interviews and the other focusing on the technical parts we might encounter.

There's no particular audience for this article, as an interviewer or an interviewee I hope you can get something out of this.

Non-technical stages


Whether you end up getting hired or not, communication across the interview series is the most important factor that will make a process potentially good or bad.

From a starting point, job descriptions tend to be a copy-paste from each other, which makes it hard to understand what are they looking for in terms of profiling.

Once you get immersed in the interviews, in most cases, expectations, focus, and takeaways from every particular interview are rarely shared.

And in case the result ends in a rejection, communication, sometimes, gets forgotten.

One of the most common examples of the last point is emails. I am talking about those template emails saying they decided to go further with other candidates, with no feedback whatsoever. Or even canceling your application from scratch without mentioning the reasons why they have decided to withdraw your application in the first place.

Not to mention the number of times I get ghosted after I ask for feedback.

Companies are in the right to do this, but for me, this is already part of the culture, so if I spot some of those behaviors I won't probably apply again nor recommend this opening to another friend.

Unnecessary filter

Having big companies setting the bar high in terms of complexity and how difficult it is to pass their interview process, has side effects on other companies that follow the same approach and decide to take this as a metric of success.

Far from being the reason for their success, one of the main reasons why they are complex is due to the filter they are forced to make based on the number of applications they have. In the long run, this will give more false negatives, but companies that are getting tons of requests are eligible to take that risk.

The first takeaway of the article, avoid copying other companies’ processes! The big names are the ones dictating the way to do these processes in a way that fits their needs. But that doesn't mean this process will be useful for all companies.

I understand that in places that receive tons of applications with higher salaries in the market, there's a bigger filter that needs to be done. This means that if the salary you will end up getting is a life game-changer, I will expect it to be more challenging than others.

But why do others follow the same thing? As for my understanding, it is just because is trending.

Related to this, how many times have you got questions during the interview process but once you started to go deep into the company code, those good and amazing practices were not even close to the reality

The one I like the most in this regard is TDD, which is also something I tend to see on job postings as well. I got asked to follow TDD and BDD practices during code challenges, just to find 0% code test coverage on the company code after I managed to get the job.

This reflects a lack of customization and profiling in the process, rather than imitate and go for something standard, you can take this opportunity to look for a candidate that would fit YOUR daily tasks and team culture.

Inclusion and diversity

Inclusion plays a more important role in this equation than people regularly think.

The lack of empathy when companies ask you to invest time in applications or code challenges, without offering anything in return, always surprises me.

I have been told that I should invest more hours in the assignment, just because I have described some solutions with comments, or because my test coverage wasn’t 100%, among others. Is incredible how generous people are with the time of others, isn't it?

Furthermore, considering free time investment, what if I have kids? What if I am doing several interviews in parallel because I am in a rush to get a new job? what if I have side jobs? Does it mean that I am not eligible to apply for these openings? That’s hard.

So, please make sure those requests are optimized or consider offering a paycheck among other types of benefits if those tasks are time-consuming.

About this particular subject, there's a book and also a newsletter that I would like to recommend, that doesn't only apply to recruitment:

In this link, you can subscribe to weekly recommendations and check out the book, which has helped me to understand better the importance and complexity of this subject.

One simple starting point is to make your interviews inclusively friendly, by including minorities as part of the process, so that people reflect more, and get a sense of the environment. It will also help to filter those profiles that show some flags during those sessions.

Duration of the process

I can understand that for companies, especially the ones offering visa sponsorship, where there is a huge investment/risk at stake, before submitting an offer they would like to be as convinced as possible.

Companies aren't doing us a favor when hiring us, we are just going to be paid for our work, it should be a bidirectional negotiation.

But lately, I have completed and started processes with up to 6 phases or sessions, including 3 only discussing technical-related subjects. Why are tech companies so obsessed with measuring and testing technical skills? Especially for senior positions, where tech-related subjects only imply a partial amount of our work, the rest is dealing with other problems where soft skills have a bigger impact.

I find it odd, that the senior and experience I get, the more complex it is to get a job. Crazy!

Side note, in case you are curious to know what defines seniority to me, you can find it here.

Slow feedback circles, make it easy for interviewees to get tired, and long sessions are an overflow of information.

Having these sessions can potentially lead to a lack of tracking of the process, difficulty in syncing the process with the people included, and difficulty finding the right and motivated people to do it.

Focus on the culture

Hire people, not roles! Find what type of profiles meets your expectations without looking in-depth at technical implications, as that is the easiest part to learn in the long term. Soft skills are harder to change or adapt.

At a company I used to work for, the most important part of the interview process was in a bar or coffee place, depending on the candidate's preferences. A session where we spend some time chatting informally about work and life. It worked both for us to check if there was a match, and for the interviewee to get a sense of what it was like to socialize with us.

Train the interviewer is important, and avoid forcing people to take interviews just because they know. During a few interviews I did in the past, I had the feeling I did well but the interviewer didn't feel like doing the interview so I was just the victim that person used to complain about him taking more interviews.

Moreover, make sure candidates take interviews from the company side and represent the profiles you are looking for.

Technical interviews

Measure the knowledge (aka seniority) is tough. Just the fact that an hour-long interview is going to define the salary you will get makes people feel nervous, which is one of the reasons why I normally panic before taking any time-framed technical interview.

I believe the interview should be bidirectional instead, where we as interviewers also take a primary role, for which I recommend this article.

Be careful with the people you put to interview, first impressions are really important, and not all devs, no matter how senior they are, are ready to make interviews and assess a person, or even less able to provide objective and not biased feedback about it. This is a skill outside of regular work that needs to be developed.

Pair programming code challenges

I'm not the first person to say that live coding interviews are far from reality and that the only thing it does is put a person in the spotlight, while the others are looking at you while coding and suffering because of the pressure.

No matter how hard you try, if one person is being evaluated and the interviewers/s know the problem, its context, and its possible solutions, it's not a pair programming session.

We can call it a collaborative session, where devs will help you to proceed if you get stuck.

These sessions are supposed to evaluate your communication skills, but I hardly ever do I feel comfortable.

Although I am not a big fan of this particular type of interview, I must say there were cases where the result was successful as the interviewers were able to build and create a safe environment and the assignment was rather simple, as the main focus was on communication and in how to move things forward on iterations.

Rocket science algorithms

I am referring to things like Hackerrank type of exercises, which I would only consider as an option if it's a mandatory skill for the job opening.

As a frontend developer, it’s unbelievable the number of interviews I have failed because of those exercises, which I have never done on a job in 10 years. Or maybe I did, there was time for research and analysis.

So, please try to mirror problems that are likely to appear in the real job.

I am not ranting against performance, as a front-end developer, I invest time in practices on how to improve it, but only when necessary.

In real-life scenarios, I work on problems when they become one, or I have metrics that can potentially become one. The need to over-engineer everything just to prepare for every single case scenario is a flaw for the business, that could easily scale to something difficult to maintain.

Take-home type of test

Although is good because there is not much pressure other than solving that on the spot (which is hardly a situation you will experience at work), it implies that you take extra free time to work on its solution, and not everyone is willing to do that.

In these cases what worked for me was to set an expected time to spend on it, otherwise is hard to measure if more people can spend more time on interviews than others, and the final evaluation won't be fair.

Scope the investment of time, evaluate comments, and don't be picky when looking for the details. Remember that usually, people don't have much time to work on this considering the context switch and iterations.

I prefer the take-home type of assessment, where you can also see the prioritization of the features and time management. And never ask for everything to be finished.

As in most processes, feedback should be mandatory. There was one time, that I spent a week developing a technical assessment from which I had good feedback first, but at the moment I was having the next round the interviewers started to ask questions without having an idea of my solutions. For me that was a lack of respect, I spent a week of my free time doing something they even didn't dare to check.

Close up

Those were the drawbacks I have noticed in the interviews I have done in the last few years, both as interviewer and interviewee.

Unfortunately, there's no unique solution we can follow. We need to adapt the process to our business and provide different alternatives to the candidates so that we will improve engagement and inclusion.

Thanks for reading ❤️

Written by Manu

I am a product-driven JavaScript developer, passionate about sharing experiences in the IT world, from a human-centric perspective.

Other articles