Reflections -- On Getting Stuck, Getting Better, and Getting Honest

This file is different from the others. There is no code here, no cheat sheet, no practice problem table. Just honest observations about the things that actually hold people back — the ones that do not appear in any algorithm textbook.

Quick Revisit
Replay-style file: thought-process walkthroughs and meta-learning, not technique reference.
Core observation: under pressure, recognition fails where recall succeeds. The fix is implementation practice, not more reading.
Sections you will revisit most often: the internal monologue (what real problem-solving feels like), the plateau diagnostic (what to fix at each rating band), and the upsolve loop.
Prerequisite: at least ~10 rated contests, otherwise the diagnostics will not map to your experience.

1. The Real Reason You're Stuck
2. The Internal Monologue of Solving a Problem
3. What to Do When You're Completely Blank
4. The Geometry of Progress
5. What Upsolving Actually Means
6. The Trap of Knowing Too Much Too Shallowly
7. The Comparison Trap
8. What Reading Editorials Is Actually Teaching You
9. The Practice Problem You Should Never Skip
10. A Note on Slow Progress
Quick Reference: Common Mental Traps
What the Code Won't Teach You
Self-Test

1. The Real Reason You're Stuck

When you plateau -- when your rating stops moving for weeks -- the instinct is to read more algorithms. Study harder. Learn something more advanced.

Usually, that's the wrong diagnosis.

At most rating levels, the bottleneck is not what you know. It's one of these:

You recognize the technique but can't deploy it. You see "segment tree" in the tags and think "yes, I know that." But when you sit down to implement it from scratch under time pressure, you're slow, you make mistakes, you stall. Knowing what an algorithm is and being able to use it are different skills. The gap between them closes only through deliberate implementation practice -- writing it from memory, not reading it.

You can't see the problem underneath the words. The problem says something about villagers and bridges and coins. You read it three times. You still don't know what it's asking in mathematical terms. This is the problem-modeling gap: the ability to strip away the story and see the abstract structure. A shortest-path problem dressed in a narrative is still a shortest-path problem. The skill of undressing it takes practice that feels uncomfortable because it's not algorithmic -- it's linguistic and structural.

You apply algorithms by template, not by understanding. You memorized the segment tree code. When a problem needs a segment tree, you paste it in. This works until the problem needs a slight variation -- a different merge function, a non-standard lazy update, a composition of two techniques -- and the template breaks. Real fluency means understanding the why deeply enough to adapt on the fly.

You're avoiding your weak spots. There's a category of problem you consistently lose to. Maybe it's combinatorics. Maybe it's constructive problems. Maybe it's greedy proofs. The comfortable move is to grind more easy problems in topics you're already good at. The uncomfortable move -- the one that actually raises your rating -- is to sit with your weak spots until they stop being weak.

2. The Internal Monologue of Solving a Problem You've Never Seen

The arc below follows the universal replay pattern: first instinct, wrong paths, reframing moment, and the transfer lesson. This is what real problem-solving looks like.

This is what you don't see in editorials. Editorials show the clean path from problem to solution, as if the author walked directly there. They never show the wrong turns, the abandoned approaches, the fifteen minutes of thinking that looked like nothing happening.

Here is what actually happens when an experienced competitor opens an unfamiliar problem:

 Open the problem. Read constraints first. n <= 2*10^5. So O(n log n).

 Read the statement.

 What is it REALLY asking? Strip the story.
 "Given array A, for each query (l, r, k), find..."
 Okay. Range query. Maybe offline?

 What's special about this problem? What's the twist?
 The twist is the k parameter. That's not standard.

 Can I do it naively? n queries, each O(n). That's O(n^2). Too slow.
 But maybe the brute-force gives me insight.

 [writes 15 lines of brute force]

 Runs on sample. Correct.

 Now: what's the brute-force doing that's redundant?
 It's recomputing the same ranges over and over.
 Can I precompute? What would I precompute?

 [5 minutes of thinking, nothing obvious]

 Different angle: Can I sort the queries?
 If I sort by k, does something simplify?

 [thinks about it]

 Yes -- sorted by k, I'm sliding a window of size k across...
 wait, that's not quite right either. What if...

 [another wrong idea]

 Okay. Take a step back. What am I actually counting?
 The answer is the COUNT of something in a range.
 Range + count = BIT or segment tree.
 But what am I putting in the BIT?

 [the key insight arrives]

 Oh. If I think of it this way...

