03 — Reading Editorials Correctly

There is no shame in reading an editorial. The only shameful outcome is re-reading the same editorial for the same pattern type six months later and learning nothing from it. Reading an editorial is a skill. Most people skip it entirely or consume it passively — both are waste. Done correctly, editorial reading is one of the highest-leverage learning activities in competitive programming.

The Core Principle

An editorial does not teach you to solve problems. You teach yourself — the editorial is just structured feedback on where your thinking broke down. That distinction matters because it changes how you use editorials: not as answers to consume, but as X-rays of your own blind spots.

The goal every time you read an editorial: leave with a new trigger. Not “oh now I know the algorithm” — that’s fragile. The durable outcome is: “now I know what signal in a problem should make me reach for this technique.”

The Correct Protocol

This protocol sounds slower. It is not. It produces learning that sticks instead of learning that evaporates.

Step 1: Attempt (30–45 minutes)

Work the problem without help. If you get it: great, skip to Step 6. If not, don’t just spin — document what you tried and why it didn’t work. “Tried DP on subarrays, ran into overlapping state issue” is more useful than a pile of commented-out code.

Step 2: Read Only the First Hint

Most quality editorials (Codeforces editorial comments, USACO, AtCoder) have tiered hints or at least a first-paragraph approach description. Read only the first structural hint, not the full solution.

  • “The key insight is that you should sort by X.” — stop there. Try again.

  • “Model this as a graph problem.” — stop there. What kind of graph? Try again.

Step 3: Attempt Again (15 minutes)

Take the hint and push. You’ll either crack it or narrow down the exact sub-problem you’re missing. Both outcomes are valuable.

Step 4: Read the Approach (Not the Code)

If you’re still stuck, read the editorial’s explanation of the approach — the algorithmic idea — without looking at the implementation. This should tell you WHAT to do, not HOW to code it. Now implement it yourself.

Step 5: Implement Yourself

This is the non-negotiable step. Do not copy the editorial’s code. Type your own implementation from the idea. Even if it looks nearly identical to the editorial, the act of writing it yourself builds the muscle memory and forces you to understand each line.

If you copy code, you’ve consumed a solution. If you implement it, you’ve solved a problem.

Step 6: Compare Your Code to the Editorial

After you’ve implemented and verified, now read the editorial code. Look for:

  • Did they handle an edge case you missed?

  • Is their implementation cleaner? Why?

  • Is there a data structure choice you didn’t think of?

This comparison phase is where you upgrade your implementation idioms, not where you learn the algorithm.

Step 7: Write the Pattern Note

Open your lab notebook and write exactly one paragraph with this template:

“This was [PATTERN]. I missed it because [REASON]. The trigger I should have caught was [SIGNAL]. Next time I’ll recognize it when I see [OBSERVATION].”

Example:

“This was interval DP. I missed it because I was trying to build the solution left-to-right and couldn’t find the recurrence. The trigger I should have caught was ‘cost depends on the order in which you merge elements’ — that’s the interval DP shape. Next time I’ll recognize it when the problem involves merging or splitting ranges where cost depends on the range boundaries.”

This paragraph is the actual deliverable of your editorial session. The code is a byproduct.

What Makes a Good Editorial Source

Not all editorials are written for you. Some are written by red-rated competitors for other red-rated competitors, and reading them at your level is like reading a differential geometry textbook to learn calculus. Rate your sources.

Source

Strength

Weakness

Best For

Codeforces editorial comments

Written by problem setters, authoritative

Often terse, assumes background

CF problems specifically

NeetCode (YouTube + site)

Extremely clear explanations, code walkthrough

LeetCode only, sometimes hand-holdy

LeetCode mediums/hards

CP-Algorithms (cp-algorithms.com)

Deep theory, multiple approaches

Reference-style, not problem-specific

Understanding algorithm families

USACO Guide (usaco.guide)

Structured by difficulty, problems linked

USACO-centric, not always generalizable

Building foundational patterns

Algorithms for CP (cpalgorithms.com)

Same as cp-algorithms.com

Same

Theory deep dives

AtCoder editorials

Mathematically rigorous, clean

Japanese-translated, sometimes cryptic

AtCoder problems, math-heavy problems

Codeforces blog posts (high-rated)

Deep insight, community-vetted

Inconsistent quality

When you need the definitive explanation

Flag bad editorials. If you spend 20 minutes reading an editorial and understand less than when you started, it’s not a you-problem — it’s a source-quality problem. Move on. Find a different explanation of the same technique. YouTube searches for the problem number (“1766C explanation”) often surface cleaner content than the official editorial.

The “Read Too Early” Failure Mode

The most common editorial mistake is not reading incorrectly — it’s reading too early. If you read the editorial after 10 minutes of struggling, you’ve learned approximately nothing. You haven’t developed enough of a hypothesis to make the editorial’s explanation meaningful. It becomes trivia you’ll forget in a week.

The 30-45 minute threshold is not arbitrary. Research on problem solving suggests that the formation of a wrong model, followed by its correction, produces stronger retention than correct information delivered cold. You need to be wrong first. The editorial fixes the wrong model. That’s the learning.

What to do when you’ve been stuck for 30 minutes but haven’t actually tried anything concrete: that’s a different problem — engagement deficit. Force yourself to commit to an approach even if you think it’s wrong. Try it. Fail concretely. Then read the hint.

What Most People Get Wrong

Most people use editorials as answer keys. They get stuck, immediately open the editorial, read the code, copy-paste it, get an AC, and feel good. They’ve learned nothing.

The second failure mode: reading the full editorial on the first read, including the code, before attempting anything. Now the problem is ruined — your brain can’t unsee the solution. You’ve consumed an answer instead of earning an insight.

The third failure mode: reading the editorial and understanding it intellectually without writing the pattern note. Understanding without articulation decays within days. The paragraph you write is what sticks.

The correct emotion after reading an editorial should be mild annoyance — “I almost had that” or “ah, that’s the trick I was missing.” If you feel nothing, you read it too early. If you feel completely lost even after reading it, the problem is too far above your current level — move to a lower-rated version first.

Building the Upsolver Habit Around Editorials

The editorial-reading protocol pairs with the upsolver habit from 01_contest_strategy.md. After every contest:

  1. For problems you didn’t solve: apply the full 7-step protocol above.

  2. For problems you solved but slowly: read the editorial anyway — compare your approach, look for the cleaner path.

  3. For problems you solved cleanly and quickly: optionally skim the editorial for alternative approaches. 5 minutes max.

The 24-hour window after a contest is the highest-value learning window. The problems are fresh, your failure is specific, and your motivation is activated. Use it.