The problem
LeetCode makes progress look easy to measure.
You solved 100 problems. Fifty were Medium. You practiced four days this week. The numbers went up, so you must be getting better.
The problem is that solved counts hide most of the information that matters in an interview.
Two people can both solve the same Medium problem. One recognized the pattern, explained the tradeoffs, and finished in 25 minutes. The other spent an hour, checked two hints, introduced the same bug three times, and barely got the solution accepted.
LeetCode records both as solved.
If you want to know when you should start interviewing, you need to track more than completion.
What to track instead
A useful readiness tracker needs four signals.
Topic coverage. Which patterns have you practiced enough to recognize? A high total solve count can still hide gaps in graphs, dynamic programming, backtracking, or binary search.
Solving speed. How long do problems take compared with other problems at the same difficulty? A 40-minute Medium means something different from a 40-minute Hard.
Difficulty progression. Are you becoming more comfortable with Medium problems, or are most of your recent solves still Easy? Are harder problems becoming faster over time?
Consistency. Are you practicing regularly, or does the total come from one large burst several months ago?
These signals tell you what happened. Notes explain why.
Combine LeetCode with your notes
I use the noworneverev LeetCode API for activity data and Obsidian for the context behind it.
The API provides the broad history:
- Problems solved
- Difficulty mix
- Topic coverage
- Recent submissions
- Practice consistency
My Obsidian notes provide the missing details:
- Time taken
- Last attempt
- Confidence
- Hints used
- Mistakes I repeated
- Concepts I misunderstood
- What finally made the solution click
The API shows the trend. Notes explain the attempt. Together, they produce a useful picture.
What one solved problem can hide
Take Word Search.
LeetCode sees one completed Medium problem.
My note records that it took 40 minutes. More importantly, it explains where I went wrong. I tried to invent an unnecessary optimization before getting the basic search right. I switched away from DFS because I blamed the approach instead of the bug. I also struggled with removing state correctly during backtracking and only later understood where pruning helped.
The solved count says:
Completed one Medium problem.
The note says:
Backtracking is still a weak area. I complicate the search too early, misdiagnose state-management bugs, and need more practice recognizing when pruning is useful.
That points to two actions: review Word Search, then attempt an unseen backtracking problem with a similar decision structure.
Turn weaknesses into a question queue
The goal is not to build a dashboard full of statistics. The goal is to decide what to practice next.
Each week, identify a small number of strengths and weaknesses from the evidence.
A strength should be supported by more than volume. If array Mediums are consistently solved faster, the explanations are confident, and recent attempts avoid repeated mistakes, that is useful evidence.
A weakness can come from several places:
- Problems that take much longer than others at the same difficulty
- Topics with little recent practice
- Problems that required repeated attempts
- Notes that describe confusion, hints, or recurring bugs
- Previously solved problems that have become stale
The next question queue should mix review problems that test whether the lesson stuck with unseen problems that test whether you can transfer it. If Word Search exposed weak backtracking state management, the next unseen problem should exercise that same skill without being a duplicate.
Make one readiness claim
The tracker should produce one date:
You should be ready to start interviewing by September 15.
That is more useful than a vague status like “making progress.”
The date should move as the evidence changes.
If you commit more hours, solve harder problems faster, and close important topic gaps, the date moves earlier.
If your available time drops, practice becomes inconsistent, or the same mistakes continue appearing, the date moves later.
The explanation matters as much as the date:
The date moved two weeks earlier because Medium solve time improved, graph coverage increased, and you maintained four practice days per week.
This is not a promise that you will pass every interview. It is a concrete claim about when your preparation should be strong enough to begin interviewing.
A weekly tracking template
You do not need a complicated system. Update one snapshot each week.
## Weekly LeetCode snapshot
**Hours available over the next seven days:**
**Ready to start interviewing by:**
**Change from last week:**
### Evidence
- Problems solved:
- Difficulty mix:
- Practice days:
- Typical solve time by difficulty:
- Topics improving:
- Topics falling behind:
- Recurring mistakes from notes:
### Brief critique
- Strong:
- Improve:
### Next questions
1. [Review] Problem — reason
2. [New] Problem — reason
3. [New] Problem — reasonThe template forces every conclusion to connect to evidence. If you cannot explain why a topic is strong or why a question belongs in the queue, do not include it. If the readiness date changes, write down what caused the movement.
Takeaway
Solved counts measure activity. Interview readiness depends on whether you can recognize patterns, solve within a reasonable time, explain your decisions, and avoid repeating the same mistakes.
Use LeetCode for the broad history. Use Obsidian for the story behind each attempt. The point is to make the next week of practice less random.