Decide on all-remote vs timezone alignment vs co-located cohort
Define the criteria for teams to be able to request an intern slot
Define expected day-to-day activities for interns (skeleton outline)
Outcome
Duration and timing
A priority for the pilot program is attracting promising university students who are nearing graduation. Therefore, we are choosing dates that align with university academic calendars.
The pilot program will be nine weeks starting 2020-06-15 until 2020-08-14.
Location
The internship program will primarily be remote, with two weeks of co-location working.
Week 1: Intern Fast Boot - Amsterdam
The interns will gather in Amsterdam for kick-off and a week of onboarding
Weeks 2-8: Remote internship
Interns will work remotely in their assigned team
Week 9: Intern send-off - San Francisco
The interns will co-locate for their final week in San Francisco to process their experience and socialize with each other
GitLab Contribute Invite
We will extend invites to the interns to attend Contribute in March 2020.
Internship day-to-day activities
Week 1: Intern Fast Boot
The program coordinators and mentors will facilitate a pre-defined program. The aim is to onboard the interns, prepare them for their seven weeks of remote working, and set them up for success.
Weeks 2-8: Remote internship
An intern's daily schedule will generally reflect how GitLab team members work, which is to say we will not impose a rigid schedule.
Interns will be encouraged to favor async communication and to set their own work schedule.
Mentors and program coordinators will provide coaching if an intern needs help in adjusting to remote work.
Interns will participate in the following pre-determined activities
Weekly 1:1 with their manager
Weekly 1:1 with a mentor
Weekly 1:1 with an internship program coordinator
Weekly intern coffee chat
2-3 group meetings per week moderated by the program coordinator.
Regular pair programming sessions with a mentor and other team members.
Week 9: Intern send-off
The program coordinators and mentors will facilitate a pre-defined program. The aim is to process the experience, gather feedback, and share learnings.
@lmcnally1 what are your thoughts regarding all-remote vs timezone alignment vs co-located?
@edjdev made the argument that an all-remote internship for a university student might not feel that exciting or impactful if they were just staying in their dorm or at their parents' house for the summer.
On the other hand, requiring interns to co-locate might exclude non-university students such as a recent dev bootcamp grad with a family that they cannot leave for 2-3 months.
I am in favour of the co-location for those that are able too. If there are those that are unable too due to family commitments, we should leave that as an option so we don't exclude candidates.
Other considerations:
Should a remote intern come to a colocated onboarding experience, if so should we cover childcare costs for that week if applicable.
Co-location will have a number of advantages
Opportunity to work together & support each other
Opportunity to have onsite mentors to ensure it is a true learning experience
Maintain focus on the deliverables
Timezone aligned could exclude whole regions of the world
Set up for success properly whilst getting a true gitlab experience
Disadvantages
Higher cost
Logistics
Liability for the property - may need to have a Manager level employee on site throughout
Remote interns may feel left out - have to create process for this
Tourist Visa length for the location (have to consider where would make the most sense)
Thanks, @lmcnally1. That all makes a lot of sense.
If we go with co-located, I like the idea of having a remote option and a process to make sure remote interns feel included. In that scenario, we probably want to consider how many co-located interns we would want in order to make co-location worthwhile. For example, if we accept 10 interns, it doesn't seem ideal for only 3 of them to be co-located while 7 are remote.
Agreed, I think if we go with co-located as a default and then caveat this with we will accept applications for people who require remote internships. We are then setting the expectation for those who do not require to be remote that it will be co-located.
Legal thing to note though:
Let's not ask people the reasons why they require the internship to be remote. Only if they require it to be remote.
I'm not as big of a fan of the co-location setup because it isn't aligned with how our company operates. We operate as an all remote company but we are experimenting with an in person internship program. If we are truly wanting these candidates to experience what it is like working at GitLab, we are creating a false expectation that they would be able to be in the same location as their coworkers.
Instead of this, I would like to propose we leave it all remote and have an intern version of a GitLab contribute. This would give them more insights into our company culture, how we work async and effectively in an all remote environment and experience what it's like being together for a short time window (like we all experience as non-intern team members).
I think this would also be a more effective use of costs imo.
I'm also concerned about finding mentors or a GitLab employee who would want to commit to being on-site consistently for 2-3 months to support the interns. The "intern fast boot" would be much easier to sell in terms of a time commitment for mentors and program managers.
What about 2 in-person intern meetups? One to kick off the program and one at the end to connect in person and process the experience?
I was thinking rotational mentors 1-2 weeks at a time and then 1-2 on site program managers for the entire program, they would be volunteers. I think we could get 2 volunteers, I for one would be happy to volunteer as a program manager.
Remote could work, my previous experience tells me that having it onsite brings in high calibre candidates due to a more personal experience and better results, which is why I am more supportive of an on-site internship. BUT no other business does remote like Gitlab so we have that in our favour.
Starting a thread to discuss program duration and timing.
I think we can use summer and 2-3 months as a starting place since we want to accommodate university student schedules. As @rtakken mentions in https://gitlab.com/gitlab-com/www-gitlab-com/issues/5526, we probably want 90 day max to align with most tourist visas.
Something like a June 8th start and August 14th end feels like it would accommodate most US school schedules. As this is a US university specific perspective, we should consider which groups of people this schedule would not be ideal for.
In response to #5529 (comment 230824867), my vote would be to define a start and end date for all interns and adjust on a case-by-case basis if needed.
APAC usually have there longest break December to February, that said they do have 2-3 months over the APAC winter months too, depending on what year they are in at University. They also have credit programs for internships so they can take an internship as part of the course.
June 8th might be early for EMEA students, but they start the new semester in the last week of August.
A lot of students are using the Summer to finish writing their thesis. However if they have to take a resit, we could be flexible around that. As well as focussing not solely on students of course.
Making sure our program would qualify for credits would be great, and for EMEA is relatively easy.
Could we start by creating an interest form and advertise it between now and november? We can use it to collect emails, target dates and some general information that could help us with planning.
The way we are operating right now assumes that our primary demographic is college students. I'm concerned that as we start making decisions on dates..etc, we are potentially alienating potential interns from non traditional backgrounds (eg. not college students). Just wanted to note that here.
It is quite likely that college students is our demographic but I wanted us to be sure before we make decisions that make it difficult for non college students to participate in
Should the team have a clear idea of the projects that an intern would be working on?
I think a roadmap that includes a quantity of issues with low weight and few dependencies, that have milestones assigned, is most likely to set an intern up for success in the beginning. Particularly if they are remote.
Do we want to restrict it to teams that are fully staffed and not hiring for more than X openings?
What's the process for requesting an intern?
It wouldn't be uncommon for it to take 90 days for a new IC to really start performing in the role. Therefore, there's an element of risk for a team taking on an intern that velocity would decrease for the duration of the internship. With that in mind perhaps larger teams in more mature stages or groups would have a higher chance of success.
2 Month Program starting Monday June 15, 2020 and ending Friday August 14, 2020
We want to make this program available to anyone who is ready to begin a career in software development. A priority for the pilot program is attracting promising university students who are nearing graduation. Therefore, we are choosing these dates to better align with university academic calendars.
Location
The internship program will primarily be remote, with two weeks of in-person programming.
Week 1 - Intern "fast boot"
Interns will kick-off the program in person. Amsterdam is the proposed location as it is home to many GitLabbers and is an attractive destination to help us promote the program.
1-2 program coordinators will be present to assist with onboarding, support, and to organize intern social events
Mentors will also be onsite to support interns
Final week - Intern send-off
Interns meet for their final week to process their experience and socialize with each other as well as with GitLab coordinators and mentors.
San Francisco is the proposed location. Like Amsterdam, it is an attractive destination that is also home to many GitLab team members. We would also like to arrange for the interns to meet with Sid if possible.
GitLab Contribute Invite
We will extend invites to attend Contribute in March. We don’t expect that all interns will be able to attend and will only plan intern specific events if most are able to attend.
Criteria for Requesting an Intern
We will create a Google Form for teams that wish to request an intern
The form will evaluate the following criteria:
Mentorship:
Does the team have a manager and at least 1-2 engineers who are willing to serve as mentors for the duration of the program?
Do the mentors have previous experience mentoring interns or junior engineers? Previous experience is a nice-to-have, but not a must-have.
Workload:
Does the team have a roadmap containing low weight issues with few dependencies that would be appropriate for an intern to work on?
Team Size and Maturity
How established is this team? Will they be able to take on an intern without risking a decrease in velocity?
There will be a group that evaluates and approves/rejects the requests.
Internship day-to-day activities
Daily activities for intern on-site weeks to be determined
Outside of on-site weeks, an intern’s daily schedule should generally reflect how GitLab team members work, which is to say we should not impose a rigid schedule. Interns will be encouraged to favor async communication and to set their own work schedule. Mentors and program coordinators will provide coaching if an intern needs help adjusting to remote work.
Interns will have a weekly 1:1 with their manager
Intern specific activities
Weekly 1:1 with a mentor
Weekly 1:1 with an internship program coordinator
Weekly intern coffee chat
2-3 group meetings per week moderated by the internship coordinator, rotating in timezone assuming we have people in more than one timezone.
Regular pair programming sessions with mentor and other team members.
Regular pair programming sessions with mentor and other team members. (Not required but recommended)
I think this is a great idea. I recently chatted with an engineering manager who used this approach to help onboard new team members and it seems to be a very effective way of helping them get comfortable, up to speed and productive. I think we might want to consider this as more than an optional recommendation.
Do the mentors have previous experience mentoring interns or junior engineers? Previous experience is a nice-to-have, but not a must-have.
A few people have added mentorship to their expertise in team.yml but more mention it in their story. We could encourage people involved in internships to add this so there's a list of people the interns can turn to for help during the programme.
Does this affect where, geographically, we'll be able to extend the programme? For example, the cost of locating interns from the US, EU and APAC in one place could outstrip the cost of salaries for the programme.
Of course it may simply affect where we hold the co-location.
When we're hiring for GitLab we say we're not location agonostic, so personally I think it's fine if it applies in this case too.
I recently chatted with an engineering manager who used this approach to help onboard new team members and it seems to be a very effective way of helping them get comfortable, up to speed and productive. I think we might want to consider this as more than an optional recommendation.
Thanks @jeanduplessis. Updating the draft to remove the optional recommendation
Does this affect where, geographically, we'll be able to extend the programme? For example, the cost of locating interns from the US, EU and APAC in one place could outstrip the cost of salaries for the programme.
Good point @johnhope. I'll make a note for further discussion on this as the decision on co-located events and budget may affect where we can recruit from.
Looks good if we are going with a remote internship, I do still think if the target is University Students, this is not the best option when they are weighing up other internships.
With a remote internship, I would suggest 2-3 group meetings per week moderated by the internship coordinator, rotating in timezone assuming we have people in more than one timezone.
This should be a high touch process, with plenty of opportunities to voice issues, concerns etc. Whilst we have a very different leadership style at Gitlab than what this will be, it needs to be high touch as this will likely be the first or second time in the corporate world, let alone remote working.
Looks good if we are going with a remote internship, I do still think if the target is University Students, this is not the best option when they are weighing up other internships.
If our goal is to find students who have high potential to become full-time GitLab team members after the internship, it might be good to filter for the students who are specifically interested in a remote internship even if it risks decreasing the applicant pool.
I would suggest 2-3 group meetings per week moderated by the internship coordinator, rotating in timezone assuming we have people in more than one timezone.
I've made a start on the Google Form to request an intern & welcome any comments.
I've tried to keep it as simple as possible. I'm assuming that the person filling out the form will be the EM or Dir Eng of the team requesting the intern. I've asked them to name a mentor in the request in order to encourage those conversations to happen early.
@nhxnguyen We're not expecting the on-team mentors to be available for the Amsterdam/SF meetings are we? We'll ask people in those locations to help?
@johnhope thank you for getting this started. A couple of points of feedback on the form:
Can we replace For more information on the programme structure and timeline, please consult issues under the wg-internship-pilot label: https://gitlab.com/gitlab-com/www-gitlab-com/issues?label_name%5B%5D=wg-internship-pilot with For more information on the program structure and timeline, please consult the [Engineering Internship](https://about.gitlab.com/handbook/engineering/internship/) page in the handbook (this link will be available once !33589 (diffs) is merged)
Rename Discipline Required -> Discipline able to accommodate since they will need issues for an intern to work in the specified discipline. Maybe add a hint to that question to say that they should have appropriate issues for the discipline they select.
We're not expecting the on-team mentors to be available for the Amsterdam/SF meetings are we? We'll ask people in those locations to help?
I would imagine that if the on-team mentors are within reasonable travel distance, willing and able to make it that it would be preferred for them to be present, however, we will find other mentors for the co-located weeks if not. So yes, no requirement for them to have to be there.
Thanks @johnhope. Looks good to me with Jean's feedback incorporated.
I'm assuming that the person filling out the form will be the EM or Dir Eng of the team requesting the intern.
Do we want to specify on the form that the person filling it out should be an EM or Director? I assume we will mention this in our announcement about the program and request form. But might not hurt to also mention in the form description.
@nhxnguyen Good idea. Swapped If you would like to request that an intern join your team for that period, please fill out this form. with This form is intended for Engineering Managers and Directors who would like to request an intern for their team.
@jeanduplessis@nhxnguyen Since @rtakken will announce the internship pilot at the company call and the handbook pages are live (and link the form), I've removed draft from the title and added everyone in the WG as an editor.