My advice is don’t give up quite yet. I had a drum line coach who was also a biology professor. One day he told us that when we practice we needed to have proper technique and take the practice deliberately. He said otherwise we would be doing ourselves a disservice, and that we would effectively be undoing part of what we’ve done.
He then told a story of one of his biology students. He said that one of his students came to him after failing a test, and said he studied for many hours before the test and was asking for his score to be improved. My drum line coach then said he told the student that he wouldn’t raise the grade, but instead in my own opinion decided to teach him a valuable life lesson. He said to the student you need to be studying smart and not hard. He then told our drum line that we need to do the same with our practices.
I bring up this story not to say you’re not working hard. I believe you have met that criteria. Maybe though you are not doing things as efficiently as you would be able to if you had the right resources.
Also, with all that said in my opinion a lot of day to day software engineering is different than competitive programming like interview questions. I wouldn’t be too stressed not being good at the interview questions, because it’s so different. I also wouldn't be stressed that you don't enjoy it. Although since it’s a good idea to have a job you may need to meet these somewhat odd demands of getting a software job.
I took a class that was primarily focused on solving problems like these, and I had at least one classmate that was discouraged because he felt not much progress was being made solving random problems. Well if you solve enough of these problems you soon seem to find out that a lot of them are very similar. A lot of them fit into just a few relatively small categories. That’s why it may be easier to see the categories as well as solve random problems. That way you can be picky about which problems you solve and choose to strengthen your skills on problems you have less experience with (another principle I learned from a music teacher).
There is one book that does this really well. It is “The Competitive Programmer’s Handbook” [0]. The only gripe I have with this book is I wish it had example problems to go along with the theoretical aspect of each of the categories. Also I would recommend the "Cracking the Coding Interview" HackerRank challenges [1] which are written and compiled by Gayle Laakmann McDowell (who is the author of the book with the same title as the course.) I recommend watching the videos that go along with each section.
Also just a tip for interviews it’s very good to think out loud and converse with your interviewer. Also remember they are not just testing your ability to answer problems, but also testing how well you would fit within their existing teams (personality wise and such), and they’re testing how you cope with failure. So try and destress before an interview, and try being humble and kind (in my opinion that’s a good thing for teams of software developers to do).
Hopefully you find this helpful, and take this as you will. You honestly have the best knowledge of where you are at in handling this.
Also, advice that my Dad (a professor in Information Systems) always gave me is that it's more important to get your foot in the door and just get a decent software developer role than go for a job with a high salary or terrific benefits.
He then told a story of one of his biology students. He said that one of his students came to him after failing a test, and said he studied for many hours before the test and was asking for his score to be improved. My drum line coach then said he told the student that he wouldn’t raise the grade, but instead in my own opinion decided to teach him a valuable life lesson. He said to the student you need to be studying smart and not hard. He then told our drum line that we need to do the same with our practices.
I bring up this story not to say you’re not working hard. I believe you have met that criteria. Maybe though you are not doing things as efficiently as you would be able to if you had the right resources.
Also, with all that said in my opinion a lot of day to day software engineering is different than competitive programming like interview questions. I wouldn’t be too stressed not being good at the interview questions, because it’s so different. I also wouldn't be stressed that you don't enjoy it. Although since it’s a good idea to have a job you may need to meet these somewhat odd demands of getting a software job.
I took a class that was primarily focused on solving problems like these, and I had at least one classmate that was discouraged because he felt not much progress was being made solving random problems. Well if you solve enough of these problems you soon seem to find out that a lot of them are very similar. A lot of them fit into just a few relatively small categories. That’s why it may be easier to see the categories as well as solve random problems. That way you can be picky about which problems you solve and choose to strengthen your skills on problems you have less experience with (another principle I learned from a music teacher).
There is one book that does this really well. It is “The Competitive Programmer’s Handbook” [0]. The only gripe I have with this book is I wish it had example problems to go along with the theoretical aspect of each of the categories. Also I would recommend the "Cracking the Coding Interview" HackerRank challenges [1] which are written and compiled by Gayle Laakmann McDowell (who is the author of the book with the same title as the course.) I recommend watching the videos that go along with each section.
Also just a tip for interviews it’s very good to think out loud and converse with your interviewer. Also remember they are not just testing your ability to answer problems, but also testing how well you would fit within their existing teams (personality wise and such), and they’re testing how you cope with failure. So try and destress before an interview, and try being humble and kind (in my opinion that’s a good thing for teams of software developers to do).
Hopefully you find this helpful, and take this as you will. You honestly have the best knowledge of where you are at in handling this.
[0]: https://cses.fi/book/index.html
[1]: https://www.hackerrank.com/domains/tutorials/cracking-the-co...