As a Software Developer, I started my journey in the Software Industry at Novell from where I moved to Citrix and later to Amazon. Being in this industry for close to 6 years now, I have met and learnt from many wonderful intellectuals and have worked with them on various top class products that directly or indirectly impact billions of lives worldwide.

I have experienced diverse corporate cultures, working environments, software development practices and processes. During this journey where I accomplished some distinguished feats and also committed many silly mistakes, I have learnt lot of things of which I think some should be helpful and of interest to the aspiring Software Engineers. This is the second one in the series. [Other articles are available in my author handle below linked below this article. Feel free to check out all of them]

Algos and Big-O

I started learning software development in C language. If you have worked with this language, and most probably you would have, you would agree that it is imperative to learn and know data structures and algorithms when you have finished learning the very basic stuff and want to move forward. Fortunately or unfortunately, new languages have made things lot easier by providing in-built comprehensive libraries for most of the operations you would need in most of the situations. However, that doesn't undermine the importance of knowing the algorithms and Big-O notation.

During your career, you are not going to write trivial code always. When facing complex algorithmic or architectural problems, you might need to figure out or devise algorithms to solve them. You may need to identify which algorithm may work better and in what conditions or may even need to use a combination of multiple algorithms. Moreover, you cannot expect the vendor to always provide exactly what you need. Good knowledge of algorithms is definitely helpful in becoming a better software professional.

The Big-O-Notation is used to represent the complexity of an algorithm as a function of the size of the input n. It's a standard way to estimate the time and memory consumption by an algorithm depending on the size of the data. You can be confident of getting asked complexity related questions in the tech interview rounds of any software giant. Big companies are particular about not selecting people who don't have an understanding of this concept because on small data set, all algorithms may appear to perform more or less same, but if applied on massively scaled systems, expensive algorithms may cause enormous negative impact.

Therefore, my sincere suggestion is to learn and understand various important algos and Big-O notations. Though they are difficult to grasp in the beginning, you'll later continue to reap the benefits of having that knowledge.
This is first of the things that I seriously think an aspiring Software Engineer should know. Keep watching for more. If you are keen on learning more about the better software development practices you can start following right from the college days, do get a copy of my first book "Hello World - Student to Software Professional" published by Partridge (A Penguin Random House Company). Now available worldwide on all the MAJOR ONLINE Stores - Amazon, Google Play, Flipkart, Barnes & Noble and many others.