I wrote previously about my approach to technical interviews. I think there’s a lot of value in catering your interviews towards the needs of the job. I once interviewed a candidate who choked on a relatively simple algorithm. Because someone had referred them, we did a second technical interview which focused more on the specific skills they’d need for the role, and they passed with flying colors. This person ended up being one of the most creative and performant problem solvers on the team.

It’s expensive to hire people, especially developers who already are quite expensive. As a former hiring manager, I want to know that the person I’m interviewing can do the job. As a result of that interview I started catering technical interviews specifically to the skills that will be needed for the job.

The argument for having a candidate implement algorithms — like traversing a linked list, or sorting an array — in their technical interview is that these questions are a good proxy to see that someone can code on a basic level. They serve as a gatekeeper. I used to dread these interviews. But I’ve gotten quite good at them now. More often than not I’m called to the next round when I encounter one, though there are bad days where I just can’t solve straight.

While I rarely use any of these algorithms on the day-to-day work I do as a developer, knowledge of the basic patterns used plus understanding their performance using asymptotic notation has improved the quality of my code. Asymptotic notation is a way to evaluate the performance of any given algorithm. Obviously we want our code to be performant, not just work. So knowledge of this really is a good measure of basic coding abilities.

By doing a technical coding challenge real time it means that the interviewer can:

• See that they can solve a relatively simple — and sometimes not so simple — problem.
• See that they understand how their code effects performance and memory restrictions.
• See how someone works through a problem in real time and how they might be to pair with.

So yeah, it’s frustrating to have to get back to fighting condition, aka practice my algorithms, when I’m looking for a job and get good again at something I won’t actually really do daily at the job, in order to get the job. But I do understand it, and most places do algorithm focused technical interviews.

So the question isn’t should I be practicing, but how?

How do you get good at algorithm focused technical interviews?

The short answer is sign up for AlgoExpert.io.

It’s important to understand how to use it AlgoExpert effectively though.

There are “190 hand-picked questions” which is great. They have an in-browser IDE through which you can code, and unit tests that evaluate your solutions. Which his excellent.

But where AlgoExpert shines are the explanation videos. The instructors model how you should behave during an interview.

• They first walk through the problem.
• Then they explain the potential solutions, and evaluate each one for performance.
• Then they code it, explaining how they coded it.

This is exactly what you need to do to ace a technical interview. Even if you don’t finish a problem, articulating your approach step by step communicates your thought process and will give you a fighting chance to get to the next level. Personally, as a hiring manager I would absolutely hire someone who didn’t quite finish a problem if I liked their approach.

If you’re going through the interview process, or just want to level up for the next position I can’t recommend this tool enough.

But make sure to watch the videos too.

You may learn an approach that you hadn’t thought of. You might find that your approach isn’t performant. At the very least, you’ll have someone model to you how to effectively communicate your thought process, which really is one of the most important skills at any job.

If you spend half an hour a day, every day, during your job hunt (or preparing for your hunt). I guarantee that you’ll find that you’ll start recognizing patterns during your technical interviews. Eventually you’ll start doing well on them.

If you get stuck on a problem, watch the video. Watch how they solve it, learn it, then do it yourself. Don’t expect to know everything. No one is judging you while you solve these. Just use it as the tool to learn.

Before I first found the platform, during my last round of interviews a few years ago, I found myself dreading the technical interviews. But then I signed up, and after working through only about 25 problems I started actually enjoying technical interviews. After 50 I was completing technical interviews with flying colors, including at the highest tier companies. I ended up getting offers from two excellent companies.

***

So while I”m not a fan of this type of interview, I understand it. And since so many companies use this as their measure, and gatekeeper it would be silly to self exclude yourself from so many potential opportunities. Being able to solve, at the very least, basic algorithms is the gate through which you’ll likely need to pass to get a great software engineering job.

But there is a path to get there.

And no, there’s no affiliate link, I’m not getting paid for this post either. It’s a great product that has helped me, and I wanted to share it with other people interviewing now too.