You see a job with a perfect description. You fulfill all the requirements and the company and its location are great. It is like this job was made with you in mind. A perfect match.

You review your CV, create a perfect cover letter, and apply for it. A few days later, you receive an email with a reply.

They liked your application and inform you that you have been approved for the next round: a live code interview with the manager.

You panic again. The last one you did was not good. You forgot everything. A huge blank. But this time is going to be different. It is your dream job, after all. You study all week for the interview.

You review algorithms, do some code challenges, check the most frequently asked questions in these situations.

The interview begins — a couple of questions to break the ice. Some things about your resume and past experiences.

No big deal. Then, the code part. You open the browser, read the task, ask some questions to make sure you understand everything, and then… blank.

All your fears start to rise again. You start to think you are not good enough, that you are a failure, that somehow you have committed a crime and are being caught.

The interviewer tries to help you, but you do not get anywhere. You know you don’t have to get it right. You just have to go in the right direction.

But it’s too late. You know, they know: The interview is done. A few more questions about the job and the company, then the famous phrase “You’re going to receive an email from us in a few days to know whether you are approved or not for the next round.”

Ten minutes later, you solve the question in the shower. “How could I be so stupid? That was so easy!”

A few days later, the email comes. You have not been approved.

Flaws

You have probably lived through this situation a couple of times. And if you are a manager, you have seen a lot of good candidates who just froze in a live code interview or test.

You know they understand the topic and how to solve it, but they just can’t handle the situation.

Coding interviews are memory-based

The problem is that developers are asked to solve complex problems on the whiteboard (or its modern online equivalent) just based on their memory.

Even though you can say the way you think matters more than the code itself, it is still very much based on how much you remember.

And if you are an introvert like me, chances are you’re not good at this. Maybe you were just having a bad day. Or maybe you’ve never seen that algorithm before. Or it is impostor syndrome again.

It is like being a guitarist, and instead of knowing how to play a song, you are asked to describe the seven modes of the major scale.

A lot of candidates are studying algorithms just to pass interviews and not because they need them to solve a real problem.

They are unidirectional

In real coding, you spend a good time interacting with others, asking questions, searching for a bug, testing your code, or teaching others.

None of these aspects are actually being evaluated during a live code interview. Only how good you are at solving a puzzle question disguised as a coding one. Alone.

Poor simulations of real problems

There are also flaws in the way the programming challenges are portrayed. They are usually standard and general problems — not the ones the company deals with daily.

This could be a way to tell if the candidate is a good coder, but not if they are a good fit for the company.

These algorithm-style interviews have some flaws, yet a lot of companies keep conducting them. There are some reasons for that.

Just because cool kids are doing it doesn’t mean it’s right

If you need to hire someone and don’t know how to do it, you will look for someone who does.

And you will probably look at how companies like Google, Facebook, and Amazon do it. “They must know what they are doing.”

Although they have spent time thinking about their interview process, it doesn’t mean they are doing it right.

And it doesn’t mean it is what you need. They have different needs and expectations than you do.

They only test basic knowledge

It is believed that people with good computer science fundamentals are going to be good software developers — that good basic fundamentals can really help with your problem-solving skills.

They are covered during the early years of a computer science program, and interviewers expect you to know them.

Chances are you will have to develop your own data structure, and it is better to have some as a guide to start. If you are comfortable with basic ones, you will probably be OK with hard ones.

However, some evaluators can really mess this up. They want a challenging interview question to filter out the poor fits but end up creating a challenge based on the knowledge side rather than the problem-solving side.

Other Methods Are Also Flawed

There are other methods for “interviewing” a candidate, but they also have their problems.

You can test people on relevant knowledge, like frameworks or OOP concepts, but they have the same problems as the coding ones. You just changed the subject.

You try to ask about their past experiences to see how they succeeded at different tasks. But you might actually be testing if they sound successful and sell it well — not if they really did something.

And for a junior developer, they just haven’t had the time or opportunity to participate in a project yet.

You might ask for evidence of what they have worked on, like a portfolio or repository. If they worked for a company, they probably cannot share what they did there.

Or maybe they don’t have one. They want to do something else with their free time instead of programming (and there’s nothing wrong with that).

You can send them a homework problem, but how do you know if that is really their work or if they are willing to do it in their free time?

Tips To Improve

Even though our interviewing methods are broken, that does not mean we should abandon them entirely.

There are some ways to improve them in order to make sure they are checking the skills needed for the job.

As an evaluator, this is the first question you should ask yourself: “Is this really evaluating a candidate for what they will be doing here? Or am I just copying and pasting someone else’s work?”

A combination of the aforementioned methods is a good way to start. You can test for different skills that a developer needs to have.

Project assessment

One good way to filter out poor fits is to send candidates a homework project.

This way, they can choose their favorite IDE, look up anything they don’t remember, and solve a real problem — as they would in the real world.

Be careful here. It is easy to send a project that will seem abusive to the candidate.

• Keep it short. Their time is as valuable as yours.
• Make the instructions very clear, but keep space for them to be creative as well. It is important to know what to expect from the task.
• Ask for proper documentation so you can know their approach and thinking process.
• Keep it aligned with the company’s business.

The important part here is to observe how the candidate solves a problem from the requirements to the production.

You can do this online with the candidate sharing their screen while doing it so you can actually see the process.

Live interview

You have a good filter with the project assessment test, but sometimes you need more data to analyze for the reasons we talked about earlier.

You can then have a live interview and ask for some things like:

• Bug fixing: Insert a bug into their code and ask them to fix it. This can be done with another project as well so you can see how well they manage to work with other people’s code.
• Refactoring: Ask for what the candidate thinks they can improve in their code (or other). You can see how well they understand what makes good code or how to scale a product.
• Pair programming: Ask them to teach or explain their code to other programmers. This will show how well they understand what they have done (if they really have) and how well they can communicate with others.

Remember to always keep this step simple and solvable. That way, the candidate can focus on what matters — not trying to come up with a solution or being nervous about not completing the problem.

Photo by Artur Aldyrkhanov on Unsplash.

Final Thoughts

The process of finding a good candidate for a role can be long and stressful for both the company and the candidate. It can last months, waste a lot of money, and the company might not even find a good match in the end.

The current method that most software development companies use can be misleading. They might be choosing someone who decorated all the content from a textbook but doesn’t know how to apply it or the implications of doing so.

There is no simple way of doing an interview. All interviewing methods have flaws. You need to find what makes sense for your company and the role you are trying to fulfill. Test if your process is really working and change it if necessary. You will not find the perfect solution on your first try.

And if you find a good way to hire a developer, share it with the world. It would be best for everyone.