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

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(n2) algorithms, if n is around 1000000 then it’s O(n) or O(nlog 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.