On his "Ask me Anything", I asked Nick Karnik what was his initial path to have such successful career, you can see his full answer here, but the part I found most interesting and the one that made me do this post was this part (the bold is mine):
Although it appeared like I was all over the place, everything I did, enhanced my resume and helped hone my skills around problem-solving. This is the basis for being successful in the long-run. You have to keep learning all the time and get to a point where you can do just-in-time learning. Once you know a programming language like C++ very well, you can pretty much learn anything. Other than that you want to focus on Data-Structures, Algorithms, and Design Patterns.
The best advice I can give is to worry about yourself and forget about what everyone else is doing. Forget about the frameworks of the day and libraries of the year. Come up with a plan and stick to it. Learn programming like it's the 90's and focus on the basics and practice on real-world projects.
The parts in bold are the most important for the theme of this post: algorithms and data structures. He gave the advice to learn them and, in the end, to learn programming like it is the 90's. That's exactly my impression about learning and deeply knowing algorithms and data structures these days, is not a thing from the 90's and are already more than solved? Why worry learn them?
I have the feeling that many people reading this will pick the torches and start to hunt me for this heresy, but let me explain better. While I was at college I learned the majority of the data structures and some basic algorithms, but the classes always gave me the impression that it was something just to the students have a strong basis, learn how to think logically, among other things, but not to know by heart how to implement them, just understand was enough. Despite forgetting the complete explanation and some other details, I know what is a queue, a stack, trees, graphs... For example I do remember about call stacks and its importance in programming, since I have to deal with it daily, I remember about trees and its good use for searches, the famous binary search, graphs and the problem to find the shortest path, these kind of stuff.
However, after an experience with how Google selection process works, I found that it was not enough just understand empirically, but you had to understand deeply, including implementation of all of them. For those who are not familiar, Google makes a phone interview with a Google Docs viewed by you and the interviewer where they test just that, all these algorithms and data structures, according to the process description. It was a big list of algorithms and data structures and although I saw many familiar names, I was sure that I wouldn't be able to prepare well enough in 2~3 weeks, the time between the first contact and the interview, so I asked to withdraw from the process before any appointment was established. I could have done the interview anyway despite not being ready, but I decided not to, I don't think it would be beneficial, instead I made the purpose to get better and try again afterwards. Wait for me!
I'm about to put some effort on this end because after that I found that not only Google requires such knowledge, but also many other companies. It may sound strange to many people, but it was new to me since I was focusing on web development, where many of the positions don't require this knowledge explicitly.
Despite having this purpose though, to get better at the basics, the question still remains... Why is still so important to know such algorithms and data structures when they are already more than solved for the most part, with ready implementations just waiting to be used? Why big companies seek for this kind of knowledge at this day and age?
PS: The more I read articles here from more experienced developers more I conclude that the hole is deeper than it looks now, learning a lot. Thanks for that! :D
PS²: The part where Nick says "Forget about the frameworks of the day and libraries of the year." is food for another post, really.
Top comments (13)
There’s some food for thought here, but I would strongly encourage all of us not to look at the recruiting practices and interviewing techniques of the ‘big 4’ as the gold standard. They are woefully inefficient (I’ve worked for 2 of them, this isn’t just envy).
But if your goal really is to get a job at google or Facebook or amazon, then, yes, just being a rockstar at algorithms and data structures is what you should concentrate on.
This is interesting, why do you think they are inefficient? I honestly like the idea of a live coding interview like this, it is better than a project they describe to you and you have to send to them in some days or a cold multiple choices test. I experienced both in the past.
It is not actually my goal right now, just the desire to be prepared if the opportunity arises. Right now I'm more worried about getting better at web development, the area I really like and study algorithms when I have time.
Because the experience in the interview bears virtually no resemblance to the daily requirements in the job. This means that your success (or failure) in the interview is not a good indicator of your success (or failure) in the position.
To get more specific and to pick one of those companies, Amazon’s turnover rate is sky high, but they’ve chosen to optimize by hiring at an insane pace to compensate (rather than to optimize on improving retention), which means their hiring practices are optimized for volume, not quality.
This is true for almost every interview I had in the past years, they never resemble what you actually do when you are able to go in. There job descriptions that requires many technologies they don't even use either. It is not particular from big companies.
I've heard about that although there divided opinions about Amazon specifically, it looks an awesome place to work and I've heard contrary opinions as well. In the end it depends, like anything else...
In my work we have to type of projects. Those that have to be durable in time, in which we use vanilla php, vanilla js.
Also we have projects that are "efforts for one year", in which we use frameworks like laravel, symphony... And others.
Our experience is that frameworks have, in general, a bad tendency to "rewrite everything and make it incompatible with older versions". Our very first deception was a library called YUI2. Now our deception is called "older version of laravel".
Only codeigniter has passed the "age well" tests!
Frameworks went and go. You can learn framework X very well, but this will kill you in no more that 3-4 years.
Learn vanilla and you would be able to do relearn anything quicker and easier that if you just "learn to use a framework"
It's not the framework's fault that you have to rewrite everything.
You can take measures to make the framework replaceable. Some frameworks make this a little easier and safer and some make it a terrible experience (read: ActiveRecord ORMs) forcing the team to write a lot of code to protect the application.
However you bring up a good point that not all applications need to be built framework agnostic. If the lifespan of an application is one year then it's probably a lot more cost effective to just go with framework's best practices. But is it easy to say how long the lifespan can be? 🤔
It depends on the culture of the language community for the most part. In Java community there is always the care to make things compatible to older versions in Java language itself. It is rare, as far as I know, to have any serious problems when you update from one version to another, although caution is always necessary. For frameworks, the same mindset generally applies, at least for the major frameworks I generally use, Spring at the top of the list, it has 15 years and I think it aged well. In Java there are many standards that are just implemented by various frameworks, so jump from one to the other is not very hard.
I don't see Spring going anywhere as far as web development goes, but if another new shiny framework comes, it will not be very hard the transition by what I know of how things work in Java.
Another I have contact is Javascript, this one... Angular is totally different from, React, which is totally different from VueJs... It is hard...
(I think) Because their employees may, sooner or later, encounter a new complex technical problem that is not on stackoverflow, as a side effect of being few of the first companies that does something new or reach a threshold, example they had to build a database and a file system in 2003-2005 to handle petabytes of data.
Also if you know CS you will write better code, even if you work with frameworks you will understand the tradeofs, especially when it comes to performance. And performance matters when you have 1M servers, and if you can reduce the load by 10% you can add a value of millions of $ each year.
I see, it makes sense, you really cannot imagine what problems such companies' employees face everyday, this experience would already be very valuable.
You are right, as a web developer I face performance problems very often, mainly from databases, the biggest bottleneck in web development.
I really like the idea of learning to program like it's the 90's! :)
Personally i've been heavily focusing on OOP bestsellers for a year now. Let's look at a few of them:
1999 Refactoring (Martin Fowler)
2003 Domain Driven Design (Eric Evans)
2004 Working effectively with legacy code (Michael Feathers)
2004 Object thinking (David West)
2009 Clean Code (Robert Martin)
Newest book is nine years old and frankly contains a lot of stuff discovered a earlier in other publications. So even though not the 90's exactly but early 00's. Focusing on general problems builds a more solid foundation than running after that new shiny thing that came out last month. A nice side-effect of course is, that adoption of new technologies is a lot more easier after understanding what issues these techs are trying to address.
Also one more important note. Software development is not all about programming. There's a lot going on in understanding what goes on in client's problem space and modeling together and solving those issues in solution space. This of course seems painfully obvious but making this important distinction has made my life a little easier.
And about your title and sugesstion that the algorithms are absolute, I can say that most of the alg we use today were developed ages ago. We cannot see them because we work at a more abstract layers.
Computer science havent evolved that much in the last decades.
I should have put "Learning Algorithms and Data Structures in the 21st century" now that I think about it. That was what I'm trying to say, indeed most of the algorithms are out there since the invention of the computer.
Oh, my bad 😀