Future Ideas To Improve The Work Experience Project

u-ways commented 1 year ago

What worked well:

Kotlin's interactive learning tour.
Explaining the value of GitHub from a university admission perspective.
The wiki and the funny videos. (It seems it was absorbing enough that they spent most of the day reading it)
A challenge related/themed to our industry.
Having them share their thoughts in the Wiki was useful as we could see what they learned. However, perhaps having it in a more visible place in their Github would be better? For example, the README could be converted to a notebook, and the instructions can be moved to the Wiki for a better UX?)
Having it as an open-source solution made us bypass the need to given them access to our internal repositories and allowed them to have their work in a shareable location.

[x] Have multiple language boilerplates as suggested by Christos (i.e. Give them access to multiple cloud-based IDEs so they don't have to learn a new language)
[x] Although a CI pipeline has been created, the test failure error reporting could, and should be improved to give clear error messages to guide the students towards a passing solution.
[x] The CI pipeline should be broken down to 6 jobs. 1 for building/compiling the project, and the rest is each challenge as a separate build step so students can see which challenge they failed and which ones have passed without having to dig in the logs.
[x] Aspostolos suggested we should avoid explicitly setting the project's timeline in days. Currently the agenda is written in expectations the experience will take 2 days only, however, some schools/students might allocate more (or less) days for their insight days. Abstracting the days out will allow us to be more flexible with the agenda in the future.
[ ] The challenge in the wiki is "too broken down". This eliminates or makes the "analysis" step too easy that students might miss the value of having critical points written down. So instead, we should rewrite the challenges description within each level to be more of a "client" language and hide the requirements within the paragraphs.

[x] Depending on the work-supplied guest laptops is not a good idea. As the local environment was not meant for development and was too restricted. Instead, we need to update the instructions to find a suitable cloud IDE to run this project.
- The cloud IDE should have a simple UI (or a config to allow it to be so)
- It should be easy to paste the logic in there. (Maybe provide them a link to each challenge with content in there already!)
[ ] Trying to make them commit their solutions in Github using Git would be too much of an ask, instead, we need to create a guide to show them how can they use the Github UI to automatically create a merge request when they edit a protected branch! (This will allow them to showcase their contributions and we can use PR bots to validate their submitted solutions!)
[ ] TDD seemed to be a complex concept to fully absorb without any background knowledge for them to apply within the same day in their challenges, so it seems we should inform them we did the "red" TDD part for them (i.e. the automated tests written) and they now need to make it "green". (Maybe a diagram in the Wiki to visualise the RED GREEN REFACTOR idea)

u-ways commented 1 year ago

It seems we can share a challenge URL with pre-pasted content for each round which makes it easier for them to jump straight to solving the problem without having to deal with the setup issues.
We can then guide them to paste the solution in Github (i.e. commit to main) so the tests can be triggered and they can get rapid feedback!

So we now switched to using the playground for users to develop their solutions.

u-ways commented 1 year ago

Raised #6 (Python) and #7 (JavaScript) to add support for multiple languages.

u-ways commented 1 year ago

Raised #8 to provide an appropriate testing specification library and improve error reporting.