My name is Rowland, and as I work in a research institute and have a background as a developer, I tend to marry these skills together into research-based and developer projects, sometimes both.
The way I allocate students to projects is based on their skills and interests. The process is as follows:
I send an email to acknowledge their submission has been seen. If the application is not taken forward I email the unsuccessful students as soon as possible. If the application is taken forward I reach out to them for a short discussion.
At that short discussion I explain to them the projects that might interest them and where I see that they could contribute. I explain the challenges and whether something is difficult or easy. I ask them to think about what they want. I also share with them the link to the project page so that they can see more options. This might take 15 minutes per student and takes up a lot of time, but I think it is worth it to make sure I understand them.
Once they agree to a project that they want to do and that I can allocate them to, I will email them with an offer. At this point they can accept or refuse this offer.
During the project, I ask the students to understand the basic concepts before they choose how they would like to improve the project. So, if they want to create a web application, they can, if it contributes to solving the broader problem. In that way, we are asking them to self-direct their project to something that is interesting to them and helps build the skills they want.
I have changed the way I have setup the student projects so that now students are in groups of three. There have been times when I have not been able to make that happen, but that is the standard as of Summer 2023/2024.
As per the RCP student handbook and the RCP onboarding checklist, I mention to them that I will schedule a time to catchup with them for a project meeting at the start of every week.
You can see the key milestones and the onboarding emails we send at regular intervals during the internship.
Most projects are building on the previous set of students work as they are complicated and it can take a long time for average students to grasp new domain information. These average students want to be spoon-fed, which is a major criticism that businesses have of new graduates.
By doing this I teach them that they need to document their new knowledge and technical work for the next set of students, which increases findability, usability and maintenance of the work that they have done. This is also a critical skill for their future careers for project handovers and maintenance work, which many students do not have experience with.
As discussed earlier, the students and look at the wiki that shows what the previous students have done, and I also talk to them over the phone about the work of the previous students. This should not be a surprise to applicants that they are working on a project developed by previous interns. They can refuse the offer of the project if they find the project not to their liking.
The current intake of the Genomics Metadata Multiplexing project is an example of an ongoing project that is working extremely well due to the foundational work done by previous students. This set of students are enjoying the work and the ability to make a difference.
I also have scheduled a voluntary follow-up session / networking session between students on Thursday across the entire student intake but have stopped these due to lack of uptake by the students. By the third week no-one attends, and I am left to myself.
I also have added to the handbook and onboarding checklist the monthly in-person Research Software Engineer (RSE) lunches that I organise and attend but again, the uptake has been low. Roughly, less than 5% of students attend a lunch and none attend consistently.
Last intake, I asked a group of students to liaise with another group on a project. I asked multiple times but this was not actioned. This intake, I did ask for more structure where a scheduled meeting with a sister project needed to be set and this has increased the communication between groups.
In the projects where there is a need for a Subject Matter Expert (SME), I have been trialling to catchup with the SME at the 5-week mark for a Q and A. This allows the students to understand the information in the wiki and some basic terms and models of the domain so that they can make the most out of the SME’s time and answers. This has been a good working model so far.
I go into the office once a month, mainly for the RSE lunches. I have worked at WEHI for over 3 years now and have had an in-person meeting with my supervisor once. I am basically a remote worker.
So, to increase the opportunity of in-person meetups, I have tried to get students to meet me in-person as part of the RSE lunches, but there has been little uptake. I tried to organise an in-person tour of the WEHI building last year after some questions from students, but no students responded to the email. There used to be a weekly tour of the WEHI building but this been cancelled since the pandemic.
I also emailed students about an in-person student intern conference that WEHI runs every year where they could present and meet fellow student interns, but no one responded.
To ensure students are aware that this is 100% remote I have updated the website and I have amended the application form to now ask them to confirm that they know that this is a 100% remote internship as appears below:
I recognise that this is a 100% remote role and that all meetings and interactions will be virtual. I also recognise that there are opportunities for in-person events like the monthly Parkville Research Software Engineer lunch.
Finally, I provide resources to the students that help them in every step of the program:
We also have material on how to write a good cover letter and what to look for when you are writing a resume.
We have a page on how to apply for the program.
We have an online FAQ that talks about the top 5 mistakes students make, an explanation on how to deal with a complex and ambiguous project, and how they can be as independent as possible, to name but a few.