I know that by such things people may mean magic pills or universal algorithms that solve all problems but I look for something real like what first do you think when seeing probabilities, where should we be careful in, say, CHT implementation or what are your first steps while constructing greedy, etc. I kinda want to make a list of suggestions and share it with CP amateurs like me.

** Cyan says some short ideas
** MetB : would it help ?

:'D

(TL;DR at the end if you're lazy)

It is well-known that, in order to master something, you have to be able to teach it. I think it applies to solved problems too.

When you solve an hard, interesting, many-steps problem (not a random cancer CF problem), try to write a complete document about it (few pages), where you will explain all the thinking process that leads to the solution.

IOI-style problems may be good candidates for that, because the subtasks format will naturally divide your solution into several thinking steps.

Everything should be clear in this document, and the path leading to the solution has to be natural (unlike most editorials which don't explain how to come up with the solution). You may have to make your solution as simple (and elegant) as possible before writing.

While explaining the solution to the specific problem, don't forget that the document also has to give general problemsolving adivces (related to the problem, of course) :

• When you use some sort of technique/trick/observations, try to write an aside about it (why we should think about it in this case, in what other cases is it useful, try to find corollaries and generalisations).

• When you're doing greedy things, don't write a formal and obscure proof, instead write an intuitive justification (it may be harder to find).

• When there is a potential wrong solution that looks attractive, explain why it's false, and how we can find a simple counterexample (e.g. testing resistance to "noise")

• etc...

In the last part of this document, summarize all useful tricks or "method points" you learned while solving this problem.

This "teaching part" is in my opinion the only way to really fix in your brain all the nice things the problem made you discover. Unless you did it, I don't think you can consider that you completly solved the problem.

TL;DR Solve hard and interesting problem, and write a complete document explaining a natural thinking path that leads to the solution (how to come up with it), with asides about techniques or method points used.

try to approach the problem by your own.

Well I have a question in which I hope other's can give me advice on.

When upsolving, is it very important that one always implements the solution, or sometimes should I just "theory solve" the qn, and skip the implementation to instead focus on having more exposure on other questions? Thank you!! :)

Well, as one wise man once said, just solve more problems.

One CM to another CM: Never ask Red coders...

I think the most important thing I learnt is that it's always optimal to think carefully and understand a solution completely (maybe on paper) before implementing it.

First of all, in team contests it obviously saves computer time. If you have 15 hours of human time and 5 hours of computer time, it's usually better to optimize computer time which can be spent on implementing and debugging and so on. It's dangerous when the guy who took the computer tries to finish his solution and the computer is not actually involved.

Moreover, I noticed that when I participate in an individual contest, it's still better to think of all details of a solution before starting it. I don't always manage to take everything into account, but the strategy "I start it now, write everything that is definitely needed and then just deal with the rest somehow" usually leads to nothing good, no matter how tempting it seems. I noticed that with the right strategy I have to debug much less my solutions than earlier.