How to Run a One-Hour Mini Contest at Your Coding Club

Most coding clubs hit the same wall around the sixth or seventh week. The first excitement has worn off, the long project is half finished, and a few students have started drifting to the back row with their phones. You want something that gets everyone typing again, but a full hackathon takes a whole Saturday and a lot of planning.

A one-hour mini contest fills that gap. I coach students for programming olympiads, and I borrowed the format from contest training, then softened it for clubs where some members have never written a loop and others are already using dictionaries without thinking. Over the last two years I have run 14 of these with groups of 12 to 30 students. This is the version that works, including the parts I got wrong at first.

Why short contests work better than you would expect

A long project rewards the confident students. They plan, they type, and the quieter ones watch. A short contest with small, separate problems changes the dynamic. Every problem is a fresh start, so a student who got nowhere on the second one can still solve the first and feel it. The clock also helps. Sixty minutes is long enough to think and short enough that nobody has time to get bored.

There is a second benefit that matters to me more as a coach. A contest shows you, in one evening, exactly where each student is stuck. Who reads the input wrongly? Who writes a correct idea but cannot turn it into code? Who freezes when their first attempt fails? You learn more in that hour than in a month of watching people follow a tutorial.

"Competition will scare beginners off"

This is the objection I hear most from club leaders, and it is reasonable. A ranking with names on it, where three experienced students solve everything in twenty minutes, can be miserable for someone in their second week.

But the problem is the scoring, not the competition. In my first two contests I used the classic olympiad rule: rank by problems solved, then by total time, with a penalty for every wrong submission. Two beginners left early and did not come back the following week. Since then I have changed three things, and nobody has walked out since.

• Students work in pairs, one newer member with one more experienced member, and the newer member types.
• There are no penalties for wrong attempts. Trying something and seeing it fail is the whole point.
• Every problem has its own small prize for the first pair to solve it, so the easiest problem is worth celebrating too.

The typing rule is the important one. It keeps the experienced student explaining rather than taking over, which is good practice for them as well. If your club already pairs people this way for projects, the contest fits straight in. Our list of club projects that work with mixed skill levels uses the same idea over a longer timescale.

Choosing four problems

Four problems is the right number for an hour. Fewer and the strongest pairs finish with half the session left. More and the weakest pairs see a wall of text and give up before they start. The problems should rise in difficulty, and each one should test a single skill.

Here is a set I have reused, with small changes, for Python clubs. The solve rates are from my last six contests combined, out of 71 pairs.

Problem A should be solvable by almost everyone, and if fewer than about 85 percent of pairs get it, it was too hard. Problem D is there so the strongest pairs have something to chew on. Most clubs will never see it solved, and that is fine.

Problem C is my favourite for teaching. The obvious recursive solution works for small staircases and then becomes far too slow somewhere around 35 steps. Pairs who discover that the answer follows the Fibonacci pattern have one of those moments they remember for months.

Write each problem with a short story, a clear description of the input and output, and two worked examples. Keep each problem statement under 150 words. Beginners lose more time to long statements than to hard ideas.

Judging without an online judge

You do not need a contest platform. For each problem I prepare five test files: the two examples from the statement and three hidden ones, including an edge case such as a zero, a single item list or the largest allowed input. When a pair says they are done, a mentor runs their program against each file and compares the output by eye or with a tiny script. It takes about a minute per check.

If a solution fails, tell the pair which test failed but not what the answer should be. Then let them work it out. This is exactly the skill described in our piece on getting unstuck on a practice problem without peeking, and the contest gives them a reason to use it.

The last fifteen minutes matter most

My timetable is five minutes to read all four problems, forty minutes of coding, and fifteen minutes of discussion. I have tried shortening the discussion to give more coding time, and it was a mistake every time.

In the discussion, ask a pair who solved each problem to explain their approach in plain words, without showing code. Then ask whether anyone did it differently. For problem A there are usually three or four distinct methods, from converting the number to a string to repeatedly dividing by ten, and seeing them side by side teaches more than the contest itself. Finish with problem C or D even if nobody solved it, because that is where the most interesting idea lives.

Keep a simple record afterwards: which problems each pair solved and roughly how long it took. After three or four contests you will see who is ready to move on and who needs another month of basics.

Plan one for next week

This week, write problem A and problem B, with two examples and three hidden test files each. That is enough for a first contest, and you can add C and D once you see how your club responds. Book a 60-minute slot, set up mixed pairs in advance, and buy a bag of sweets for the first-to-solve prizes. You will learn more about your students in that hour than in the previous three sessions combined. More group ideas sit in our club projects section.