Is this greedy or DP?

You read a problem, glance at the constraints, and your brain immediately blurts out a label: n is two thousand so it must be some O(n squared) DP, or this one feels greedy, or there is a segment tree hiding in here somewhere. Then you spend the next forty minutes trying to force the problem into whatever method you guessed, and this is one of the most reliable ways that otherwise capable people throw away an entire contest. The label came from the surface of the problem rather than from anything you actually understood about it, and a guess made from the surface is wrong often enough that building your whole approach on it is a bad bet.

The failures it produces are predictable. You get greedy solutions that pass the samples and then die on a case you never thought to check, because you committed to greedy before you had any real reason to believe a greedy choice was safe. You get dynamic programming with a state so contorted that it could only have come from someone working backwards from the assumption that it had to be DP. You get segment trees and other heavy machinery dragged in to do a job that one clean observation would have done in two lines. Two specific beliefs cause most of this, and both are wrong: that "not greedy" implies "DP," when ruling one out actually tells you almost nothing about the other, and that "the obvious greedy failed" means greedy is dead, when usually it just means the obvious greedy was wrong and a correct one is sitting one observation deeper.

The way out is to flip the order and refuse to name the method until you have earned the right to. Start by forgetting the label entirely and making observations about the problem instead: what an optimal answer is forced to look like, what you can swap or reorder without making things worse, what stays fixed no matter what you do. Prove small facts. Simplify the problem until it becomes tractable, by solving a smaller version, dropping a dimension, or removing a constraint and seeing what is left. Then rephrase what remains into something concrete and algorithmic, like maximizing a quantity over a set of choices or finding a shortest path on a graph you have just uncovered. By the time you have done that work the method is usually obvious, and it might well turn out to be DP or greedy or a stack or a DSU, but the difference is that the tool fell out of the structure you found instead of being stapled onto the surface you guessed at. It is the same code in the end and a completely different process, and only the second process holds up on a problem you have never seen before.

This is the same idea as metacognition over pattern recognition, applied to the exact moment you reach for an algorithm. The blog this draws from is worth reading in full.