> ## Documentation Index > Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt > Use this file to discover all available pages before exploring further. # Upsolving & Editorials > How to learn from every problem—the skill that separates Specialists from Experts # Upsolving & Reading Editorials ## What is Upsolving? Upsolving = Solving problems you couldn't solve during a contest, after the contest ends. **This is where 80% of your learning happens.** The contest shows you what you don't know. Upsolving teaches you what you need to know. *** ## The Upsolving Process ### Step 1: Wait & Reset (5-10 minutes) After a contest: 1. Take a break—clear your head 2. Don't read editorials immediately 3. Note which problems you attempted but failed ### Step 2: Second Attempt (20-30 minutes per problem) Before reading the editorial: 1. Re-read the problem statement carefully 2. Check if you missed any constraint or condition 3. Think about the problem type (greedy? DP? graph?) 4. Try a different approach than during contest ``` ┌─────────────────────────────────────────────────────┐ │ SECOND ATTEMPT │ ├─────────────────────────────────────────────────────┤ │ 1. Did I read the problem correctly? │ │ 2. What constraints did I miss? │ │ 3. What approach makes sense for these bounds? │ │ 4. Can I simplify the problem? │ │ 5. Are there any patterns I recognize? │ └─────────────────────────────────────────────────────┘ ``` ### Step 3: Read the Editorial If you're still stuck after 20-30 minutes, read the editorial. **How to read an editorial effectively:** Most editorials have multiple levels. Read just the first observation or hint. With that hint, attempt the problem again for 10-15 minutes. Still stuck? Read the next part of the editorial. Ask yourself: "Why does this work?" not "What's the code?" ### Step 4: Implement the Solution Even if you understand the editorial, **code it yourself**. ```cpp theme={null} // Don't copy-paste from editorial // Type it out, understand each line // Add your own comments explaining the logic ``` ### Step 5: Analyze the Key Insight Write down the key insight in your own words: ``` Problem: [Problem Name] Key Insight: [One sentence explaining the core trick] Pattern: [What type of problem was this?] Mistake: [What did I miss during contest?] ``` *** ## Understanding CF Editorials ### Structure of a CF Editorial ``` ┌─────────────────────────────────────────────────────┐ │ Problem A - [Title] │ │ │ │ Time Complexity: O(n) │ │ Author: [Name] │ │ │ │ [Observations/Hints] │ │ Observation 1: ... │ │ Observation 2: ... │ │ │ │ [Solution Approach] │ │ Step-by-step explanation │ │ │ │ [Code] │ │ Reference implementation │ │ │ │ [Proof/Why It Works] (sometimes) │ └─────────────────────────────────────────────────────┘ ``` ### Reading Between the Lines **Common Editorial Phrases & Their Meanings:** | Editorial Says | What It Really Means | | ------------------------------- | -------------------------------------------------- | | "Observe that..." | This is the key insight you probably missed | | "It's easy to see..." | It's not easy, but this is a standard technique | | "Without loss of generality..." | You can simplify by assuming something | | "Clearly..." | The author thinks it's obvious (it's not) | | "Consider the optimal solution" | Think about what any correct answer must look like | | "Greedy works because..." | There's a proof, but trust it for now | *** ## Upsolving Workflow ### Immediate Upsolve (Same Day) ``` ┌─────────────────────────────────────────────────────┐ │ CONTEST DAY SCHEDULE │ ├─────────────────────────────────────────────────────┤ │ Contest 2 hours │ │ Break 30 min │ │ Second attempt (no editorial) 30-60 min │ │ Read editorials + understand 30 min │ │ Implement solutions 30-60 min │ └─────────────────────────────────────────────────────┘ ``` ### Spaced Upsolving (1-7 Days Later) Problems you've read editorials for: 1. Solve again from scratch (no looking) 2. If you can't, you didn't truly understand 3. Read editorial again if needed 4. Repeat until you can solve independently *** ## Building Your Problem Log Create a structured log of every problem you upsolve: ### Template ````markdown theme={null} ## Problem: [Link] **Rating**: [800-3500] **Tags**: [DP, Greedy, Graph, etc.] **Date**: [When solved] **Source**: [Div 2 C, Educational, etc.] ### Key Insight [One sentence: the core trick or observation] ### Approach 1. [Step 1] 2. [Step 2] 3. [Step 3] ### My Mistake During Contest [What went wrong / what I missed] ### Pattern Recognition [What type of problem is this? What similar problems exist?] ### Code Snippet (if unique technique) ```cpp // Key part of the solution ```` ```` ### Example Log Entry ```markdown ## Problem: CF 1873D - 1D Eraser **Rating**: 1100 **Tags**: Greedy, Two Pointers **Date**: 2024-01-15 **Source**: Div 4 D ### Key Insight Greedily erase from left to right. When you hit a 'B', erase the next k characters and jump ahead. ### Approach 1. Scan left to right 2. When we see 'B', increment count, skip k characters 3. When we see 'W', just move to next character ### My Mistake During Contest Overthought it. Tried to find "optimal" erasing positions. Should have realized greedy from left works. ### Pattern Recognition This is a "greedy scheduling" problem in disguise. Similar to: interval covering, activity selection. ```` *** ## Finding Editorials ### Where to Look **Pro Tip**: Official CF editorials are the gold standard. They include mathematical proofs and formal explanations that make the ideas much more intuitive than just looking at code. Understanding the "why" through proofs builds stronger pattern recognition. | Source | Quality | Why Use It | | --------------------- | --------- | ---------------------------------------------------------- | | Official CF Editorial | ⭐⭐⭐⭐⭐ | Mathematical proofs, formal explanations, builds intuition | | CF Comment Section | Variable | Community insights, alternative approaches | | CP-Algorithms | Excellent | Deep theory and implementation details | | USACO Guide | Great | Well-structured for common problems | ### Reading CF Editorials Effectively 1. **Focus on the proof** - Understanding *why* something works is more valuable than the code 2. **Trace through the logic** - Follow each observation step by step 3. **Identify the key invariant** - What property makes the solution correct? 4. **Connect to similar problems** - How does this proof pattern apply elsewhere? *** ## Common Upsolving Mistakes **Mistake 1: Reading Editorial Too Soon** Give yourself at least 20-30 minutes of genuine effort before reading. **Mistake 2: Copy-Pasting Code** Always type the solution yourself. Muscle memory matters. **Mistake 3: Not Implementing After Reading** Understanding ≠ Being able to code it. Always implement. **Mistake 4: Moving On Too Quickly** If you can't explain the solution to a friend, you don't understand it. **Mistake 5: Never Revisiting** Problems you upsolve should be solved again 3-7 days later. *** ## The Spaced Repetition System ### Rating-Based Intervals | Problem Rating | First Revisit | Second Revisit | Third Revisit | | -------------- | ------------- | -------------- | ------------- | | At your level | 3 days | 7 days | 30 days | | +100 above | 2 days | 5 days | 14 days | | +200 above | 1 day | 3 days | 7 days | ### Tracking System Create three lists: 1. **New**: Problems to upsolve 2. **Review**: Problems to revisit 3. **Mastered**: Problems you can solve reliably Move problems through the pipeline as you master them. *** ## Virtual Contest + Upsolve Combo The most effective practice routine: ``` ┌─────────────────────────────────────────────────────┐ │ WEEKLY SCHEDULE │ ├─────────────────────────────────────────────────────┤ │ Saturday: │ │ - Virtual Contest (2 hours) │ │ - Break (30 min) │ │ - Upsolve unsolved (1-2 hours) │ │ │ │ Sunday: │ │ - Review Saturday's upsolves │ │ - Solve 3-5 new problems │ │ │ │ Monday-Friday: │ │ - Solve 2-3 problems daily │ │ - Review old upsolves (spaced repetition) │ └─────────────────────────────────────────────────────┘ ``` *** ## Upsolving by Problem Type ### Greedy Problems 1. Identify the greedy choice 2. Understand **why** greedy works (exchange argument) 3. Practice recognizing the pattern ### DP Problems 1. Identify the state 2. Write the recurrence relation 3. Understand transition logic 4. Practice state design on similar problems ### Graph Problems 1. Identify the graph structure 2. Know which algorithm applies 3. Practice graph construction from problem statements ### Math Problems 1. Identify the mathematical property 2. Prove or understand the key formula 3. Remember the technique for future problems *** ## Key Metrics to Track ### Weekly Goals | Metric | Target | Purpose | | -------------------- | ------ | -------------------------- | | Problems Upsolve | 10-15 | Learning new techniques | | Problems Revisited | 5-10 | Solidifying knowledge | | Virtual Contests | 1-2 | Simulating real conditions | | New Patterns Learned | 2-3 | Expanding toolkit | ### Monthly Review At the end of each month: 1. Review your problem log 2. Identify common weak areas 3. Specifically practice those areas 4. Celebrate progress! *** ## Next Steps Set up your CP environment for efficient upsolving. Make fewer mistakes during contests = less upsolving needed. *** ## Interview Deep-Dive **Strong Answer:** * Reading the editorial and moving on is the single biggest upsolving mistake. Understanding an algorithm conceptually and being able to implement it under pressure are completely different skills. My process has five steps. * Step 1: Read only the first key observation in the editorial, then close it and try again with just that hint. Often the editorial's first observation ("notice that sorting the array by end time simplifies the problem") is the insight I missed, and with that nudge I can derive the rest independently. * Step 2: If still stuck after 15 minutes, read the full editorial and understand the proof of correctness, not just the code. Why does the O(n log n) approach give the same answer as my O(n^2) approach? What property does it exploit that I missed? * Step 3: Implement the solution from scratch without looking at the editorial code. If I cannot implement it, I do not truly understand it. This is where most of the real learning happens. * Step 4: Write a one-sentence summary of the key insight and tag it by pattern (e.g., "binary search on answer with greedy check," "monotonic stack for next-greater-element"). This builds my pattern library for future problems. * Step 5: Re-solve the problem from scratch 3-7 days later without any references. If I can solve it clean, the pattern is internalized. If not, I repeat the process. **Follow-up:** How do you decide which problems are worth upsolving versus which to skip? I prioritize upsolving problems that are 100-200 rating points above my current level and that use techniques I have seen but not mastered. Problems way above my level (300+ rating gap) often require techniques I have never encountered, and the editorial will not make sense without prerequisite knowledge. Problems at or below my level that I failed during the contest are high priority because they reveal bugs in my fundamentals, not missing knowledge. I skip problems that require highly specialized techniques (like segment tree beats or Li Chao tree) unless I am specifically studying that topic. **Strong Answer:** * Spaced repetition exploits the spacing effect from cognitive science: information reviewed at increasing intervals is retained far longer than information crammed in a single session. For CP, this means re-solving upsolve problems at intervals of 1 day, 3 days, 7 days, then 30 days. * Implementation: I maintain three lists -- "New" (problems to upsolve), "Review" (problems to re-solve), and "Mastered" (problems I can solve reliably). After upsolving a problem, it goes into "Review" with a next-review date. Each time I successfully re-solve it without hints, the interval doubles. If I fail, the interval resets to 1 day. * The evidence: without spaced review, I have observed (and research confirms) that people forget roughly 50% of a newly learned algorithm within a week. With spaced review, the same person retains 90%+ after a month. In CP terms, this means during a contest you can actually recall and implement the technique you studied, rather than vaguely remembering it exists but not being able to code it under time pressure. * The ratio I recommend: 60% new problems, 40% review problems. This feels slow initially but compounds dramatically. After 3 months, the "Mastered" list has 50-100 patterns that are rock-solid, and those patterns cover the majority of problems at your rating level. **Follow-up:** Can you apply spaced repetition to algorithm templates and code snippets, not just problem-solving? Yes, and I recommend it. I maintain a set of "implement from scratch" drills: write a segment tree, write Dijkstra, write a DSU, write binary search on answer -- all without references. I do this once a week before a contest as a warm-up. The first time it takes 15 minutes to write a segment tree. After a month of weekly practice, it takes 3 minutes. That speed difference during a contest is often the difference between solving 3 and 4 problems. The key is implementing from memory, not copy-pasting from a library. **Strong Answer:** * A good problem log entry captures four things: (1) the key insight I missed, stated in one sentence, (2) the pattern category (e.g., "binary search on answer," "greedy with exchange argument"), (3) what specifically went wrong during my attempt (misread the problem, chose wrong data structure, had an off-by-one bug), and (4) a prevention strategy for next time. * The log accelerates improvement because it converts implicit experience into explicit knowledge. Without a log, I might solve 500 problems and make the integer overflow mistake 30 times before it becomes automatic to use long long. With a log, I see "overflow" appearing 5 times in a week, add it to my pre-submit checklist, and eliminate it within 2 weeks. * The pattern categorization is especially powerful. After logging 100 problems, I can filter by tag and see: "I have seen 12 binary-search-on-answer problems and solved 8 of them during contest. My failure mode is always in defining the check function." That kind of specific insight is impossible to derive from a raw list of solved problems. * The log also reveals plateau causes. If I have not logged any DP problems in a month, it is because I am avoiding them, and that avoidance is exactly why my rating is stuck. **Follow-up:** How is this different from just reviewing your Codeforces submission history? Your submission history shows what you solved and when, but not why you struggled or what you learned. It does not capture the key insight, your specific mistake, or the pattern category. It also does not track problems you read editorials for but decided to skip. The log is a curated learning record; the submission history is raw data. Reviewing raw data is like reading a server log versus reading an incident postmortem -- the postmortem tells you what actually mattered.