None of that is wasted time. All of it is the process. The wrong attempts are how your brain builds the map of why the right answer works. If you skip to the editorial the moment you're stuck, you skip the map-building.

The shape of the monologue varies by problem type. A short tour of the entry points and the moments where progress unlocks:

Implementation problem. "Constraints are loose. There's no clever trick — just careful coding." The unlock is reading the statement exactly, in particular the output format. The trap is over-engineering when a careful linear pass would suffice.
DP modeling problem. "What information do I need at step $i$ to make optimal future decisions?" The unlock is the state definition, not the recurrence. If two different inputs that should differ collapse to the same state, the state is missing a dimension.
Greedy proof problem. "I see a greedy that might work. Can I exchange any non-greedy choice for a greedy one without making the answer worse?" The unlock is the exchange argument; the trap is shipping a hunch.
Graph reduction problem. "This story is about villagers and bridges. What is the underlying object — a tree, a DAG, a flow network, a 2-SAT instance?" The unlock is the reduction; the trap is trying to invent algorithms on the disguised version of the problem.
Constructive problem. "What does a valid output look like? Can I describe a recipe that always produces one?" The unlock is the structural invariant of the output, not a search procedure.

Different problem types feel different in your head, but the meta-structure is the same: read carefully, identify the special property, decide what shape the answer takes, and only then pick the technique.

The discipline is staying in the discomfort. Twenty minutes of genuine confusion is worth more than twenty minutes of reading a solution. The confusion is the learning -- it's your brain actively searching, forming hypotheses, testing them. That searching is a skill. It gets faster with practice.

3. What to Do When You're Completely Blank

There's a specific kind of stuck that feels different from "I know how to approach this but I'm struggling with the details." It's the moment you read a problem, understand every word, and have absolutely no idea where to begin. No candidate technique. No toe-hold.

This is normal. It happens to everyone. Here's the protocol:

Step 1: Go back to constraints.

 n <= 20? -> Enumerate subsets. Bitmask DP. Meet in the middle.
 n <= 500? -> O(n^3) is fine. Interval DP. Floyd. Gaussian.
 n <= 5000? -> O(n^2). Brute force with early exit. 2D DP.
 n <= 2*10^5? -> O(n log n). Sorting + binary search. Segment tree. BFS/DFS.
 Queries? -> Offline? Mo's? Persistent structure?
 Values <= 10^9? -> Usually coordinate compress them. They're just labels.

Constraints are not just a TLE limit. They're a message from the problem setter: "here is the complexity class I expect." Read them as a hint.

Step 2: Generate brute force. Seriously.

Even if the brute force is $O (n^{3})$ and the constraint is $n = 10^{5}$ , write it. Writing the brute force forces you to understand the problem. Often, in the act of writing it, you'll see the structure you need to exploit. The brute force is not wasted code -- it becomes your stress-test oracle and your thinking scaffold.

Step 3: Ask what's special about this problem.

What makes this problem different from a generic optimization or counting problem? Usually there's one structural property that the solution exploits. What invariant does the input satisfy? What geometric property? What number-theoretic constraint? That special property is the key. Find it and you've found the problem.

Step 4: Classify the answer, not the approach.

Instead of asking "what algorithm should I use?" ask "what is the shape of the answer?" Is the answer:

A single number? A sum? A count? --> Think DP, combinatorics, math.
A subset of elements? --> Think greedy, bitmask, or matching.
A path or sequence? --> Think graph, DP, or sorting.
A YES/NO? --> Think binary search on answer, 2-SAT, or flow.

The shape of the answer often narrows the technique even before you understand the full problem.

Step 5: If still blank after 15 minutes, read a hint, not the editorial.

A hint is one sentence: "this is a graph problem" or "try sorting by X." An editorial is the full solution. Hints keep you in the driver's seat. Editorials hand you the answer and take away the practice of finding it. The distinction matters enormously for learning.

4. The Geometry of Progress

Rating progress is not linear. It looks like this:

 Rating
 1900 | *
 1800 | * * *
 1700 | * * * * *
 1600 | * * * * *
 1500 | * * * * * *
 1400 | * * *
 1300 | * * *
 1200 | *
 +-------------------------------------------------> Contests

 Reality: a noisy upward trend with plateaus and drops.
 Not a smooth curve. Not a straight line. Never.

Every sustained plateau has the same anatomy: you've saturated a skill level and are not yet working at the next one. The plateau breaks when you consistently solve problems slightly above your comfort zone -- not far above (demoralizing) and not at your level (no growth).

