I’ve recently been investing time in our Graduate programme. I’ve seen several different suggestions on how to best put them together. This was one suggestion that someone sent through to me.
The graduates form 2-3 teams that are each building something (probably a SPA) to solve a business problem, whether for MYOB or maybe for a charity etc, for MYOB would be ideal as you feel like you are contributing and building something useful. I was thinking something like making the training/brown bag board digital, making a suggestions and events portal for the social committee but there are many options.
They go through an entire building process from the start to the end, being able to focus and learn one area at a time eg. front end, back end, DevOps. This will enable them to focus on learning areas they may not have covered at uni, but that are an important part of every day delivery at MYOB. I have listed some of the topics below, but I am sure there are many more
Difference between a library and a framework – each team could do something different Choice of language Popular choices of each and why Common file structures to follow AWS / Databases Different types of testing How tests fit into your file structure Build pipelines Integration/smoke testing Pull requests and code reviews on Github Communicating with your team to avoid github/deployment errors Using MYOB styles packages / Feelix Breaking down projects into milestones and stories Using a board / Jira to track workflow
Each team would need a mid/senior developer (who could rotate), and a manager could oversee all of the teams. They would also need the support of other areas (eg ux, BA, QA) depending on what they are working on, which would allow them to meet existing employees and understand how they interact with these roles.
Halfway through the projects the teams should swap, to finish building what the other team had started. This would give them a sense of having to work on and understand a new code base (as they will do in their teams), but they will be able to ask each other questions/for assistance as they will have the greatest amount of knowledge of the app.
Having focus on one project will allow the grads to absorb and understand what they are doing, rather than regularly context-switching from a class-learning to practical environment. They would be able to gather around a board when needed and learn about a new topic or theory before applying it. Some sitepoint/short courses could be included as spikes on particular topics, where they could then discuss application options with their senior dev. All of the grads I have spoken to have commented on how they always learn more when they can instantly practically apply their new knowledge.
Having all of the grads understand a similar project will enable them to experiement with mobbing sessions, group refactoring sessions, and learn ideas and concepts that may better influence the team they will join in their rotations.
This period should be the same time frame for all students, with a focus on learning how our software connects and works together. I feel like having a learning period with a timeframe that is different for each person dependent on skills will only encourage competition, and will make people who do not finish first feel less capable and left behind. This was felt during the developHER program with only 3 people in a classroom environment, if I had watched 6 or 7 of my colleagues ‘move on’ without you I know I would feel left out.
I am not sure what the diversity numbers are in terms of our male/female grads, but (very generally) I would also be conscious of male colleagues being more competitive and some female developers potentially feeling left behind
After this time the graduates could start their rotations, with a better idea of what they like to work on (front end, develops etc) so they can select teams they have a personal interest in, where they are more likely to connect with their colleagues and feel like they are adding value.
