The best way to learn about something is by doing it. The best feedback comes directly from working with end-users and the product directly. At GitLab, we have the opportunity to get more direct product feedback and help folks learn more about security at the same time.
For folks interested in learning more about security and/or Product Management, we are offering the opportunity to an internship with the Secure and Govern Product Management team.
Each iteration of the internship will be slightly different, depending on the intern's interests and expertise, the specific projects involved, as well as the mentor. Interns should choose one of the following two internship track options:
All interns will be paired with a mentor. Before starting the internship program, the intern and mentor should have a kickoff call to understand the intern's interest, skills, and availability to then figure out specific goals to drive towards.
General goals of this internship are:
General goals of this internship are:
This program benefits everyone involved in a variety of different ways.
Open source track
Shadow intern track
Open source track
Shadow intern track
Open source track
Shadow intern track
Both
This section provides general guidance on what the internship would look like. It is meant to be demonstrative, not prescriptive, and based on what has worked for past iterations. The mentor and intern are responsible for setting the schedule and deliverables that make sense for them.
At the start of the internship, the mentor and intern should decide what the goals of the internship are. This should include either a hands-on application of a GitLab security tool to some open source project or a specific product task to be accomplished during the allotted time. This is the critical piece that helps the intern learn, provides GitLab good feedback, and that benefits the open source project.
Submit your final list of goals to the section leader for approval. The most effective way to do this is to work with your selected mentor and create an issue.
The majority of the internship should be spent doing, rather than talking about doing. To that end, for the open source track, a big piece of the internship should be spent on working with the open source projects directly, rather than working with GitLab teams. For the shadow intern track, the intern should feel free to join any of the Product Manager's regularly scheduled meetings unless there is a meeting where the PM specifically requests privacy. Shadowing meetings should be secondary; however, to accomplishing the stated goals. Priority should be given to meetings that are directly connected with accomplishing those goals.
At the end of the internship, the intern should produce some sort of content about their time in the program and what they did. This could be a blog, a YouTube video, conference presentation, or anything that is agreed upon. The goal is to be able to share with others about what was done and give the intern something tangible they can point to in the future.
To make the above a bit more concrete, here are some examples of what a four-week long internship might look like.
| Week | Description |
| 1 | Identify OSS projects to work with, scanners to add, and introduce self to the maintainers. |
| 2 | Write MRs to add scanners to the projects. |
| 3 | Continue with MRs to add scanners to the projects. Start addressing vulnerabilities found by the scanners. |
| 4 | Finalize or handoff any open MRs to maintainers. Write blog about experience. |
| Week | Description |
| 1 | Identify a feature to lead through the development process. Become familiar with relevant direction pages, problem/solution validations, and epics/issues/designs. Ensure the designs are finalized, that the requirements are comprehensive and well written, and that the feature is 100% ready for planning breakdown. |
| 2 | Participate in the weekly group meeting and put the feature through the planning breakdown process. Work with engineers throughout the week to answer questions and iterate on the design as they refine their issues. |
| 3 | Work with the PM to identify customers or users who are likely candidates to be early adopters of the new feature. Share the plans with them and solicit their feedback on future improvements that might be made. |
| 4 | Continue to evangelize the upcoming feature. Write the release post item, inform the PMM, and share with any interested customers or SAs. Write blog about experience. |
| Intern | Mentor | Time Period | Type | Write-up |
| @ericrosenberg88 | @stkerr | July 2020 | Internal | Blog post |
| @kkwentus1 | @sam.white | January 18, 2021 - February 19, 2021 | PM Shadow | |
| @jrandazzo | @matt_wilson / @abellucci | January 1, 2023 - February 28, 2023 | PM Shadow |
To apply, please reach out to both Hillary Benson (@hbenson) and the mentor listed below for the open time slot.
| Time frame | Mentor | Track |
| None currently available. If you are interested please comment in the #product Slack channel and tag @hillary |
If you are willing to act as a mentor for the program, you should do a few things:
If you are an open-source project hosted on GitLab.com, we would love to have you work with one of our interns as part of this program! If you're interested, please create an issue and tag us! If you haven't already, consider also applying for our GitLab Open Source Program.
