Find the step where attempts break
Every attempt goes through the same steps: understand the statement, find a slow method, find the fast idea, show why it works, write the code. People who stall usually fail at the same step over and over.
Take your last ten problems that failed or needed a hint, and name the step where each one broke.
Statement: you misread the output or missed a constraint.
Model: you couldn’t say what to store or what a state meant.
Idea: you had a brute force and no way to speed it up.
Proof: your greedy or DP looked right and failed on a case you never tried.
Code: the idea was right and the implementation wasn’t.
Replay one failed attempt
Pick one failed attempt and replay it from the statement, without the editorial open. Write down the first decision you couldn’t justify at the time. “I sorted because it looked like a greedy problem” is useful. “I didn’t get it” tells you nothing.
Then find an input that breaks your original idea. If you used two pointers, try an array with negative numbers. A specific counterexample tells you which assumption you were missing, and you’ll remember a counterexample long after you’ve forgotten the editorial’s wording.
Be honest about the help you used. “Read the prefix-sum hint, wrote the map myself” and “copied the editorial” are different results. Count only the first one as a solve.
Train the broken step on its own
Use problems easier than your usual ones. If proofs break, take problems you’ve already solved and write the argument for why the method works before looking at your code. If ideas break, work through one topic and stop each attempt once you’ve found the fast method, without coding it.
If code breaks, go the other way: easy problems written quickly, each one checked against a brute force. Ten minutes a day of that fixes off-by-one habits sooner than another hard problem would.
Arise sets are grouped by topic and rating. Open the topic where your labels pile up and work through the rows below your usual rating.
Check that the repair stuck
Come back to the original problem a week later and explain the method out loud before you code it. If you only recognize the solution when you see the code, it didn’t stick yet.
Then try a variation that changes one condition: allow negative values, ask for the count instead of the maximum, add a second kind of query. Solving the variation means you understood why the method works, which is the part that carries over to new problems.
Recount your labels after a month. If the same step still covers half the list, the repair problems were too hard or you didn’t do enough of them.