Project Euler's problems are nice, but they get hard fast. It's nice to apply and practice some theoretical knowledge this way, but no way to acquire that knowledge in the first place.
I like that the Project Euler problems get hard fast, it's a great opportunity to fail over and over again, which (at least for me) forces you to think more deeply about the problems, when something is too easy you can fall into the trap of a "good enough" solution, which is often appropriate in the day job, but not necessarily so when you are trying to practice. I love the code golf option on 4clojure for that also, because for so many of the problems I just can't see how people get the smallest solutions - not that I would want to write code like that for a shipping product.
Project Euler is fun and all that. But no real way to learn about all those techniques you need in the first place. A particularly hard problem might set you off learning about stuff in that direction. I'm still working on a way to generalize my dynamic programming knowledge enough to solve problem 256 at the moment. Problem 202 was fun, when you realized what the problem was really about.
