Problem Tracking¶
Solving problems without tracking them is paying a cost twice: once to struggle through the problem, and again when the same pattern reappears six weeks later and feels unfamiliar. Tracking is not journaling — it is a precision retention system. The goal is: when a pattern appears in a new problem, your brain fires a connection to a previous solve. That connection requires deliberate encoding.
What to Track Per Problem (Non-Negotiable)¶
This is the minimum viable problem log. Do not over-engineer it. Do not under-engineer it.
ID | Problem number and platform (e.g., LC-1, CF-123A, CSES-1683)
Title | Problem name
Date | Date solved (YYYY-MM-DD)
Status | Solved / Solved-with-hint / Watched-solution / Unsolved
Time | Minutes taken (approximation is fine)
Difficulty| Easy / Medium / Hard (use platform rating)
Pattern | 2-4 word tag: "Sliding Window", "BFS + visited set", "0/1 Knapsack"
Approach | 2–3 sentences: what was the key insight? What made it click?
Mistakes | What went wrong first? Off-by-one? Wrong data structure? Wrong complexity?
Revisit? | Y/N — flag if you want to redo this in 2–4 weeks
Why “Pattern” is the most important field: The entire point of problem practice is pattern recognition. If you log 300 problems but never extract the pattern label, you’ve memorized 300 solutions, not 15 patterns. Pattern is the abstraction that makes new problems solvable.
Tracking Tool Options¶
Option 1: Plain Markdown in Your Git Repo (Recommended)¶
A single README.md or problem_log.md in your dsa-journey GitHub repo. Simple, portable, version-controlled, zero dependency on external tools.
Template file structure:
# Problem Log
## Legend
- Status: ✅ Solved | 🟡 Hint | 👀 Watched | ❌ Unsolved
- Revisit: 🔁
## Log
| # | ID | Title | Date | Status | Time | Pattern | Revisit |
|---|-----|-------|------|--------|------|---------|---------|
| 1 | LC-1 | Two Sum | 2026-07-27 | ✅ | 12m | HashMap O(n) lookup | |
| 2 | LC-121 | Best Time to Buy/Sell Stock | 2026-07-28 | ✅ | 18m | Sliding Window (min tracker) | |
| 3 | LC-217 | Contains Duplicate | 2026-07-28 | ✅ | 8m | HashSet | |
## Pattern Index
### HashMap
- LC-1 (Two Sum): classic O(n) complement lookup
- LC-49 (Group Anagrams): sorted string as key
### Sliding Window
- LC-121 (Stock prices): track running minimum
- LC-3 (Longest Substring No Repeat): expand-contract with HashSet
The Pattern Index is separate from the log table — it groups problems by pattern. Build it as you go. By Phase 4, this index becomes your primary exam-prep tool.
Option 2: Notion¶
If you prefer a visual, filterable database, Notion works well for problem tracking.
Recommended Notion setup:
Create a database with properties: ID, Title, Platform, Date, Status (Select), Time (Number), Pattern (Multi-select), Difficulty (Select), Revisit (Checkbox)
Add a “Notes” text block to each entry for the Approach and Mistakes fields
Create filter views: “Revisit = Yes” (for review sessions), “Pattern = DP” (for pattern drilling)
Community verdict (r/learnprogramming, 2025): Notion is popular for tracking but has one failure mode — over-designing the database structure instead of actually solving problems. Spend 20 minutes max on your Notion setup, then start using it. Do not spend 2 hours on templates.
Option 3: Obsidian¶
Obsidian (obsidian.md) is popular for knowledge management and works well if you’re already using it. The advantage over Notion: local files, no internet required, graph view shows connections between patterns.
Verdict: If you’re already an Obsidian user, use it. If not, Notion or plain markdown is lower overhead for this specific use case.
Option 4: LeetCode’s Built-In Tracking¶
LeetCode shows your solve history, difficulty distribution, and tag breakdown. It’s useful as a supplementary view but insufficient as a primary log because:
It doesn’t capture time-to-solve
It doesn’t capture pattern labels (you can add notes per problem in Premium)
It doesn’t let you track non-LeetCode problems (CSES, CF)
Use LeetCode’s stats as a secondary checkpoint (check your tag distribution monthly). Do not rely on it as your primary tracking system.
Anki for Pattern Memorization¶
The community is divided on Anki for DSA. The honest assessment:
Arguments for Anki (r/learnprogramming, moderate support):
Spaced repetition works for memorizing: time complexity of algorithms, algorithm names → use cases, common edge cases for specific patterns
Some learners use Anki for “pattern → approach” cards: front “Given a string, find longest substring without repeating characters” → back “Sliding window + HashSet, O(n)”
Arguments against Anki for DSA (r/competitiveprogramming, stronger consensus):
DSA skill is not memorization, it’s generalization. Anki can make you memorize that “Two Sum = HashMap” without understanding why.
The same retention is achieved more effectively by solving variants of the same problem type.
Time spent making Anki cards is time not spent solving problems.
Verdict for this learner: Do not use Anki for individual problem memorization. Use it only if you want to memorize: the Big-O of standard operations (sort, binary search, heap operations), or the names of algorithms you keep forgetting exist. Keep the Anki deck small — under 50 cards. Do not spend more than 5 minutes/day on Anki.
DSA Anki decks available: A deck called “LeetCode Patterns” exists on Anki’s shared deck library. Community verdict is mixed — the patterns are mostly correct but not comprehensive. If you use Anki at all, build your own cards from your problem log, not from a pre-made deck. Your own cards encode your specific gaps.
GitHub Repo Setup for DSA Practice¶
When to Push¶
Do not push every solve as a separate commit. The signal-to-noise ratio collapses. Recommended cadence:
After each session (2–3 hours of solving):
git commit -m "Phase 1: add LC-75, LC-76, LC-567 (sliding window)"After completing a pattern section:
git commit -m "Phase 1 complete: sliding window (8/8 NeetCode 150 problems)"After weekly review: Update the problem log, commit the updated log
README Format for the Repo¶
# DSA Journey
Start: July 27, 2026 | Target End: April 27, 2027
## Progress
- Phase 0 (Jul 27 – Sep 10): [ ] In Progress
- Phase 1 (Sep 10 – Oct 27): [ ] Not Started
- ...
## Stats
- Total problems solved: X
- LeetCode: X (Easy: X, Medium: X, Hard: X)
- CSES: X / 400
- Codeforces max rating: X
## Problem Log
See [problem_log.md](problem_log.md)
Keep this README updated monthly. It serves as the single honest audit of your progress.
The Weekly Review Ritual (15 Minutes)¶
Every Sunday (or your preferred reset day), do this before starting new problems:
Check your Revisit flags. Pick 2–3 problems you flagged for revisit. Attempt them cold (no notes). If you solve them fluently, remove the flag. If not, flag them for another 2 weeks.
Update your pattern index. Add new problems solved this week to the pattern index.
Check the numbers. How many problems this week? How does it compare to your weekly target (15–20 problems)?
One honest sentence about the week. What pattern is weakest? What clicked this week?
Total time: 15 minutes. Do not skip this. The people who skip the weekly review are the same people who solve the same type of problem again 6 weeks later and wonder why it still feels new.
Navigation: ← 01_ide_and_environment.md | → 03_competitive_programming_setup.md