http://oi-wiki.com/contest/problemsetting/

(in chinese)

I like problems that make me go WOAH after I realize the solution

Having something exciting story or problem statement indicates a good problem. Seeing some problem statements is long and tedious! It will be a good problem if an author maintains the main goal by converting an interesting story.

[self-opinion:)]

I think first 3 problems of global round were normal just like any other round felt like they could swap A and B but it wasn't necessary anyways.

I think these stupid people just got negative delta and started spitting on the official blog. C wasn't hard everyone knew it's dp so where's the problem.

I can't say about other problems because i wasn't able to solve them but many of those who are spitting on that blog could not even solve 2-3 problems.

The only problem is in past rounds is weak pretest and i think testers are responsible for it. Umnik's comment was like a support to these idiots. I know he was just being honest that the round was an average round not like a good global round but still these newbie pupil better go to solve some problems rather than saying that the round was bad.

Edit :-

I like those problems in which these newbie and pupils attempts but struggles to pass

Good problem:

Balanced between analysis and implementation. It is not fun when you need a lot of analysis just to write a single line of code. Just like it is not very fun when the solution is obvious and requires and only a careful implementation from the beginning.

Easy to understand. Sometimes I feel i need to keep overwhelming amount of info in head just to understand what I'm asked

Also I prefer problems to be solvable with some algo/ds rather absolutely adhoc. I kind of understand why most problems on low levels are not like that but it does not change my preference

Speaking of mathematical equation, The problem with such problems is that most programmers don't have a good mathematical background.

That said it is possible to make a bad round even with good problems.

• Having a short clear statement with no useless stories which no one cares about

• Having pretests covering at least obvious mistakes (last edu problem B for example had "non negative" written in bold and had no tests covering this lol).

• Not being a cancer problem, this includes having trash or unnecessary case handling (that’s the case with last global round i guess, problems B and C had negatives only to annoy people and make them get WA), heavy implementation (most of us know how to implement but such problems result into unnecessary WAs due to small implementation details apart from them being very toxic).

• Not being standard (people who know the trick/topic can get it AC with < 1 min thinking, imo these problems should exist in educational rounds only).

• Solving the problem is fun, you get an observation which leads into another subproblem with new observations leading into other subproblems till you get the full solution.

Though if I abstract away my personal preferences, objective reality and specifics of this particular platform

Good problem probably means just two things

1) Easy to understand
2) Not well-known, requires thinking

I think there are various ways to say a problem is a good one.

• Need brilliant idea (cool ad-hoc)
• Hard but not need knowledge of too complex algorithm
• Step-by-step thinking leads to the solution (in this case, good practice pays you)
• Though the problem statement is simple, the solution is beautiful
• It's hard at a glance but actually solvable, sometimes in a simple way
• Typical but good for practice problems (for Div3,Div4,Educational,ABC...)

Short statement and a neat solution.

Priorities for a problem to be a good problem (sorted ascendingly) :

• Has a clear statement, stories/legends should be marked with a different font like the Italic one.

• Not a completely standard problem (It may contain a mixture of standard problems as subproblems, or having an ad-hoc part, which is even better).

• Has strong pretests (Even though that's irrelevant to the idea of the problem itself, but i am talking about the whole project/problem).

• Not Plagiarized.

• Not constructive, unless the answer can be achieved or proved step-by-step, and not just guessing or knowing the pattern before.

• Not an A, B, C in a global round.

• Having an Enderman statement.

Let put some educational problem aside, I think a good problem should have

1. clean statement that is easy to understand

2. original/interesting observation or idea

3. reasonable amount of implementation respect to the difficulty of observation/idea

4. the problem should be "a problem" rather than some combination of two or more unrelated part

   (this problem is a bad example, whose solution is just doing Dijkstra then use the result of Dijkstra to do some partial ordering without caring any special property come from the result of Dijkstra)

Div 3 rounds is the best ,I really benefit from it specially its graph and dp problmes and most of its problems about algorithms and data structure.
Unlike codeforces div 2 rounds nowadays which became bad and waste of time in unnecessary ideas .

It depends on the context. A good IOI problem is different from a good ICPC problem, which is different from a good Codeforces problem.

Codeforces has a short contest format; you have 5-6 problems to be solved in only 2 to 2.5 hours total.

So I think a good CF problem has one or two crucial magic insights, where if you notice in then everything falls neatly into place. Ideally, the insight is ad hoc, and doesn't rely too much on advanced prerequisite knowledge.

Math insights are okay as long as they don't make up the bulk of the task, i.e. there is still something "programmatic" about the problem. If the entire logic can be described and theoretically executed on pen and paper, and the program is just an implementation of this idea, then maybe it would have been more suitable for a math contest. Again, math-heavy problems are totally fine as long as having a computer is actually a crucial and not-incidental part of the task.

I normally champion implementation-heavy problems, but I think short contests are a bad place for it. It's just really stressful, especially to debug.