- The context:
One of the major challenges we face as software developers is continuous learning. Technology evolves so fast that it is almost impossible to follow the pace. Programming languages, frameworks, libraries, etc. are constantly being released with new versions and features. And the (unfortunate) trend in the market seems to be that the more technologies you know the more valuable you become.
I have been involved in quite a lot of job interviews during my professional career (most of the times as interviewed but also as interviewer). And I can count with my hand’s fingers on how many of them I have been asked about a concept so simple as an algorithm. An algorithm is the base where Computer Science lays on (I hope you know that). Every time we type a code using JavaScript, Java, C#, React, NodeJS or whichever technology we like, we are creating algorithms to solve a problem. We even use algorithms in our daily lives without even noticing.
Now let’s try to answer this simple question: how do you measure an algorithm complexity? Many people don’t know, others don’t remember, and a small minority would think about Big O notation.
How about data structures? Can you tell the difference between an Abstract Data Type (ADT) and a Data Structure (DS)? Is a LinkedList an ADT or a DS? What are the advantages of using an array over a linked list and vice versa?
How about operating systems? Can you tell the difference between a process and a thread? Do you know what is the difference between parallelism and concurrency?
I you could answer the above questions I congratulate you. A lot of developers I know couldn´t. Their answer was very simple: who cares? And they were right. Nobody cares about this stuff anymore. And this is wrong in so many ways.
- The problem:
While I was playing the role of an interviewer some while ago, I asked the candidates to implement an algorithm that could reverse an input list. I was just interested in a pseudocode, but they were free to implement the algorithm in their favorite language. Two of them immediately starting to type a for loop: for i = 0; i<array.length; i++ and they stopped trying to figure out the next steps (one of them didn’t complete it). Other two simply typed: output = input.reverse(). Fair enough. I replied that the exercise consisted of implementing that “reverse” function. Their answer: why should I do that if it is already implemented? Only one of them came up with a for loop starting by the end of the input array.
OK, it was an interview. We tend to get nervous and try to answer the first think that comes to our mind instead of taking a few minutes to think about the best approach. But I highlighted the answer that shocked me the most: why should we do that if it is already implemented? I understand that we must not reinvent the wheel, but does that mean that for every problem we face, we shall expect until someone else solves it first and then copy and paste the solution from stackoverflow?
Again: that mindset is so wrong in so many ways. As software developers (engineers or whichever title you put yourself on) our job should be to solve problems. Frameworks, programming languages, etc. are just tools that help us achieving our goal.
Of course, this is not entirely our fault. As I said in the beginning: the software developer market has been leading us to this for so many years so far. My advice: do not rely entirely on tools rather than your skills.
Happy coding!!
Top comments (1)
Thoughtful - thank you. I would contest that the whole 'machine' of education+employment+consumerism has been optimised to funnel value to those who define it, rather than solve worthwhile problems, hence the 'who cares' challenge... but let's leave my politics aside for now 😄
Algorithms are indeed useful, perhaps at a higher level of abstraction than you talk about here since Donald Knuth literally wrote the book on the lower levels? I would expect engineering and CS graduates to be familiar with this work, or equivalents, and know how to apply the analysis (big O notation, resource utilisation, hotspots etc.) to larger problem spaces such as distributed computing or business models, to engineer valid solutions, making good use of the algorithms that are well defined at lower levels. The difficulty of course is that such problems are less tractable and harder to interview on - which is why I would rather ask candidates to spend a day (paid) with a team and look at how they fit in, think through the real challenges the team face and offer their summary at the end of the day.