Picture this. You're in your 3rd job and your career has progressed a lot. In a software developer's life, that would mean you've learned lots of different technologies and gained lots of experiences working with various platforms. This might also mean you've gained non-technical experiences like leading teams or client interaction.

Then one day you wake up and decide that it's time to move on. It's time to go and look for a new job. You submitted your resume to several companies and scoured LinkedIn for interesting job postings. Eventually you got some favorable responses and after a few emails, you're now in line for a couple of interviews.

Depending on the role you're applying for, the questions will primarily be focused on your target role and technology which is most likely closely related to your latest experience. But as developers, we all know that there a category of questions that will almost always be asked regardless of the role you're applying for  — algorithms.

Don't lose them. Let them linger at the back of your minds.

Let's face it, with all the development worked you've done for the past years, did you really have the time to actually implement and use your own sorting algorithm for a live project? Let's say that once in a while you had to implement your own custom sorting algorithm for very special circumstances. How many times did you actually have to do that?

I'm not saying these concepts are useless. What I'm trying to say is that with years of experience and years of translating high-level business requirements into code, there is a high chance that developers get out of touch with these core concepts.

But in reality, as developers, we should always keep these concepts very close to us. In fact, based on my own experience, I often apply these concepts in my daily work. I just don't realize that I'm doing so.

This is why technical interviewers want to ask you about them. They want to know if you're still able to explain the concepts. Ideally, interviewers shouldn't expect you to memorize names. They should be able to extract your understanding of some of these concepts. At least that's how I did it when I became a technical interviewer myself.

But there are lots of them!

Let me reiterate. Interviewers just want to get a glimpse of your understanding of some of these concepts. As you can see, I'm not using the word "all" here. No one should expect something like that from you.

Honestly, if your interviewer seems like he knows all the algorithms in the world, there are 2 possibilities to it. First is either he really practices using all of them in his daily routine (good for him!). Second is he's been doing interviews for quite a while, so he regularly brushes up on them.

Either way, regardless of wherever your interviewer falls in the above two possibilities, their whole strategy will most likely revolve around this: "How comfortable is this candidate when it comes to explaining or discussing algorithms?"

My suggestion is for you to ensure that prior to going to these types of interviews, you brush up on your algorithm knowledge. Pick a few that you can have a comprehensive understanding of. Then, do a high-level review of a couple more.

Which ones should I select?

This next part is based on my experience as an interviewee and of course, as an interviewer. I'll share with you how I choose which algorithms I usually review before going for an interview.

Technical interviewers may ask you to write pseudocode, or even use a specific algorithm to solve a problem on the spot. Based on my experience, the test for algorithm knowledge usually revolves around the ff. categories: Sorting, Path Finding and Text Parsing.

Sorting

I always have Quick Sort ready. Regardless of your choice, the idea is to have a sorting algorithm ready when tackling technical interviews. Sorting-related technical problems are always around the corner. Honestly, with all the out-of-the-box sorting functions we use in our daily lives, studying algorithms under this category is very, very vital. You don't want to be known as "that candidate who just uses functions without understanding how they work".

Path Finding

There are lots of algorithms for path finding out there. I personally review BFS, DFS and A* before any interviews. For BFS and DFS, note that it will be better if you're able to implement them in either a recursive or iterative approach. In other algorithms (like A*), there's a concept of a heuristic. For these, make sure you understand how to identify the correct heuristic for a given problem.

Text Parsing

This can include manipulating strings or implementing your own Regular Expression engine. I personally believe this category is the trickiest among the 3. In fact, with text parsing, you're often required to mix and match other algorithms in your solution.

Finally, practice!

Let me emphasize one thing. Whatever set of algorithms you pick, always practice! It is very important to know the ins and outs of each algorithm. In some cases, you may even be asked to combine or expand existing algorithms to solve particular problems. Other interviewers may even ask you to compare the pros and cons for different algorithms.

Additionally, you can primarily focus on the algorithms you pick based on the categories I mentioned above; but, also ensure that you get a chance to have a high-level understanding of other algorithms as well. Remember, it's your understanding that's being tested and not your memorization skills. It doesn't matter if you can write the pseudocode perfectly. If you're not able to explain it, then that's not going to reflect well for you.

Lastly, if you're asked about an algorithm you don't know anything about. Don't lie. Don't make up an algorithm just based on the name. In this situations, it's better to be honest. Interviewers are trained to dig deeper especially on answers they feel are untrue. The more they dig up, the more you get in trouble. Just say you don't know that specific algorithm. More often than not, your interviewer will ask you about another algorithm or let you pick which one you want to discuss.

Anyway, here's to hoping for a successful next technical interview for you! Cheers!

Cover photo from LinkedIn Sales Solutions on Unsplash