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.
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.