
Ask HN: How did you improve your problem-solving skills? - pps
I&#x27;m currently trying to get better at solving CS&#x2F;Math puzzles and I&#x27;d like to hear your story - what are you doing when you struggle with problems from Project Euler, HackerRank, LeetCode, etc? What kind of resources helped you? Did you read &quot;How to Solve It?&quot; by G. Polya? If so, do you think it&#x27;s useful for non-mathematicians? Thanks for any hints!
======
laurentl
For project Euler specifically:

\- look at the size of the inputs, it usually tells me what type of complexity
my solution should have: if n is around 1000 I’ll be looking at O(n __2)
algorithms, if n is around 1000000 then it’s O(n) or O(n _log n), if n is 10_
*12 you need O(log n) or O(sqrt n). Knowing the complexity class gives you
some idea of which algorithms to try or to discard. (And if you can get away
with letting your naive solution run for a few hours to get the answer)

\- figure out an inefficient solution that works for small inputs, then run it
for a range of inputs and try to pick up a pattern (this is usually a last-
ditch effort though).

\- leave the problem alone for a while if I’m stuck on it for too long. This
is usually a sign that I’ve taken the wrong approach; looking at the problem
with fresh eyes will sometimes reveal a new way to attack it.

\- read the PE forums for solved problems. These are a goldmine for
mathematical analyses, code snippets, etc. Not to mention that some hard
problems are related to earlier, easier problems and trawling the easier
problems’ forums can land you the solution to the harder ones.

\- try to frame the problem in a different way. Some PE problems are well-
known math or CS problems in new clothes. For me this involves a lot of
formula writing: I frame the problem in a mathematical manner and try to
rearrange the terms into another formulation of the problem. Also lots of
googling and reading Wikipedia articles about mathematical branches and
theorems. Even if it doesn’t help for the problem at hand, it might help on a
problem further down the line.

------
csnewb
The books that I've read that have helped me immensely: How To Solve It,
Problem Solving 101, 5 Elements of Effective Thinking, and Peak: Secrets from
the New Science of Expertise. Trying to improve my problem solving ability in
coding forced me to look inwards and analyze my thought process to understand
why I'm able to solve some problems and unable to solve others. Ultimately
I've realized the root cause of my inability to solve hard problems was poor
problem decomposition. Every hard problem can be broken down into subproblems,
and those can be further broken down until they become easy enough to solve.
Then you just connect all the pieces together. It takes a lot of deliberate
practice with many problem types to be able to recognize how to decompose
problems, however.

------
arcticwombat
* Solve problems

* Afterward, reflect on what went well and what didn't

* Write down what you should have done differently

* Solve more problems, keep those notes handy

* Repeat

Sorry, not based on CS/Math puzzles, but real-world software development and
problem solving.

------
Cypher
General problem solving skills will help. One exercise is to pick a product
everyone uses, say a washing machine and then you work backwards, imagining
how they ever got to that stage. The type of iterations they had and then what
the limitations of it were which caused them to make a new model.

------
DoreenMichele
I will recommend the book "How to lie with statistics." Problem solving starts
with understanding what's important. This book goes into the ways that people
routinely use numbers to mislead, whether intentionally or not, and how to
suss out what actually matters.

------
TheAlchemist
TopCoder used to be a great place for this. After every 'match' there were
write-ups and discussion on how to solve the problem in different ways etc. I
learned a ton from there !

Also, as other said - there is no easy way around it - it's hard work (but
still fun) and you have to take the hard road - working on the problem until
you solve it (or your pre-defined time runs out) then reflecting on what was
good / bad in your thinking process.

