A closer look into how solving Algo/DS problems makes you a kick-ass developer

Alternative title: The ideal intent behind conducting an Algorithms and DS interview round

With start-ups growing their users base and solving real-world problems on daily basis, it is quite normal for us to believe that gone are the days when developers were hired based on how good they are with Algorithms and Data-structures, or the more common term for today, “Algo/DS”. In fact, a few companies out there have removed this round altogether from their hiring process.

Before we go any further and someone gets triggered, allow me to drop a quick note. While I strongly believe in having an Algo/DS round, I also understand that the way few of the orgs (or just the interview panel for that matter) conduct this round is a sheer waste of time, resources, and energy. In cases like these, I’ve ensured that I give my realistic and to-the-point feedback to the Talent Acquisition or the HR POC of the org.

Now let’s take a walk. Allow me to present my opinion.

Of course, an opinion stand-alone is NULL/nil. So I’ve attached a screenshot below that should back my opinion as well. Take a good look at it. (Entries are in reverse order)

Here the image shows different solutions I submitted for a single problem. Problem link: https://leetcode.com/problems/unique-paths-iii/.

The first solution took 420 ms along with 278 MBs to run

The second and third, with some modification to the first one took 444 ms with almost the same memory.

By this time, I was like, at least my solutions got accepted in one go 🏅

I spent some time thinking about the problem and then it clicked, maybe I am making it complicated more than it needs to be (basically over-engineering). I simply replaced one of the data structures (set) with another (a 2-d array.. a simple 2-d arrayyyyy!!!!). This time it took only 4 ms with 7 MBs to run. The numbers came down almost by 95%. All I changed was a Data Structure I was using to store the intermediate state.

The bottom line of the story, only after trying out different approaches/algorithms/data structures, you understand which one is going to be useful in which scenario.

That being said, below I’ve highlighted how at each stage of our careers, there is more and more need to practice these Data Structures and Algorithms.

Gives a kick-start to entry-level coders

Those at the entry-level in this field, don’t call themselves developers, they prefer CODERS! They are absolutely right. They know very little about the problems a dev solves on day to day basis. But when a dev is not on calls with PMs or debugging prod down or solving a customer issue, you’ll find them in a corner, writing classes, methods, loops, conditionals, and other kinds of code blocks (The OOPS realm). This is something that everyone learns at the elementary level only. Simply put, they get used to seeing solutions to different problems only a block of code away.

Helps you in minimizing courses for certificates

You claim you have in-depth knowledge of a coding language. Sure, but how do you think one will believe it? You say “I have certificates!”. “That’s amazing!! Let me ask a few questions. Why don’t you defend the credibility of your certificates? You game?”.

This may sound rude, but one can collect the certificates for all the courses out there but if they don’t practice it on regular basis, in near future, that knowledge is going to be alien. And let’s face it. No one buys what’s written on a certificate.

I am not saying certificates are a bad thing. Of course, they have a lot of merit in them. They show the candidate has prepared well. But then that will be visible in the QnA followed. No?

Reviewing the problems from different angles

There are different ways to solve a problem. Even brute force solves the problem. One could argue that even brute force solution is accepted for many solutions. Sure.. but does that mean you can’t do any better than that? Assume a case where you have lakhs of rows or documents to process and very limited compute resources. At the end of the day, the high availability of computing resources would mean high infra bills. And as we said, brute force is one way to solve the problem, maybe sorting the given data or applying hashing, or using a standard Data Structure like heaps will help reduce the time and compute resources taken by your code.

Bug-free code

However senior or junior a dev is, we all are humans. We all make mistakes. Some make them more often than not. As you practice DSA, you understand a few of the corner cases and next time those will be highlighted intuitively. This would imply fewer cycles b/w Devs and QAs.

The APIs/Services I write are built on top of MySQL, ElasticSearch, Kafka, Redis, and Mongo. And to top it off, I have support for pagination as well, that ought to account for something, right?

Sure... But what if the page size of a client request is North of 10000 rows? Multiple scenarios can be true like maps, service layers to process data from different sensors, etc.

And what if you have to write a cron? In a cron, you might have to process a large set of data at the application layer itself to prevent different DBs from getting bottle-necked.

Consider the above LeetCode problem. I was able to solve it. But take a look at what numbers I was able to achieve after optimizing the code. If we have limited knowledge about Data Structures, we’ll end up being in a state where our code will be taking more time and space to solve a problem. Results are usually high infra bills.

The point is, While hacks are a quick way to solve a problem, in the long run, try to solve the problem at the core engineering level. Not only you’ll get a better UX but also a better-engineered solution (and in turn a better bonus 💩).

Experienced developers are usually part of the hiring process

When an interviewee joins a video call (COVID version of walks into the interview room 😔), she/he places a tremendous amount of trust in the interviewer. After hearing out the problem, they (at least I do) believe that if I am gonna come up with 3 approaches, the interviewer not just is aware of all of them, but also understands the trade-offs involved when a specific approach is picked. In fact, is aware of a few other algorithms which could change the time/space complexity drastically. One quick hack around is to ask only specific questions from all your interviewees. Umm… but then Glassdoor and LeetCode discuss are real forums. So unless you want to judge someone on how well they Google before the interview, this hack won’t work.

Another one is to spend a lot of effort finding a good problem and doing research over it. On the other hand, if you practice regularly, you understand all these approaches in your day-to-day life as well.

Let me know if you think some aspect has been overlooked and I’d be happy to modify this for the broader audience.