30 days. 4 contests. One shot at proving I actually know this stuff.
I’ve been on Leetcode for a while. 194 problems solved, 104 active days, a max streak of 27.
On paper, it looks decent. But my contest rating sits at 1474, and I know exactly why — I freeze.
I know the patterns vaguely, but vaguely isn’t enough when the clock is running.
So starting today, I’m doing something about it. 30 days, structured topic-by-topic, 5 hours a day, 4 real contests as checkpoints.
The goal is 1900+. That’s not a typo.
Today — graphs
Week 1 is Graphs, DP, Binary Search, and Two Pointers. Today I focused on graphs — the fundamentals I’ve been “familiar with” but never truly tight on.
BFS — mark on push, not on pop
The classic mistake: marking a node visited when you dequeue it. You should mark it the moment you push it to the queue. Marking on pop causes duplicate entries and wasted work. There’s an if visited: continue workaround, but it’s slower.
DFS — iterative order is trickier than it looks
For iterative DFS to match recursive order, iterate neighbors from end to start. The last pushed neighbor gets explored first, mimicking the recursive call stack. If the judge only wants a valid DFS order, forward iteration works — but know the difference.
Cycle detection — always track the parent
In an undirected graph, a cycle exists if a visited neighbor isn’t the current node’s parent. Both BFS and DFS work for this. Once you understand the logic, the DFS version follows naturally.
Distinct islands — shape fingerprinting
The insight: record relative positions from the starting cell of each island’s DFS, not absolute grid coordinates. Store each shape in a set. Count the set size at the end.
Bipartite check — greedy coloring
Try to 2-color the graph. If two adjacent nodes get the same color, it’s not bipartite. A graph with an odd-length cycle can never be bipartite — but you don’t need to find the cycle, just let the coloring fail.
What I’m doing differently
10 minutes solo attempt on each problem. Then 20 minutes with the solution — not just reading it, understanding every line.
At the end of the day, brief notes: the core idea, the gotcha, one or two code lines worth remembering.
That’s this post, essentially.
I’ve done “DSA sprints” before, and they fell apart. Usually because I tried to go too hard too fast, or I skipped the note-taking step. This time, the notes are the point. The contest is a forcing function.
