Advent of Code: How December's Daily Puzzles Can Sharpen Your Coding Skills

For twenty-five days each December, Advent of Code publishes a small programming puzzle at midnight Eastern Time. Two, in fact: part one is usually gentle, and part two takes the same problem and twists it until you have to think again. There is a story attached — elves, snow, a sleigh that needs repairing — and there is a personal input file, different for every participant, so you cannot simply copy an answer from a friend. It is free, it works in whatever language you prefer, and it has quietly become a fixture of many programmers' year.

How the event actually works

The format is deliberately plain. Each day you get a puzzle description, a worked example, and a link to your own input. You feed the input into your program, compute an answer, and submit it. A correct answer earns a star; part two of the same day earns a second one. Fifty stars in total, and no real penalty for a wrong submission beyond a short cooldown after several misses.

Puzzles unlock at midnight Eastern Time, which is convenient for some time zones and miserable for others. The global leaderboard rewards raw speed for the handful of people who care about it; private leaderboards are the sane option, letting a group of friends or colleagues compare star counts over the whole month without anyone waking up at 5 a.m. Everything stays online afterwards, so a puzzle you skip in December is still sitting there in March.

Why it makes a good yearly skills check

Most practice platforms hand you problems with the technique already in the title: binary search, dynamic programming, two pointers. Advent of Code does not. You get a description of behaviour and have to decide what kind of problem it is. That decision is the part that interviews and real work actually test, and it is the part that decays fastest when you spend a year gluing services together.

A few things make the event unusually good at exposing gaps:

• Parsing is half the job. Inputs range from tidy comma-separated lists to nested rule systems and ASCII maps. If you regularly reach for regex or a hand-rolled tokeniser, you will find out quickly where your habits cost you time.
• Part two forces refactoring. Solutions written as one long script tend to collapse when the second half arrives. Keeping part one in a function, with the parsing separated out, is a small discipline the puzzles reward again and again.
• No library shortcuts. The problems are designed to be solved without specialised packages, so graph search, memoisation and interval handling come from your own fingers, not from an import.
• Time pressure is optional. You can race the clock or ignore it entirely. Either way, the difficulty curve will find the edges of what you know.

Reading the difficulty curve

The first week is a warm-up: string handling, small simulations, a bit of arithmetic. Do not be fooled into thinking the rest of the month will feel like that. It is also the best week to try an unfamiliar language, because the cost of a wrong turn is twenty minutes rather than a whole evening.

Around days 7 to 12, the puzzles start asking for proper data structures. Grids appear, then breadth-first search, then something that needs a priority queue or a set of visited states. This is where a small personal toolbox pays off: a coordinate helper, a BFS template, a priority queue wrapper. Writing them from scratch on day 15 at 11 p.m. is not character-building, it is just slow.

From the middle of the month onwards, expect graph problems, dynamic programming, interval arithmetic, and occasionally a puzzle that asks you to build a small virtual machine and then extend it across several days. Days 20 to 25 escalate fast, and the final day is often one long, satisfying problem that pulls together half the techniques you used earlier.

When to skip, and when to read a write-up

Not every day is worth your evening. If a puzzle demands a technique you have never met, spending four hours grinding is usually worse than spending forty minutes on an honest attempt, then reading a solution write-up and reimplementing it yourself. You keep the star, you keep the evening, and you learn the technique. The only rule worth keeping is that you write the code yourself rather than pasting someone else's answer.

A workflow that keeps you moving

1. Read the whole description twice. The second read catches the constraints — the ranges, the wrapping rules, the off-by-one traps — that the first read skims.
2. Parse first, solve second. Turn the raw input into a structure you can reason about, and print a few lines to confirm it looks right.
3. Make the example pass, with an assertion. The worked example is a free unit test and it will catch most misreadings immediately.
4. Solve part one the dumb way. Brute force is fine. Correct and slow beats elegant and wrong.
5. Then read part two properly. Often it needs a completely different approach, and patching the old code costs more than rewriting it.
6. Timebox yourself. Forty-five to sixty minutes is a reasonable limit before you check the community threads. Note what blocked you; that note is the real output of the day.

Pick a language on purpose

Using Advent of Code to learn a new language is a popular and genuinely useful idea, with one caveat: the difficulty curve does not care about your learning goals. A workable compromise is to use the new language for the first ten days or so, then switch to your strongest one when the puzzles get heavy. Nobody is scoring you on consistency. If you do switch, keep both solutions in the same repository — the comparison is instructive.

The community half of the event

Private leaderboards with colleagues turn the month into a low-stakes shared ritual, and a group repository where everyone commits their daily solution produces more interesting reading than any tutorial. The daily solution threads are worth visiting after you finish: seeing a two-hundred-line approach reduced to twelve lines of Python is a better lesson in simplification than most code review you will get at work. Post your own solution once you have the star, not before.

Making it a habit that survives January

Twenty-five consecutive evenings is a lot to ask of anyone with a job, so plan for attrition. Create a repository with a folder per day and a small template — input reading, a place for the example assertion, a timing print — and the daily cost drops to minutes. Keep a running note of the technique that slowed you down each day; by 3 January you will have a short, honest list of things to practise, which is more useful than any generic learning plan.

Aim for a good number of honest attempts rather than all fifty stars. Twenty-five solved puzzles you actually understood beat fifty where a third were copied from a thread. And when December ends, do one thing more: open last year's repository and read a couple of your old solutions. The gap between then and now is the skills check, and it is far more concrete than anything a certificate will tell you.

Photo: Lara / Pexels