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 & 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:- Take a break—clear your head
- Don’t read editorials immediately
- Note which problems you attempted but failed
Step 2: Second Attempt (20-30 minutes per problem)
Before reading the editorial:- Re-read the problem statement carefully
- Check if you missed any constraint or condition
- Think about the problem type (greedy? DP? graph?)
- Try a different approach than during contest
Step 3: Read the Editorial
If you’re still stuck after 20-30 minutes, read the editorial. How to read an editorial effectively:Read Only the First Hint
Most editorials have multiple levels. Read just the first observation or hint.
Step 4: Implement the Solution
Even if you understand the editorial, code it yourself.Step 5: Analyze the Key Insight
Write down the key insight in your own words:Understanding CF Editorials
Structure of a CF Editorial
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)
Spaced Upsolving (1-7 Days Later)
Problems you’ve read editorials for:- Solve again from scratch (no looking)
- If you can’t, you didn’t truly understand
- Read editorial again if needed
- Repeat until you can solve independently
Building Your Problem Log
Create a structured log of every problem you upsolve:Template
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
- Focus on the proof - Understanding why something works is more valuable than the code
- Trace through the logic - Follow each observation step by step
- Identify the key invariant - What property makes the solution correct?
- Connect to similar problems - How does this proof pattern apply elsewhere?
Common Upsolving Mistakes
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:- New: Problems to upsolve
- Review: Problems to revisit
- Mastered: Problems you can solve reliably
Virtual Contest + Upsolve Combo
The most effective practice routine:Upsolving by Problem Type
Greedy Problems
- Identify the greedy choice
- Understand why greedy works (exchange argument)
- Practice recognizing the pattern
DP Problems
- Identify the state
- Write the recurrence relation
- Understand transition logic
- Practice state design on similar problems
Graph Problems
- Identify the graph structure
- Know which algorithm applies
- Practice graph construction from problem statements
Math Problems
- Identify the mathematical property
- Prove or understand the key formula
- 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:- Review your problem log
- Identify common weak areas
- Specifically practice those areas
- Celebrate progress!
Next Steps
Environment Setup
Set up your CP environment for efficient upsolving.
Contest Strategy
Make fewer mistakes during contests = less upsolving needed.
Interview Deep-Dive
You solved a problem during a contest using an O(n^2) approach that barely passed within the time limit. The editorial shows an O(n log n) solution. How do you approach upsolving this -- do you just read the editorial and move on, or is there a more effective process?
You solved a problem during a contest using an O(n^2) approach that barely passed within the time limit. The editorial shows an O(n log n) solution. How do you approach upsolving this -- do you just read the editorial and move on, or is there a more effective process?
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.
Describe a spaced repetition system for competitive programming. How would you implement one, and what evidence suggests it works better than simply solving new problems?
Describe a spaced repetition system for competitive programming. How would you implement one, and what evidence suggests it works better than simply solving new problems?
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.
What makes a good problem log entry, and how does maintaining one accelerate improvement compared to just solving more problems?
What makes a good problem log entry, and how does maintaining one accelerate improvement compared to just solving more problems?
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.