One of the more consistent asks from course participants is more exercises. People like the interactive form, but they also want to play with Rust themselves.

The current exercises have some problems:

• They sometimes rely on content not fully covered at the time (Day 1 afternoon exercises uses methods which are not fully introduced at this point)
• They sometimes ask you to solve a problem where the problem itself is challenging (the multi-threaded link checker in the Concurrency section is more of a mini-project than an exercise).

To solve the above, we should write new exercises. The exercises should be trivial: the participants should be able to come up with a correct solution in 30 seconds — the challenge should be "How to implement this in Rust?" The Luhn exercise is a good example: it's easy to see how to solve it in a C-like way where you just iterate through the characters one by one and ignore most error cases. So students can start with that version and iterate on it to make it nicer.

Exercises can also be less free-form than the current exercises. If we provide more scaffolding for the students, we can guide them better and ask them to implement a bigger task. This is something we should do for the link checker exercise. We should provide most of the solution and just let students fill in 20-30 missing lines. That reflects how engineers typically work: you read a lot more code than you write and you are often asked to work in an existing system.