Algorithms, Big O & technical interviews…a lesson.
Hello again ! My last couple of blogs have been about design patterns and I really enjoyed learning about all the different ones but in the technical interviews I’ve done, no one has asked me to code any design pattern. Algorithms is all that technical interviews are about and I used to hate them, I still kind of hate them. Like with everything else hate is a product of fear and fear the product of not knowing or understanding. In my mind I made algorithms this very complicated concept that only super software developers know how to tackle. Big O notation? Even more scary! I’d hear things like ‘O of n’, ‘time complexity’, ‘efficiency’, etc… All these words just sounded like what the hell did I get myself into? The idea of doing a technical interview especially while someone is watching me gives me so much anxiety. I recently interviewed with Amazon and it was my first technical interview ever. I knew that with Amazon I would of course have to do a coding interview where I would be watched but I wasn’t expecting it to be the first interview ! The questions I was asked to code weren’t even difficult but my anxiety and lack of being prepared got the best me & I didn’t advance in the interview process. It was then I realized my fear of algos, Big O, and technical interviews had cost me what we all know would have been a great opportunity for a junior developer. At that moment I made the commitment to myself not just to really dive into algos but really understand them and not just to get through an interview but because it will make me an efficient developer.
Algorithms are just problems that you solve using code. Remember in school you’d get a word problem like Billy has 10 apples and he gives Mikey 4 of those apples and then he meets up with Sally and give her 5 apples, how many apples does Billy have? It’s adding and subtracting right, but how would you tell your computer to solve that problem? And the way you write that code affects how efficient that code is & by efficient I mean how long is it taking your machine to execute what you’re telling it do? And depending on how many apples Billy has makes a big difference on how long that takes.
This block of code shows a Linear Time Complexity, this means that the more data you have the more time it will take to process it, the increase is linear or in a line. Each item in the code will have to be processed one at a time. In the screenshot, I show a visual representation of this. Whatever parameter is passed in, it will loop over that many times.
Since the time it takes code to execute can vary so much on different things such as the machine you’re using, other applications running in the background etc. This isn’t a recommended way to measure time complexity because how much it can vary. Performance.now() is a JS method that returns a timestamp, measured in milliseconds.
A Linear Time Complexity or also known as O(n) isn’t the most efficient way to write code, but sometimes Linear is the best case.
Since I’ve started to get more relaxed with algos, I’m going to pivot from design patterns and really dive into algos. More importantly write about them so they don’t seem so scary. Thanks for reading !!
