Hi Florian, maybe I can try to answer your question. because I went through the DHBW myself and had to mentor DHBW students 👋🏻 (I was way ahead of the pack, at least programming-wise), so I know the problems first-hand.

First of all, the challenges you give your students should be real-life problems at your company. Don't give them theoretical tasks, which will be thrown away. Your students will be a lot more motivated if they see their programs being used and know they actually contribute. Don't forget that they are employees, too, and they usually also want to work for their money (which is more special to them than it is to you).

You shouldn't let them work on big old code bases or complex, long-runninig projects, though. Give them a task which they can solve in their three months. That includes preparation, experiments, implementation and testing. Students are slow and their code is bound to be bad, so give them smaller tasks than you would give to regular employees - you can always go over the program and let them refine it if there still is time.

Good topics usually include small helper tool programs, which make everyone's work easier. I had students create tools for automating processes (like form applications, which send mails in a given format), scripts, which pull data from several systems to automate whole manual tasks away, tutorials for girls' day, file converters, etc. They are things a skilled developer would create in a day, however, especially if the students have no experience, it will take them a long time, and they will introduce many bugs. Get them to interact with their "customers" a lot, so they get feedback on how to improve the tools' usage and tailor them to the team's needs. They will rewrite the code a lot with new feature requests, and have a lot of practice this way. Make it a fun (and maybe less professional) time for them, which they can use to explore the field.*

In my experience, you will likely have to throw away their code right after they leave for University, because it is not maintainable and your team finds flaws and expects them to be fixed. Don't tell the students though! They might find out eventually (or not), and they will understand that the tools changed over time and their code was not good (because they were new), however in the beginning, they really just need the sense of accomplishment, which will drive them to learn and practice more. Quite often, my students started to program at home. They began to automize their own lifes with their own skills, which, in the end, leads to more practice and which will make them geat developers in the long run.

* If they return to you, you can start introducing them to regular processes, though, and give them more challenging tasks!