The target: problems rated roughly 100-200 above your current rating. They're hard enough to require new thinking but tractable enough to finish. This is the productive discomfort zone.

Plateaus at specific ratings tend to have specific causes:

Plateau at ~1200-1300 You can implement what the problem describes but you're not yet extracting the mathematical structure. The fix: practice reading problem statements and before coding, writing down in one sentence what the problem is really asking (not what it says, but what mathematical object it describes).

Plateau at ~1400-1500 You know the standard algorithms (binary search, BFS, basic DP) but you can't see when to apply them. A problem doesn't announce itself as "a binary search problem." The trigger phrases in 03-problem-pattern-recognition.md help, but they only work if you've internalized the algorithms themselves. The fix: do more thematic drills -- 10 binary search problems in a row, 10 DP problems in a row, until your instincts build.

Plateau at ~1600-1700 You know more algorithms than you can use effectively. You identify the right technique for part of the problem but can't combine it with the other part. The fix: study problems that combine two techniques and focus on the glue -- how the output of one technique becomes the input of another.

Plateau at ~1800-1900 The algorithm is no longer the bottleneck -- the modeling is. The problem doesn't say "graph" or "DP." It describes a scenario you must convert into a known structure before the algorithm becomes obvious. The fix: upsolve heavily. Read editorials not for the algorithm but for the reduction -- the moment where the author says "observe that this is equivalent to..." Study that equivalence.

5. What Upsolving Actually Means

Upsolving is not reading the editorial and moving on. Done correctly, it's one of the highest-leverage activities in competitive programming.

The full loop:

 Contest problem you couldn't solve
 |
 v
 Attempt for 30-60 more minutes AFTER the contest.
 You have no time pressure now. Think more carefully.
 |
 v
 Still stuck? Read the editorial TITLE or FIRST PARAGRAPH only.
 (Often the first paragraph is the key insight without the details.)
 |
 v
 Try again with just that hint. Implement from scratch.
 |
 v
 Still stuck? Read the full editorial.
 |
 v
 Understand the approach at the structural level:
 - What did the editorial observe that you didn't?
 - Why does this approach work?
 - What made you not think of it?
 |
 v
 Implement the solution WITHOUT looking at the editorial code.
 Looking at code is the shortcut that prevents learning.
 |
 v
 Get AC. Then -- and this is the part most people skip -- 
 think about the META-QUESTION:
 "What kind of problem was this, really?
 What would trigger me to think of this next time?"
 |
 v
 Write down the trigger in your own words.
 Add it to your personal pattern list.

The meta-question at the end is the entire point. One upsolve that teaches you a new trigger phrase is worth ten upsolves where you just got the code to compile.

6. The Trap of Knowing Too Much Too Shallowly

At some point, the notebook becomes a trap. You've read about centroid decomposition. You've read about persistent segment trees. You understand the ideas at a high level. You feel like you know a lot.

Then you open a problem that needs centroid decomposition and you can't write it.

Shallow knowledge is seductive. It feels like progress. You read a file, you understand the concept, you move to the next file. The notebook grows in your mind as this vast catalogue of things you know.

But there's a test: can you implement it from memory in 30 minutes?

If not, you don't know it -- you've only met it.

The solution is not to stop reading. It's to read and implement, in that order, every time. For every topic in this notebook:

Read the file.
Close it.
Write the implementation from memory.
Compare with the file. Note what you got wrong or forgot.
Write it again, fixing the gaps.
Solve one practice problem using only your implementation.

Only after step 6 do you own the technique. Steps 1-2 alone give you recognition without recall. Recognition loses to recall every single time under contest pressure.

7. The Comparison Trap

You will see people your rating who seem to think faster, code cleaner, solve harder problems with less effort. Some of them started earlier. Some of them have different natural inclinations. Some of them practice in ways that don't look like practice. Some of them are just different.

Comparison is useful when it shows you something to imitate. It's corrosive when it makes you feel like the gap is fixed.

The only contest that matters is you-today versus you-three-months-ago.

Concrete questions to measure yourself against yourself:

Three months ago, could you implement binary search correctly on the first try?
Three months ago, could you debug a wrong answer in under 10 minutes?
Three months ago, could you recognize a DP problem before writing brute force?

If the answers are improving, you're improving -- regardless of what the rating number says this week.

8. What Reading Editorials Is Actually Teaching You

An editorial is not instructions for solving one problem. It's a case study in a problem-solver's reasoning. You should read it that way.

