I'm interested in improving efficiently, and the main advice I see (on blogs, comments, CP Discord, etc.) is "solve more problems". For someone who's not solving any problems yet, this is great advice. Additional detail seems unhelpful because getting started is WAY more important than nitpicking and prematurely worrying about efficiency.

But how can someone who's already solving a lot of problems improve more efficiently?

I have a lot of unanswered questions about this:

How should we choose problem difficulties?

Someone who's already Expert probably won't get to the next level by solving 500 problems that are all Div2A. I often hear "solve problems that are slightly above your current level", and once again this is great advice. But it's important to sometimes mix in "easy" problems for practicing speed and staying motivated. How should we balance the two?

How should we choose problem topics?

I've heard arguments for choosing problems randomly, but it makes sense to sometimes choose specific topics to address weak points or review important concepts. When should we do one or the other?

How should we structure our training schedules?

My friend who does competitive gymnastics said that his training schedule goes "Hard, Hard, Easy" (two sessions of intense training followed by one session of lighter training, to help with recovery). How should competitive programmers structure their training schedules?

What should we do after getting AC?

One way is to just move on to the next problem. But Polya's book "How to Solve It" talks about four steps in problem solving: understand the problem, make a plan, carry out the plan, and look back. What are good ways to do "look back" so we can get the most out of each problem?

What other activities should we do?

Obviously, there's participating in contests. But besides that, is it helpful to read textbooks? Prove theorems? Watch streams? Play Zachtronics games? How helpful are these activities compared to only solving problems? How should we divide our time between these different activities?

I know there's no single answer to these questions that works for everybody in every situation, but I'm still interested in hearing your ideas.

There's a huge (might not fit in int32) difference between my performance on a good day and a bad day, and I bet I'm not alone on this. I think there are many factors beyond pure problem solving skill / algorithms knowledge that determine how well you do on contests.

Of course there's the basic things: for example, if someone is hungry or sleepy, they probably won't do as well.

But beyond the basics, I bet there are lots of interesting ideas to explore. Does anyone here have thoughts on this? For example,

• What are some non-technical factors that affect contest performance?
• How can we improve in those areas (besides just participating in more contests)?

I sometimes ask my friends, Would you rather be Red on Codeforces or have $$$10^6$$$ dollars? (Obviously, "Magic" doesn't count: you have to gain the skill level of Red as well.) They are usually able to answer instantly, but I won't say which answer they give :)

I'm curious how the Codeforces community feels about this topic. I know some things in life don't have monetary value, but I'd still like to get a rough estimate of how much competitive programming is worth to you.

So, I'd like to ask you the same question: Would you rather be Red or have $$$10^6$$$ dollars?

P.S. If you're already Red / Nutella, maybe you can answer instead: Would you trade all of your skill in competitive programming in exchange for $$$10^6$$$ dollars?

I don't think anybody likes getting WA. It's especially annoying when they're silly issues that are easy to prevent in the future, so I decided to keep start keeping track of things that have caused me to get WA. Here are a few:

• Not setting precision high enough when using cout to print floating point answers

  • The default precision is only 6 digits, and problems often ask for more precision than that, so I think it's a good idea to do cout << setprecision(12) whenever floating points are involved

• Using 1 << k instead of 1LL << k when the result won't fit in 32 bits

• Only considering one direction of an undirected graph when reading input

• Using the wrong priority queue ordering

  • Since C++ priority queues give you the max element by default, you need to initialize with priority_queue<T, vector<T>, greater<T>> if you want to get the min (e.g. in Dijkstra's algorithm)

• Using the wrong parameter (e.g. n instead of m) when reading input(!)

  • I'm not joking, this has caused me to pass pretests but fail system tests before :(

What about you, what are some of the (silly and easily preventable) causes of WA that you've encountered?