4 WAs, a TLE, a new pattern, and the one habit that’s been costing me every contest.
I saw a Leetcode profile recently — 130 days, 1900 rating, no prior experience. I asked what could explain that kind of growth. The answer was simple: consistent contests. Not just weekly ones. Daily virtual contests on top of topic practice.
That hit different. I’ve been grinding topics for 10 days and giving one real contest per week. But topic practice and contest performance are two different skills. You need pressure to build the second one. So I made a change — one virtual contest every evening after the learning session. Real timer, no hints, no AI mid-contest.
Day 1 of that experiment was yesterday.
Virtual Contest — Weekly 502
Q1 ✓ Solved
Q2 ✓ Solved 4 WAs first
Q3 ~ Upsolve
Same pattern as the real contest — Q1 and Q2 solved, Q3 attempted post-contest, Q4 skipped. 45 minutes total. The result looks similar on paper but what happened inside was different.
Q2 — the 4 WAs that taught me everything
The problem asked how many integers x satisfy l ≤ x^k ≤ r. I knew the approach. I coded it immediately. Wrong answer. Fixed something. Wrong answer again. Four times.
The clean solution was right there the whole time:
Take the kth root of both bounds. Every integer between ceil(l^(1/k)) and floor(r^(1/k)) is valid. Count them. One edge case — k=1, return r-l+1 directly.
The floating point trap: pow() in C++ has precision issues. 4^(1/3) might return 3.9999999997 instead of 4.0. Fix it by subtracting a tiny epsilon before ceiling and adding before flooring:
ceil(pow(l, 1.0/k) - 1e-9) and floor(pow(r, 1.0/k) + 1e-9)
I would have caught this in 5 minutes if I’d thought it through before typing. Instead I coded first, debugged after, and burned 4 submissions finding something that should have been obvious during planning.
Think until the thinking is done. Then code.
One extra minute of thinking before the keyboard saves 20 minutes of debugging after.
Q3 — 2D prefix sum, a new pattern
During the contest I couldn’t even parse the question properly under pressure. After the contest I tried brute force — TLE on a case with 200 non-zero values. Then I watched the editorial.
The pattern: for each possible value (0 to 200), build a binary matrix marking cells greater than that value. Then build a 2D prefix sum on each matrix so any rectangle query is O(1). To check if a cell is a local maximum, query the rectangle around it and check if the count of cells greater than it is zero.
The prefix sum formula for 2D:
pref[val][i][j] = pref[val][i-1][j] + pref[val][i][j-1] - pref[val][i-1][j-1] + (matrix[i-1][j-1] > val)
And the rectangle query removes corners the same way. I couldn’t have solved this in contest — it’s a hard pattern I hadn’t seen. But I understand it now. That’s the only thing that matters.
Heap — started with the 9 that matter
The full heap playlist is 17 problems. Given the new plan — 1 DP video daily, virtual contest every evening, ongoing topic in between — 17 problems isn’t realistic without losing depth. So I cut it to 9 high-value ones.
Heap basics locked in first: complete binary tree, 1-indexed left at 2i right at 2i+1, insert and delete both O(log n), heapify to build is O(n) amortized because leaf nodes do no work. Heap sort is O(n log n).
Kth Largest Element in an Array
Min heap of size k. Push every element, pop when size exceeds k. Top of heap is the kth largest. 5 minutes. If you know heap you have this one.
K Closest Points to Origin
Max heap of size k storing {distance, point}. One thing worth noting: no need to compute sqrt for distance comparison. Raw squared distance works and avoids float precision issues entirely.
Kth Largest Element in a Stream
Same pattern as the array version but online — new elements keep arriving. Maintain a min heap of size k. On each add, push the new element and pop if size exceeds k. Top is always the kth largest.
All three today felt easy and fast. That’s what heap problems mostly are once the data structure clicks — you recognize the pattern in 30 seconds and the implementation follows directly.