When you read an editorial, the questions to ask are not "how did they solve it?" but:

What did they notice first? What was the entry point into the problem?
What made the reduction possible? There's almost always a moment in an editorial where the author says "observe that..." or "equivalently, we can restate the problem as...". That observation is the skill. That's the thing to extract.
Why wouldn't a simpler approach work? Good editorials explain why $O (n^{2})$ fails and why the clever trick is necessary. Understanding why the wrong approach fails is as important as understanding why the right one works.
Is this a pattern I've seen before? If yes, label it. If no, add it to your pattern collection.
Could I have seen this? Honestly. What would I have needed to know, or notice, to have found this approach? This question builds the mental model for future problems.

If you read an editorial without asking these questions, you're memorizing a solution instead of learning to solve problems.

9. The Practice Problem You Should Never Skip

Every week, before your virtual contest, solve one problem that is rated about 300 above your current rating. Expect to fail. Spend 45 minutes genuinely trying. Then look at the editorial.

This is not regular practice. This is scouting: you're getting a preview of what you'll need to learn eventually. You won't solve it. But you'll form a question -- how was I supposed to see that? -- that primes your brain to notice the answer when it appears in something you study later.

This is how experienced competitors build intuition for hard problems. They've seen the shape of hard problems before. They've failed at them enough to recognize the patterns. The failures weren't wasted -- they were map-building.

10. A Note on Slow Progress

Some weeks you will solve four problems, learn two new techniques, and feel like you're finally moving. Other weeks you will solve nothing, re-read the same file three times, and feel like the walls are closing in.

Both weeks are progress. The second kind is just less visible.

Learning in competitive programming has an irregular texture. There are periods of visible gain and periods that feel like treading water but are actually periods of consolidation -- your brain is organizing and connecting what you've already learned before it can hold more. These periods are necessary. Shortcutting them by pushing harder doesn't work; it usually just produces fatigue.

The question is not "am I making progress fast enough?" but "am I doing the right things consistently?" If you are reading actively, practicing daily, upsolving honestly, and working slightly above your comfort level -- the progress is happening, whether or not this week's contest reflects it.

Trust the process. The path from 1100 to 2100 is long, and it's supposed to be. Every problem you genuinely struggle with and eventually solve is making you a better problem-solver. That's the whole point.

Quick Reference: Common Mental Traps

Trap	What it looks like	What to do instead
Algorithm hoarding	Reading 10 new topics without practicing any	Implement every topic before moving to the next
Editorial escape	Reading the editorial at the first sign of struggle	Give it 20-30 minutes of genuine effort first
Comfortable grinding	Solving 10 easy problems instead of 2 hard ones	Always include problems slightly above your level
Shallow understanding	"I know what a segment tree is" without being able to write one	Test yourself: implement from memory
Rating fixation	Refreshing rating after every contest	Look at your 20-contest trend, not individual contests
Comparison paralysis	"That person solved it in 15 minutes"	Your only competition is your past self
Topic avoidance	Always skipping combinatorics problems	Your avoidance pattern IS the study plan
Editorial reading without implementing	Understanding the solution but not coding it	Never read an editorial without coding the solution yourself
Treating hints as answers	Getting the first hint and immediately reading the full editorial	Extract the minimum information needed to keep trying
Giving up on upsolves	Marking a problem as "understood" after reading the editorial	You understood it when you got AC on your own code

What the Code Won't Teach You

These are the non-algorithmic truths that separate people who know algorithms from people who improve at competitive programming.

The discomfort IS the learning. Twenty minutes of genuine confusion is worth more than twenty minutes of reading a solution. Confusion means your brain is actively searching, forming hypotheses, testing them. That searching is a skill that gets faster with practice.

Your avoidance pattern IS the study plan. The categories you consistently skip or fail at -- combinatorics, constructive problems, greedy proofs -- are exactly what you should be spending time on. Comfort is the enemy of growth.

