Pick the one that sounds hardest.

You enter real competitions as a team. There is a public leaderboard you can see and a private one you cannot, and the gap between them is where most of the learning happens — it is how you find out whether you built something that generalises or something that memorised.

Start on a beginner competition where the problem is well-posed and the baseline is public. Move to featured competitions when placing stops feeling like luck.

What you come away with

• Validation that survives contact with unseen data
• Reading a leaderboard without fooling yourself
• Working under a deadline you do not control

Take something from nothing to running in production. Users, bugs, feedback, uptime — the parts of engineering that only show up once real people touch your work, and that no course assignment can simulate.

The platform this club runs on was built this way, by members, in the open. So was the Discord bot that registers your project group.

What you come away with

• Shipping something you then have to maintain
• Reading a bug report from someone who is not you
• Making decisions with incomplete information

Take a paper apart and rebuild it from scratch. Most papers do not reproduce cleanly on the first attempt, and working out why — a missing preprocessing step, an undocumented hyperparameter, a different evaluation split — is the actual skill.

Then write up what you found, including the parts that did not work. That write-up is often more useful to the next person than the result itself.

What you come away with

• Reading a paper closely enough to implement it
• Telling a real result from a lucky seed
• Writing up a negative result honestly