One of my problems is timed algorithm test, such as by hackerrank. You have to pass it to be considered for next step for some company, of course... it's cheap. They don't need to spend a single minute on you, but you need to spend at least 2 hours. In the projects I do, I really don't see those used much... I don't mind studying some CS stuff as they can help general logical problem solving thinking, but I tend to forget them if I don't use them, such as practice I wrote here ... I also bought that huge green brick Cracking the Code Interview which I still haven't finished...I often feel the projects I built said enough about me but surprisingly not many really check that. Do I need to continue DS and ALGO until I can ace those tests?
Appreciate your response, Annie -- when I was searching for work for the first time. I used to waste endless energy thinking about the same things that you did, rationalizing them even, and selectively finding people that were "successful" to reinforce them.
I was lucky enough to land two of my first roles barely knowing data structures and algorithms. I was a "front-end" developer with a strong HTML and CSS and decent JavaScript background. You're not wrong -- what you describe gets you in the door, but doing the same thing for year after year if relegated to client-side JS where things change fast and flame wars over frameworks are a staple, it gets old really really fast (at least for me it did). I ended up having to peel back the covers of several libraries, patch the issue, push it upstream to the original maintainers. This gave me a taste of what seemed "cool" and I recall how nice reading code from a well-maintained library on GitHub was compared to the code written at most companies internally and said, "Wow! I wanna do this!"
I began just poking around into other source code available on GitHub for libraries I've used and it made me realize how apparent my lack of fundamentals was. It wasn't enough to push me to study some CS like you did, though. I finally swallowed the pill when I was trying to switch roles -- I was targeting big tech companies (prestige, pay, and hopefully talented people). I read up a lot on how to prepare for them and had to come face to face with what you're feeling now with regard to HackerRank and phone screens. I ended up taking a highly recommended algorithms course (the one by Sedgewick and Wayne) on Coursera -- eye opening experience. I remember seeing words that I've seen before and going, "Oh! Oh! Oh!". I took many other courses and watched countless YouTube videos when I was practicing problems on LeetCode (~150 problems). It was downright grueling and difficult. It wasn't all bad though, because some of the problems were very realistic and they absolutely challenged the hell out of me...
Have I ever used them in everyday work? No. I can't say that I have. I have used recursion many times and here are a few examples: parsing JSON from an API and navigating its nested structure to convert them back into "domain objects" (i.e. JSON representing a person) back into an actual person object with methods and all. Instead of writing custom parsing code for every type of entity or resource that could be returned from the API, I wrote a general recursive parser, and all it needed to be fed were a list/array of fields/nested fields that needed to be parsed. Secondly, I wasn't aware while studying data structures and algorithms how useful they actually were -- more than people know. A side-effect is: I cannot NOT think about performance implications of even the smallest bit of code that I write or that anyone else writes. It is immediately obvious to me when people do repeated work and what its algorithmic complexity is in big-O notation. It is immediately obvious to me when I see nested for loops and the performance implications this could have if the data set each of those loops is going through is too large -- I experienced this first hand when a coworker had three loops across three different data sets requesting over hundreds of thousands of records in each across three different tables (M x N x K). It exceeded the storage (memory capacity) of the machine and took it down in production. Knowing advanced algorithms shouldn't be necessary. For that I'll defer to one of the best pieces that I've seen written: Data Structures & Algorithms I Actually Used Working at Tech Companies. The author worked as a principal engineer and led a team at Uber. I thought the author was going to continue pushing why they matter, but it was a refreshing piece to read and I think you'll find that it is, too.
People can certainly build a career or even design shop from avoiding anything that touches computer science related topics, but it's nearly impossible not to encounter them as a full-stack developer and most certainly as a back-end developer and most certainly beyond the web-stack (where most of my interest currently is).
CTCI is a great book. I only use it for the first four chapters as those are invaluable, especially the part covering algorithmic complexity in big-O notation and its exercises. The reason I can do big-O analysis is because of that book and its exercises. The book that I use, with some harder problems, but is not necessary, but matched more closely with problems that I've seen in the current climate is Elements of Programming Interviews.
If you're convinced now that you should study them, I do recommend a full algorithms course -- maybe not what I did, because it's much longer, but ones I really like are:
MIT OpenCourseware - Intro to Algos. I usually watch videos at 1.5x+. Erik Demaine is really good
Data Structures in 8 hours by William Fiset, a Google engineer and former competitive programmer. People that do CP are EXTREMELY good at them
JavaScript Algorithms and Data Structures Masterclass - I have never done this one myself, but have done mock interviews with friends that are interviewing and have done the course and I've seen some of the content through their screen-shares -- some solutions I agree with and others I didn't, but some are also really good
Lastly, I'll leave you with something that stuck with me when I first read it:
There are 2 types of software engineer: those who understand computer science well enough to do challenging, innovative work, and those who just get by because they’re familiar with a few high level tools.
Both call themselves software engineers, and both tend to earn similar salaries in their early careers. But Type 1 engineers progress toward more fulfilling and well-remunerated work over time, whether that’s valuable commercial work or breakthrough open-source projects, technical leadership or high-quality individual contributions.
The above comes from a site called, "Teach Yourself CS" here. The creators of the site are people I know personally.
I know I've made this an essay, but feel free to message me if you've other questions
Wow thank you so much David! Maybe you should write this into a full post called should you learn computer science as a self-taught developer? For me, I am not against it as you can see... I've read Grokking the Algorithm book, took a crash coding interview course + did some practice exercises, bought CTCI (haven't finished), and got Colt Steele's udemy course you mentioned (to-do list)... I'm also planning to do Standford's algorithm specialization on Coursera. It's just all those take a lot of time... while CS grads have 4 years to slowly digest those before they specialize, we self-taught ones don't have that luxury. We pick a few tech stack we like and whip out projects without asking too much so we could land a job.... yes, I believe you, eventually questions will surface and we will need to dive deeper. So for me it's a matter of.... what should I prioritize? I only have limited of time to dedicate, and there are tons of stuff to learn (esp in front-end or web dev in general), some are fun and useful, which I enjoy such as Svelte, some are not so such as algorithm. Personally I like creative stuff I saw on Awwwards, when websites are ugly, even they're fast and functional, or they're beautifully written inside, I don't enjoy working on them. Maybe that's the dilemma, I am not a pure software engineer, I want too much, and need two brains or three to do all. When did you realize that you want to dive deeper in the CS? I started that after 1 year of coding, when I realize they actually tested you those for the job.... >.< But I haven't felt it helped me in my "job" yet.
Perhaps -- because this comes up a lot and I feel like not enough from self-taught engineers. I re-started my blog about two months ago, and I think I'll copy what I shared with you over in a more extensive piece that's sectioned so I can point friends and people that I'm working with and myself for future reference to it :)
Grokking Algorithms is neat! I've only done a cursory look at its contents.
Super question! I forgot to mention that resource overload was a thing. I know about almost all the books, courses, and resources for interviewing. I remember trying to find the "best one" based off others opinions rather than my own. It was a poor use of time. All the resources are helpful, but they speak to different people differently. I encourage people to not do what I did, but stick to one book and one practice site (for me it's been EPI and LeetCode), but I do reference The Algorithm Design Manual from time to time.
But for what you're optimizing for -- interviews and passing HackerRank tests, you have to put it into practice. A lot of the problems are just "tricks" like "sliding window technique" with two pointers that aren't covered in enough detail (if at all) in algo courses. A single quick run through of any algorithms course should be enough even if the ideas don't stick. Once you do problems and read discussions on LeetCode (if you're using this resource), you can come back to your original resource and revisit how the algorithm or data structure is used and then make attempts to transfer it to your problem. One thing that is also worth mentioning is rather than trying to understand the code that someone else is explaining, first and continuously ask, "How? What led this person to think of this?" It makes your mind think differently about problems and think of them in terms of tools/ideas/concepts to throw at problems rather than the specific details about how to solve ONE very specific problem -- as that becomes an issue in real interviews when you recognize that you've seen a problem and then try to remember the steps to solve it instead of, "Oh! I see this pattern! Can I try X" (e.g. I need top 5 items -- can I use a heap here?)
You're right -- we don't have the luxury of focusing on just school, but you'd be surprised to learn that most CS and software engineering students are literally subjected to only a single algorithms course and don't realize until they attempt to transfer their learning into an internship or full-time offer that they, too, are subjected to what you and I are. TripleByte has a blog post on how bootcamp grads perform versus CS grads -- slightly stronger overall in data structures and algorithms, but it's not a large of a gap as you think. Both need to revisit and do problems just to get in! CS grads just get more eyeballs and recruiters reaching out to them early on.
When I study for interviews, I struggle with focus, too until I've created a regimen and stick with it, because it's far more fun digging into other technical topics or learning new programming languages than it is for me to do practice problems again, but once I'm in the swing of things, it's not too bad, and once you've really learned them through sheer effort powering through many problems, believe me, you won't forget them -- maybe how to do them, but you'll recognize the problem and have an idea about what you can throw at it even if you can't do it. It'll stick with you forever :)
But do trust that this climate is probably worse if not more worse than the '07/'08 financial crisis. Every company is starving for senior engineers and that's where most of the budgets are allocated. Without a senior around, a newcomer doesn't know what they don't know and some of it can have dire consequences and can be extremely costly for the company (if it's a small shop or start-up). Only the big companies can really afford to hire juniors at this time and they're getting slammed!!! The best way to get into companies right now is to find open positions, find people (engineers/designers), message them personally, and ask for a referral. A lot of people I know don't want to do this, instead churning through 1000s of applications with barely a callback -- it is demoralizing. But this only also works if the person's demonstrably hire-able -- public works are presentable, somehow displays a desire to learn among other things...
Yeah you should definitely write some blog posts about all those things we talked. :) I often feel there are a lot of sources and don't know where to begin... >.< For instance I choose the standford one for algorithm over princeton one is because I heard that one is more on theory rather than a specific programming language. Some people curate a list of 250 podcasts to listen to, 100 programming books you should read etc.... it's just overwhelming.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One of my problems is timed algorithm test, such as by hackerrank. You have to pass it to be considered for next step for some company, of course... it's cheap. They don't need to spend a single minute on you, but you need to spend at least 2 hours. In the projects I do, I really don't see those used much... I don't mind studying some CS stuff as they can help general logical problem solving thinking, but I tend to forget them if I don't use them, such as practice I wrote here ... I also bought that huge green brick Cracking the Code Interview which I still haven't finished...I often feel the projects I built said enough about me but surprisingly not many really check that. Do I need to continue DS and ALGO until I can ace those tests?
Appreciate your response, Annie -- when I was searching for work for the first time. I used to waste endless energy thinking about the same things that you did, rationalizing them even, and selectively finding people that were "successful" to reinforce them.
I was lucky enough to land two of my first roles barely knowing data structures and algorithms. I was a "front-end" developer with a strong HTML and CSS and decent JavaScript background. You're not wrong -- what you describe gets you in the door, but doing the same thing for year after year if relegated to client-side JS where things change fast and flame wars over frameworks are a staple, it gets old really really fast (at least for me it did). I ended up having to peel back the covers of several libraries, patch the issue, push it upstream to the original maintainers. This gave me a taste of what seemed "cool" and I recall how nice reading code from a well-maintained library on GitHub was compared to the code written at most companies internally and said, "Wow! I wanna do this!"
I began just poking around into other source code available on GitHub for libraries I've used and it made me realize how apparent my lack of fundamentals was. It wasn't enough to push me to study some CS like you did, though. I finally swallowed the pill when I was trying to switch roles -- I was targeting big tech companies (prestige, pay, and hopefully talented people). I read up a lot on how to prepare for them and had to come face to face with what you're feeling now with regard to HackerRank and phone screens. I ended up taking a highly recommended algorithms course (the one by Sedgewick and Wayne) on Coursera -- eye opening experience. I remember seeing words that I've seen before and going, "Oh! Oh! Oh!". I took many other courses and watched countless YouTube videos when I was practicing problems on LeetCode (~150 problems). It was downright grueling and difficult. It wasn't all bad though, because some of the problems were very realistic and they absolutely challenged the hell out of me...
Have I ever used them in everyday work? No. I can't say that I have. I have used recursion many times and here are a few examples: parsing JSON from an API and navigating its nested structure to convert them back into "domain objects" (i.e. JSON representing a person) back into an actual person object with methods and all. Instead of writing custom parsing code for every type of entity or resource that could be returned from the API, I wrote a general recursive parser, and all it needed to be fed were a list/array of fields/nested fields that needed to be parsed. Secondly, I wasn't aware while studying data structures and algorithms how useful they actually were -- more than people know. A side-effect is: I cannot NOT think about performance implications of even the smallest bit of code that I write or that anyone else writes. It is immediately obvious to me when people do repeated work and what its algorithmic complexity is in big-O notation. It is immediately obvious to me when I see nested for loops and the performance implications this could have if the data set each of those loops is going through is too large -- I experienced this first hand when a coworker had three loops across three different data sets requesting over hundreds of thousands of records in each across three different tables (M x N x K). It exceeded the storage (memory capacity) of the machine and took it down in production. Knowing advanced algorithms shouldn't be necessary. For that I'll defer to one of the best pieces that I've seen written: Data Structures & Algorithms I Actually Used Working at Tech Companies. The author worked as a principal engineer and led a team at Uber. I thought the author was going to continue pushing why they matter, but it was a refreshing piece to read and I think you'll find that it is, too.
People can certainly build a career or even design shop from avoiding anything that touches computer science related topics, but it's nearly impossible not to encounter them as a full-stack developer and most certainly as a back-end developer and most certainly beyond the web-stack (where most of my interest currently is).
CTCI is a great book. I only use it for the first four chapters as those are invaluable, especially the part covering algorithmic complexity in big-O notation and its exercises. The reason I can do big-O analysis is because of that book and its exercises. The book that I use, with some harder problems, but is not necessary, but matched more closely with problems that I've seen in the current climate is Elements of Programming Interviews.
If you're convinced now that you should study them, I do recommend a full algorithms course -- maybe not what I did, because it's much longer, but ones I really like are:
Lastly, I'll leave you with something that stuck with me when I first read it:
The above comes from a site called, "Teach Yourself CS" here. The creators of the site are people I know personally.
I know I've made this an essay, but feel free to message me if you've other questions
Wow thank you so much David! Maybe you should write this into a full post called should you learn computer science as a self-taught developer? For me, I am not against it as you can see... I've read Grokking the Algorithm book, took a crash coding interview course + did some practice exercises, bought CTCI (haven't finished), and got Colt Steele's udemy course you mentioned (to-do list)... I'm also planning to do Standford's algorithm specialization on Coursera. It's just all those take a lot of time... while CS grads have 4 years to slowly digest those before they specialize, we self-taught ones don't have that luxury. We pick a few tech stack we like and whip out projects without asking too much so we could land a job.... yes, I believe you, eventually questions will surface and we will need to dive deeper. So for me it's a matter of.... what should I prioritize? I only have limited of time to dedicate, and there are tons of stuff to learn (esp in front-end or web dev in general), some are fun and useful, which I enjoy such as Svelte, some are not so such as algorithm. Personally I like creative stuff I saw on Awwwards, when websites are ugly, even they're fast and functional, or they're beautifully written inside, I don't enjoy working on them. Maybe that's the dilemma, I am not a pure software engineer, I want too much, and need two brains or three to do all. When did you realize that you want to dive deeper in the CS? I started that after 1 year of coding, when I realize they actually tested you those for the job.... >.< But I haven't felt it helped me in my "job" yet.
Perhaps -- because this comes up a lot and I feel like not enough from self-taught engineers. I re-started my blog about two months ago, and I think I'll copy what I shared with you over in a more extensive piece that's sectioned so I can point friends and people that I'm working with and myself for future reference to it :)
Grokking Algorithms is neat! I've only done a cursory look at its contents.
Super question! I forgot to mention that resource overload was a thing. I know about almost all the books, courses, and resources for interviewing. I remember trying to find the "best one" based off others opinions rather than my own. It was a poor use of time. All the resources are helpful, but they speak to different people differently. I encourage people to not do what I did, but stick to one book and one practice site (for me it's been EPI and LeetCode), but I do reference The Algorithm Design Manual from time to time.
But for what you're optimizing for -- interviews and passing HackerRank tests, you have to put it into practice. A lot of the problems are just "tricks" like "sliding window technique" with two pointers that aren't covered in enough detail (if at all) in algo courses. A single quick run through of any algorithms course should be enough even if the ideas don't stick. Once you do problems and read discussions on LeetCode (if you're using this resource), you can come back to your original resource and revisit how the algorithm or data structure is used and then make attempts to transfer it to your problem. One thing that is also worth mentioning is rather than trying to understand the code that someone else is explaining, first and continuously ask, "How? What led this person to think of this?" It makes your mind think differently about problems and think of them in terms of tools/ideas/concepts to throw at problems rather than the specific details about how to solve ONE very specific problem -- as that becomes an issue in real interviews when you recognize that you've seen a problem and then try to remember the steps to solve it instead of, "Oh! I see this pattern! Can I try X" (e.g. I need top 5 items -- can I use a heap here?)
You're right -- we don't have the luxury of focusing on just school, but you'd be surprised to learn that most CS and software engineering students are literally subjected to only a single algorithms course and don't realize until they attempt to transfer their learning into an internship or full-time offer that they, too, are subjected to what you and I are. TripleByte has a blog post on how bootcamp grads perform versus CS grads -- slightly stronger overall in data structures and algorithms, but it's not a large of a gap as you think. Both need to revisit and do problems just to get in! CS grads just get more eyeballs and recruiters reaching out to them early on.
When I study for interviews, I struggle with focus, too until I've created a regimen and stick with it, because it's far more fun digging into other technical topics or learning new programming languages than it is for me to do practice problems again, but once I'm in the swing of things, it's not too bad, and once you've really learned them through sheer effort powering through many problems, believe me, you won't forget them -- maybe how to do them, but you'll recognize the problem and have an idea about what you can throw at it even if you can't do it. It'll stick with you forever :)
But do trust that this climate is probably worse if not more worse than the '07/'08 financial crisis. Every company is starving for senior engineers and that's where most of the budgets are allocated. Without a senior around, a newcomer doesn't know what they don't know and some of it can have dire consequences and can be extremely costly for the company (if it's a small shop or start-up). Only the big companies can really afford to hire juniors at this time and they're getting slammed!!! The best way to get into companies right now is to find open positions, find people (engineers/designers), message them personally, and ask for a referral. A lot of people I know don't want to do this, instead churning through 1000s of applications with barely a callback -- it is demoralizing. But this only also works if the person's demonstrably hire-able -- public works are presentable, somehow displays a desire to learn among other things...
Yeah you should definitely write some blog posts about all those things we talked. :) I often feel there are a lot of sources and don't know where to begin... >.< For instance I choose the standford one for algorithm over princeton one is because I heard that one is more on theory rather than a specific programming language. Some people curate a list of 250 podcasts to listen to, 100 programming books you should read etc.... it's just overwhelming.