Recognition without recall is worthless under pressure. You can recognize a segment tree when you see one. Can you implement it from memory in 30 minutes? If not, you've only met the technique -- you don't own it. The test: close the reference, write the code, compare with the reference, fix gaps, write it again.

 THE LEARNING LOOP THAT ACTUALLY WORKS:

 +------------------------+
 | 1. Attempt problem |
 | (genuine effort, |
 | 20-45 min) |
 +----------+-------------+
 |
 v
 +------------------------+
 | 2. Stuck? Read HINT |
 | (one sentence, |
 | not full editorial)|
 +----------+-------------+
 |
 v
 +------------------------+
 | 3. Try again with |
 | just that hint |
 +----------+-------------+
 |
 v
 +------------------------+
 | 4. Still stuck? Read |
 | editorial. Then |
 | implement WITHOUT |
 | looking at code |
 +----------+-------------+
 |
 v
 +------------------------+
 | 5. META-QUESTION: |
 | "What kind of |
 | problem was this? |
 | What would trigger|
 | me to think of |
 | this next time?" |
 +----------+-------------+
 |
 v
 +------------------------+
 | 6. Write down the |
 | trigger in your |
 | own words. |
 +------------------------+

 Step 5 is the entire point.
 One upsolve that teaches a trigger
 is worth ten that just get AC.

 PLATEAU DIAGNOSTIC:

 Rating stuck Most likely cause Fix
 -------------- -------------------------- ----------------------
 ~1200-1300 Can't extract math structure Practice rewriting
 from problem narrative problems as equations

 ~1400-1500 Know algorithms but can't Thematic drills:
 see when to apply them 10 BS, 10 DP, 10 BFS

 ~1600-1700 Can't combine two techniques Study "glue" problems
 in one solution (output of A --> input of B)

 ~1800-1900 Algorithm isn't the Study editorial
 bottleneck -- modeling is REDUCTIONS, not algos

Mental Traps

Trap: "I'll learn this algorithm later when I need it."

Later never comes because you can't recognize when you need it. You don't know what you don't know. The algorithm you skipped is the one you'll miss in a contest -- and you won't even realize it was the right tool.

Trap: "I understood the editorial, so I've learned the technique."

Understanding and being able to reproduce are different skills. Test: close the editorial, wait 24 hours, implement from scratch. If you can't, the understanding was shallow.

Trap: "My rating dropped, so I'm getting worse."

Rating is a noisy signal. A single contest can swing +/-100. Look at your 20-contest moving average. The path to 2100 involves drops, plateaus, and sudden jumps. All are normal.

Self-Test

These are not knowledge tests -- they're honesty tests.

[ ] Name your weakest problem category (the one you skip or fail most). Have you practiced it deliberately in the last 2 weeks? If not, do 5 problems in that category this week.
[ ] Pick your last contest. For each unsolved problem, can you state the key insight from the editorial in one sentence? If not, you read the editorial without extracting the pattern.
[ ] Implement your most-used data structure from memory (segment tree, DSU, BIT). Time yourself. If it takes more than 15 minutes, you've only "met" the technique -- you don't own it.
[ ] Recall one problem where your first approach was wrong. What made the correct approach different? What would have helped you see it faster? This reflection builds the pattern library that raw problem-solving doesn't.
[ ] Rate your upsolving discipline honestly on a scale of 1-5 (1 = "I never upsolve", 5 = "I upsolve every contest within 48 hours"). If below 4, that's your single highest-leverage improvement.

Transfer Lessons

These are the meta-patterns that emerge from honest reflection. Each one is a trigger you can carry into future contests:

Situation	First Instinct	Reframing	Transfer
Rating plateau	"Learn more algorithms"	The bottleneck is usually deployment, not knowledge	Practice implementing under pressure, not reading
Completely blank on a problem	Panic or skip	Go back to constraints -- they hint at the complexity class	Constraints are a message from the setter
Editorial seems obvious	"I should have seen that"	Ask what the entry point was, not the solution	Extract the trigger, not the answer
Solved it but slowly	"I need to practice more"	Identify which phase was slow (reading? modeling? coding?)	Target the bottleneck phase specifically

This file has no prerequisites. It's relevant at every rating level.The techniques in the rest of this notebook teach you what to know.This file is about the thinking that makes the knowing useful.

Reflections -- On Getting Stuck, Getting Better, and Getting Honest ​

Contents ​

1. The Real Reason You're Stuck ​

2. The Internal Monologue of Solving a Problem You've Never Seen ​

3. What to Do When You're Completely Blank ​

4. The Geometry of Progress ​

5. What Upsolving Actually Means ​

6. The Trap of Knowing Too Much Too Shallowly ​

7. The Comparison Trap ​

8. What Reading Editorials Is Actually Teaching You ​

9. The Practice Problem You Should Never Skip ​

10. A Note on Slow Progress ​

Quick Reference: Common Mental Traps ​

What the Code Won't Teach You ​

Mental Traps ​

Self-Test ​

Transfer Lessons ​