A safe harbor for coders and developers

Projects

Winter Coding Challenge: 30 Days of Algorithms to Sharpen Your Skills

Winter Coding Challenge: 30 Days of Algorithms to Sharpen Your Skills

Around the second week of December, most side projects go quiet. The evenings are dark, the year is winding down, and the vague promise to get better at algorithms gets pushed to January. A winter challenge works differently: it gives that promise a start date, a finish line, and thirty small tasks in between.

Thirty days is long enough to build a habit and short enough to see the end from day one. What follows is a complete plan — how to structure the month, what to solve each week, how to keep going when work gets busy, and what to do with your solutions once you have written them.

Why Thirty Days Beats a Weekend Sprint

Cramming forty problems into a single Saturday feels productive and teaches almost nothing. Memory fades fast when everything arrives at once. Thirty days spread the same workload into forty-five-minute sessions and give your brain time to sleep on each idea. That gap between sessions is where recognition turns into recall.

There is a second benefit: streaks create friction against quitting. Missing day nine is easy. Breaking a nine-day streak is not. Keep the daily commitment small enough that a bad day cannot justify skipping it — one problem, one written explanation, done.

Building the Month in Four Blocks

Pick one language and stay in it for all thirty days. Switching between Python and Java mid-month costs you the fluency that makes pattern recognition possible. Then organise the month into four blocks that build on each other.

  • Days 1–8: Arrays, strings, and two pointers. Sliding windows, prefix sums, in-place manipulation, frequency maps. These problems are the vocabulary the rest of the month speaks.
  • Days 9–16: Searching, sorting, stacks, and queues. Binary search on sorted arrays and on answer ranges, monotonic stacks, interval merging, and the heap problems that always follow.
  • Days 17–24: Recursion, trees, and graphs. Depth-first and breadth-first traversal, binary search trees, topological ordering, connected components, and a first pass at union-find.
  • Days 25–30: Dynamic programming and mixed review. One-dimensional DP, grid DP, knapsack, and longest increasing subsequence, then two days of problems picked at random from earlier weeks.

Two or three problems from each block should be ones you have already seen. Repetition is not cheating; it is the mechanism.

The Daily Routine That Actually Teaches

A session that consistently produces learning has a shape. Yours can be shorter or longer, but keep the order:

  1. Read the problem twice. Write the input constraints and one example on paper before touching the keyboard.
  2. Spend fifteen minutes stuck, deliberately. Try a brute-force approach first and note its complexity.
  3. Write the solution yourself. If nothing works after twenty-five minutes, read a hint — not the full solution.
  4. Test the edges. Empty input, one element, duplicates, negatives, and the largest allowed size.
  5. Write three sentences about it. What pattern did this use? What would have told you sooner? Where else does that pattern apply?

Step five is the one people skip and the one that pays. A solution you cannot describe in plain words will not come back to you in a technical interview or in production code.

A Sample Week to Copy

Specific problems beat abstract categories. Here is what a week might look like, using well-known exercises as anchors and varying the difficulty:

  • Day 1: Two Sum with a hash map. Learn to trade memory for speed.
  • Day 2: Best Time to Buy and Sell Stock. Track a running minimum instead of recomputing pairs.
  • Day 3: Valid Palindrome with two pointers, then again ignoring non-alphanumeric characters.
  • Day 4: Longest Substring Without Repeating Characters. The canonical sliding window.
  • Day 5: Merge two sorted arrays in place, filling from the back.
  • Day 6: Product of Array Except Self. Prefix and suffix passes without division.
  • Day 7: Re-solve Day 4 from a blank file, then explain it out loud.

Notice day seven. A review day every week stops the month from becoming seven disconnected exercises. By day thirty you want thirty solutions and about six of them written twice.

When You Fall Behind

You will miss a day. Travel, illness, a deadline at work — something will interrupt the streak, and the interruption is where most challenges die. Plan for it now.

Decide in advance that a missed day is absorbed, not repaid. Do not stack two problems the next evening; that turns a small gap into a reason to quit. Instead, keep a short list of three easy problems sized for a low-energy evening — a string reversal, a running sum, a simple bracket check. Fifteen minutes on a hard day keeps the habit intact and costs nothing.

If you lose four or five days, shift the schedule rather than compressing it. The blocks matter more than the calendar.

Tracking Progress Honestly

Counting solved problems is a weak measure. Anyone can grind through easy questions and feel productive. Track three things instead: the number of days with a written explanation, the number of problems solved without hints, and the number of patterns you can describe from memory without looking at code.

If you cannot explain why the sliding window works, you have learned a solution, not a technique.

Keep a plain text file, one line per day: the problem, the pattern, how long it took, and whether a hint was needed. Thirty lines of honest notes are worth more than a folder of copied answers. When the month ends, read the first week's entries and notice how much faster the reasoning has become. Put a complexity estimate next to each one, too — writing "O(n log n) for the sort, then O(n) to merge" forces a precision that vague comfort never does.

How to Start Tomorrow

Do not spend a weekend designing the perfect curriculum. Choose a language, name a time of day for the session, and put the four blocks on a calendar. Start with a problem you know you can finish, because day one should end with a solved problem rather than a stalled one. Write the three-sentence explanation even if the problem felt trivial. Then do it again the next day.

By the end of thirty days you will not be an expert, and that was never the point. You will have a working habit, a set of patterns you recognise on sight, and a written record of your own thinking. That is a stronger starting position for the new year than most resolutions ever get.

Photo: EVG Kowalievska / Pexels

Related Posts

Top 10 VS Code Extensions for Python Developers in 2025

Tools

Top 10 VS Code Extensions for Python Developers in 2025

Ten VS Code extensions that genuinely help Python work in 2025, with honest pros, cons, and the order to install them in.

How to Deploy a Static Website with GitHub Pages and a Custom Domain

Tutorials

How to Deploy a Static Website with GitHub Pages and a Custom Domain

A practical walkthrough for hosting a static site free on GitHub Pages, from pushing your first commit to pointing a...