Skip to main content

The Mistake Journal System

Every wrong answer contains a lesson. Most competitive programmers make the same mistakes repeatedly because they don’t track them. This chapter gives you a systematic approach to eliminate recurring errors and accelerate your improvement. Mistake Learning Cycle

Why Mistakes Repeat

The brutal truth: Without tracking, you will make the same mistake 10+ times before it sticks. With tracking, you can reduce that to 2-3 times.

The Memory Problem

The 5 Categories of CP Mistakes

5 Categories of Mistakes

Setting Up Your Mistake Journal

Option 1: Notion Template

The Correct Code

Root Cause Analysis

  • Why did I make this mistake?
  • What was I thinking when I wrote it?
  • What should I have done differently?

Prevention Strategy

  • How will I catch this next time?
  • What mental check should I add?
  • Any template/snippet to prevent this?

Tags

#overflow #off-by-one #edge-case #modulo #binary-search

The Master Mistake Database

Top 50 Common CP Mistakes

Build your own database. Here’s a starter:

Integer Overflow (THE #1 KILLER)

Off-By-One Errors

Modular Arithmetic Pitfalls

Binary Search Edge Cases

Graph Algorithm Mistakes

String Processing Errors

Array Initialization


Analyzing Your Mistakes

Weekly Mistake Review

Every Sunday, review your mistake journal: Mistake Analysis Process
1

Count by Category

How many of each type did you make this week?
  • Overflow: 3
  • Edge cases: 5
  • Logic: 2
Focus next week on edge cases!
2

Identify Patterns

Are certain topics causing more mistakes?
  • Binary search: 4 mistakes
  • DP: 1 mistake
Study binary search more!
3

Check for Repeats

Did you make any mistake you’ve made before?
  • Integer overflow: Made it twice this week!
Add reminder to pre-coding checklist!
4

Update Your Checklist

Add the most common mistakes to your pre-submit checklist.
Monthly Mistake Trends Track these metrics monthly:
  • Total mistakes per week (should decrease)
  • Repeat mistakes (should decrease faster)
  • Time to debug (should decrease)
  • New mistake types (sign of tackling harder problems)

The Prevention System

Pre-Coding Checklist

Before you start coding ANY problem, ask:

Pre-Submit Checklist

Before hitting submit, verify:

The “5 Second Rule”

Before submitting, pause for 5 seconds and scan for:
  1. Data types (int vs long long)
  2. Loop bounds (< vs <=)
  3. Edge cases (n=0, n=1)
  4. Output format (newlines, spaces)
  5. Debug output (remove cerr/cout debugging)

Mistake Templates by Topic

Binary Search Mistakes

DP Mistakes

Graph Mistakes


Quick Reference: The Mistake Lookup Table

When you get WA or TLE, check this table:

Building Mistake Immunity

The 3-Strike Rule

If you make the same mistake 3 times:
  1. Create a snippet to prevent it
  2. Add it to pre-submit checklist
  3. Teach it to someone else (explaining cements memory)

The Mistake Flashcard System

Create flashcards for your top mistakes:
Review flashcards weekly before contests.

The “Never Again” List

Keep a pinned list of your top 5 most frustrating mistakes:
Read this before every contest.
Your mistakes are your competitive advantage.Most people make mistakes and forget them. If you track, analyze, and systematically eliminate your mistakes, you’ll improve faster than 90% of competitors.Start your mistake journal TODAY.

Interview Deep-Dive

Strong Answer:
  • The systemic fix has three layers: prevention, detection, and verification. Prevention: add #define int long long to my contest template, or at minimum use long long for any variable that participates in multiplication or accumulation. Detection: compile with -fsanitize=undefined during local testing, which flags signed overflow at runtime. Verification: add an explicit item to my pre-submit checklist — “scan every multiplication and sum for overflow potential.”
  • To measure effectiveness, I continue logging mistakes for the next month and compare the overflow WA rate. If it drops from 40% to under 10%, the fix is working. If it persists, the fix is not addressing the root cause — perhaps the overflows are happening in less obvious places like implicit int-to-int multiplication inside STL operations.
  • Beyond the immediate fix, I would audit my past overflow bugs and categorize them: (1) product of two ints, (2) running sum exceeding 2 times 10^9, (3) modular arithmetic intermediate values, (4) array size calculations. Each subcategory might need a different prevention strategy.
Follow-up: Is there a tradeoff to always using long long everywhere, even when int would suffice?Yes. Long long doubles memory usage for every integer variable and array. A segment tree with 4 million nodes goes from 16 MB to 32 MB. On problems with 256 MB memory limits and large data structures, this can cause MLE. Long long also has slightly slower arithmetic on some architectures (though this is negligible on modern 64-bit CPUs). In practice, the time saved from never debugging overflow bugs far outweighs these costs in 99% of contest problems.
Strong Answer:
  • The 3-strike rule: if I make the same mistake three times (identified via my mistake journal tags), I escalate to a permanent fix. The first occurrence is a learning moment. The second is a warning. The third means my normal coding habits will not prevent this — I need a structural intervention.
  • Structural interventions, ranked by effectiveness: (1) A code snippet in my IDE that auto-generates the correct pattern. For example, after my third binary search infinite loop, I created a VS Code snippet binsearch that expands to a tested template with lo + (hi - lo) / 2 and lo < hi. Now I never hand-write binary search bounds. (2) A checklist item I review before every submission. (3) A macro in my template that handles the case automatically (like safe modular arithmetic).
  • The snippet approach works because it removes the human from the error-prone step. I do not trust myself to remember lo + (hi - lo) / 2 under contest pressure — I trust the snippet that I tested once and reuse forever. This is the same principle as using library functions instead of hand-rolled implementations.
  • Measurement: after implementing snippets for my top 5 recurring bugs, my first-submission acceptance rate increased from 55% to 75% over 2 months. Each prevented WA saves 5-15 minutes of debugging, which compounds across a contest to an extra problem solved.
Follow-up: How do you decide between a snippet, a checklist item, and a template macro?Snippets for patterns with complex syntax that I frequently get wrong (binary search, segment tree, modular inverse). Checklist items for conceptual checks that cannot be automated (did I handle the n=1 edge case? did I reset globals between test cases?). Template macros for things that should always be true in every solution (fast I/O, long long types, safe mod function). The principle: automate what can be automated, checklist what cannot, and template what is universal.
Strong Answer:
  • The forgetting curve (Ebbinghaus, 1885) shows humans forget approximately 50% of new information within 24 hours and 70% within a week without deliberate review. A mistake made on Saturday is largely forgotten by the following Saturday’s contest. The journal is the review mechanism that prevents this decay.
  • Concrete evidence from my own practice: before journaling, I made the integer overflow mistake an average of once per contest for 3 months (12 occurrences). After starting a journal and reviewing it weekly, the same mistake dropped to once per month within 6 weeks. That is a 75% reduction, translating to roughly 10 minutes saved per contest.
  • The journal also reveals patterns invisible to unaided memory. You think you struggle with DP, but your journal shows 80% of your DP mistakes are specifically in the base case initialization, not in the recurrence relation. That level of specificity transforms vague “practice more DP” into actionable “drill DP base cases.”
  • The opportunity cost argument: each recurring WA costs 10+ minutes in a contest (debugging + penalty time). If journaling eliminates 3 recurring mistakes per contest, that is 30 minutes recovered — often enough for an additional problem. Over 20 contests, that is the equivalent of 10+ additional hours of productive contest time.
Follow-up: What is the minimum viable mistake journal — what is the least effort that still provides benefit?After every WA or TLE, write one line: the date, the mistake category (overflow, off-by-one, edge case, logic, reset), and a 5-word description. That is it. Even this minimal log, reviewed weekly, reveals patterns within 2-3 weeks. You do not need elaborate templates or detailed code diffs to get 80% of the benefit. The detailed analysis is nice-to-have for specific difficult bugs, but the category tagging alone drives the core insight.