4 ms·

How do I force myself to find doing those problems to be fun? To me they just seem painful because they really expose how stupid I am even if I know he basics.

hzay 8y ago
It's okay if you don't find these problems to be fun. Some people like crossword puzzles, some don't. If you can't solve a problem, it doesn't say anything about you, except that you haven't yet practiced using that particular algorithm/technique enough. It most definitely does not say that you are stupid, although some ppl would have you believe that. I'd recommend that you only solve problems that are extremely easy, on websites like https://www.spoj.com https://www.spoj.com or https://www.topcoder.com https://www.topcoder.com or old google code jam questions. Pick a single website (I recommend codejam) and do only the easy ones for a few months. It's hard to argue against the happiness that comes when your program passes the tests. The point is not to sharpen your skill but to get used to the feeling that your program passes ALL the tests cases. If you get to a stage where you're completely sick and bored of easy problems, pick a slightly more difficult problem with basic algorithms like plain BFS or DFS. Try it for just a day or two and when you can't solve it, read the published solution. Try to understand it, apply it manually to the test cases and once you're sure that you've completely grasped the solution, implement it and see if it passes all the tests cases. Take it slowly, and return to easy problems often. This could take you pretty far in terms of enjoying the process. :) At least that's how it worked with me -- I liked the high of getting a program "accepted".
jsolson 8y ago
Start simple: find a list (with answers). Don't try to "solve" them, just read the questions and try within a minute or so to name a data structure or algorithm -- something you'd expect most undergraduate intro classes to cover -- that seems likely to be part of the solution. Check your work, keep track of which ones you got right/wrong, and move onto the next question. Re-visit the ones you got wrong first. Try them again, repeat until you've gotten them all right (this might just be because you remember the solution from looking it up, that's fine, you'll have plenty of time to forget by the time we get back to it :). Now, revisit the ones where you had the right data structure on the first go. HOW would that data structure help? Go a level deeper on actually trying to solve it. I can't guarantee this will be fun, but it should be fast. A few minutes here on there on any given problem, going one level deeper each time you visit it. Eventually you'll have the whole algorithm for one of the problems, likely using some common data structure like a hash map, tree, or heap. Code it in a language with a good set of algorithmic primitives, use every tool the library gives you (don't worry about remembering how the data structures work on this pass). Hopefully with the whole algorithm in mind and all of the tools at your disposal, this is "just plumbing". Rinse, repeat. Somewhere in there, do the same with the complexity analysis (time and space!). Next time, try it where you have to build the data structure by hand. Then one day you'll see a problem not on your original list, and you'll immediately think "red-black tree with a hash table lookaside buffer, but I wouldn't want to have to build the RB tree by hand if they asked me to, so AVL tree because the complexity is the same and I can bang out the code like it's what I do every morning before breakfast". Like I said, it might not be fun (at least at first), but it is a way to break up the practice into digestible chunks. Also it builds on the strategy that I've seen work best in interviews -- if you treat each step of iterative deepening of the solution as a point where you'd talk with the interviewer about what you're thinking and why, you give them a lot to go on about your thought process and a chance to course correct if you misunderstood the question or your heuristic for how to approach it simply came up wrong.
- shreyanshd 8y ago
  For someone who is preparing for interviews, this is really good advice. Thank you.
kjeetgill 8y ago
It might be more fun if the problems are a bit more game like. I got my start with Euler Project which I was doing for fun looooong before I even thought about interviews. There's lots of other resources out like that now I think. I've heard people mention hacker rank.
franzwong 8y ago
I have the same problem. I can't say my approach works or not because I am still trying. My approach is to keep writing the basic algorithm, data structure, common questions again and again. Do it once every 2-3 weeks. When I know every part of them, then I can start twisting or go deeper. I am not that top talent. Sometimes even a 0-based or 1-based array can bug me a while.

hzay 8y ago

It's okay if you don't find these problems to be fun. Some people like crossword puzzles, some don't. If you can't solve a problem, it doesn't say anything about you, except that you haven't yet practiced using that particular algorithm/technique enough. It most definitely does not say that you are stupid, although some ppl would have you believe that. I'd recommend that you only solve problems that are extremely easy, on websites like https://www.spoj.com https://www.spoj.com or https://www.topcoder.com https://www.topcoder.com or old google code jam questions. Pick a single website (I recommend codejam) and do only the easy ones for a few months. It's hard to argue against the happiness that comes when your program passes the tests. The point is not to sharpen your skill but to get used to the feeling that your program passes ALL the tests cases. If you get to a stage where you're completely sick and bored of easy problems, pick a slightly more difficult problem with basic algorithms like plain BFS or DFS. Try it for just a day or two and when you can't solve it, read the published solution. Try to understand it, apply it manually to the test cases and once you're sure that you've completely grasped the solution, implement it and see if it passes all the tests cases. Take it slowly, and return to easy problems often. This could take you pretty far in terms of enjoying the process. :) At least that's how it worked with me -- I liked the high of getting a program "accepted".

jsolson 8y ago

Start simple: find a list (with answers). Don't try to "solve" them, just read the questions and try within a minute or so to name a data structure or algorithm -- something you'd expect most undergraduate intro classes to cover -- that seems likely to be part of the solution. Check your work, keep track of which ones you got right/wrong, and move onto the next question. Re-visit the ones you got wrong first. Try them again, repeat until you've gotten them all right (this might just be because you remember the solution from looking it up, that's fine, you'll have plenty of time to forget by the time we get back to it :). Now, revisit the ones where you had the right data structure on the first go. HOW would that data structure help? Go a level deeper on actually trying to solve it. I can't guarantee this will be fun, but it should be fast. A few minutes here on there on any given problem, going one level deeper each time you visit it. Eventually you'll have the whole algorithm for one of the problems, likely using some common data structure like a hash map, tree, or heap. Code it in a language with a good set of algorithmic primitives, use every tool the library gives you (don't worry about remembering how the data structures work on this pass). Hopefully with the whole algorithm in mind and all of the tools at your disposal, this is "just plumbing". Rinse, repeat. Somewhere in there, do the same with the complexity analysis (time and space!). Next time, try it where you have to build the data structure by hand. Then one day you'll see a problem not on your original list, and you'll immediately think "red-black tree with a hash table lookaside buffer, but I wouldn't want to have to build the RB tree by hand if they asked me to, so AVL tree because the complexity is the same and I can bang out the code like it's what I do every morning before breakfast". Like I said, it might not be fun (at least at first), but it is a way to break up the practice into digestible chunks. Also it builds on the strategy that I've seen work best in interviews -- if you treat each step of iterative deepening of the solution as a point where you'd talk with the interviewer about what you're thinking and why, you give them a lot to go on about your thought process and a chance to course correct if you misunderstood the question or your heuristic for how to approach it simply came up wrong.

shreyanshd 8y ago
For someone who is preparing for interviews, this is really good advice. Thank you.

kjeetgill 8y ago

It might be more fun if the problems are a bit more game like. I got my start with Euler Project which I was doing for fun looooong before I even thought about interviews. There's lots of other resources out like that now I think. I've heard people mention hacker rank.

franzwong 8y ago

I have the same problem. I can't say my approach works or not because I am still trying. My approach is to keep writing the basic algorithm, data structure, common questions again and again. Do it once every 2-3 weeks. When I know every part of them, then I can start twisting or go deeper. I am not that top talent. Sometimes even a 0-based or 1-based array can bug me a while.