Find out whether the role is mostly teaching, code or community work
GitLab's developer-relations handbook describes educational content, events, community programs and feedback into product development. An internship may concentrate on only part of that work.
Ask what you would produce most often: sample applications, tutorials, workshops, event coordination or contributor support. Presenting confidently will not replace debugging in a sample-code role, and coding alone will not make a workshop understandable to a newcomer.
Sources[1]
Build one complete developer task
Choose a small task such as turning a local CSV into a chart or adding search to a toy application. Specify the learner's starting knowledge, prerequisites and supported environment. Use public or synthetic data.
Provide installation, a first successful result, one failure-and-recovery example and cleanup instructions. Mention any required account or paid feature before setup begins. The written instructions should work without the recording; viewers should not have to pause a video to find a command.
Example: attendance is not task completion
A fictional workshop has 100 registrations, 60 attendees, 36 people starting the exercise and 24 completing it. Twelve of the same attendees return for another session.
| Measure | Calculation | Result |
|---|---|---|
| Attendance among registrations | 60 / 100 | 60% |
| Completion among attendees | 24 / 60 | 40% |
| Completion among starters | 24 / 36 | 66.7% |
| Return among first-session attendees | 12 / 60 | 20% |
The completion rate is 40% of attendees or about 66.7% of starters. Neither denominator is wrong, but they describe different things. The 12 returns are 20% of the first session's attendees, not evidence of product retention or proof that the workshop caused later use.
The first issue to investigate may be the 24 attendees who never started. Check setup difficulty, time available and audience fit before assuming that more promotion is the answer.
Replace ‘the API is confusing’ with a reproducible observation
Record the intended task, the documented step, the expected result and what happened. For example: ‘The sample payload omitted a required input. The error named an internal field; the learner completed the task only after the instructor supplied the missing input.’
That gives the documentation or engineering team something to investigate. Three complaints about authentication may have three different causes, so retain the context before grouping them. Do not request secrets or private payloads to make a public reproduction.
Show a useful contribution, not an inflated activity count
GitHub's open-source guide describes useful contributions beyond code, including documentation and examples. Read a project's contribution instructions and existing discussion before proposing a change. A tested correction to a problem you encountered is a better sample than many superficial issues.
Show whether the contribution was submitted, accepted or declined, and what you changed after feedback. An independent demo is also valid evidence; it does not need an external project's endorsement.
Package the demo, tutorial and one feedback-to-revision example for your application. Ask whether the opportunity is paid employment, an ambassador program or event work, and confirm its terms. Those arrangements should not be treated as equivalent merely because each uses the word developer.
Sources[2]