How to Submit Internship Project Proof for Mentor Review
Submit the deliverable requested by your task, a link the reviewer can open, and a walkthrough when the brief requires one. Explain what works, how to reproduce it, and what you contributed. Open all evidence while signed out before sending it for mentor review.
Match the link to the task brief
Read the task title, deliverable, and required steps before selecting a submission link. A LinkedIn onboarding task needs the public post named in that brief; a code project needs the repository or application evidence requested for that project. A profile page, homepage, or screenshot of a link may not show the required work.
The EdBytes Submit work view lets you choose the milestone and provide a deliverable URL, walkthrough URL, and optional notes. Your task brief determines which evidence is required. If the fields and brief leave you unsure, ask through support before submitting unrelated material.
Test access from outside your account
Open the repository, prototype, report, post, and video in a private browser window. A link that works only because you are signed in is not ready for review. Check file-sharing permissions and open the exact file or page you plan to submit, not merely the folder that contains it.
For a repository, confirm that the default branch contains the completed version and a README with setup instructions. For a hosted application, check that the deployed version matches your source. Use public or properly anonymised examples; removing a password prompt is not a reason to publish confidential data.
Plan a concise walkthrough
When a walkthrough is required, aim for the 2–3 minute format described in the internship guide. Start with the working result, then show the important implementation or process decision. Explain one challenge and how you addressed it. A silent screen recording or a long tour of every file makes the evidence harder to assess.
- Introduce the task and the result you will demonstrate.
- Show the main workflow and an example output.
- Explain your contribution and one implementation decision.
- State any known limitation and where the reviewer can find the source.
Keep the repository, prototype, or report visible enough to relate the explanation to the work. Check the audio and sharing permission after uploading the recording.
Write notes that resolve uncertainty
Use the notes field for the run command, required environment, location of a feature, or a known limitation. Notes should reduce the effort needed to review the project. If you revised an earlier submission, name the feedback item you addressed and point to the changed behaviour.
For example: “Run the documented start command, add a task, then refresh the page to check local storage. I fixed the empty-title validation from the earlier review.” Do not claim that a feature is tested simply because it exists in the source; describe the checks you actually performed.
Example: an evidence note that helps a reviewer
For a browser task, a useful note might be: “Open the demo, add a task and refresh. The repository README explains the run command. The walkthrough demonstrates these actions and the empty-input check.” Adapt that example to your actual work and the evidence fields in your workspace; do not submit those words as proof on their own.
For a lab report, identify the authorised environment and reproduce the observation safely. Display code examples as text: a literal <script> belongs in an escaped code example, not executable report HTML. For design or animation, share a viewable prototype or export plus the process evidence requested in the brief. The overall internship guide explains what happens after submission.
Check these items before sending
- The selected task matches the work in the deliverable.
- Every link opens while signed out.
- The project includes usable setup or viewing instructions.
- The walkthrough is available when required by the brief.
- Sources and assets are credited, and sensitive data is removed.
- The notes identify any limitations or revisions.
After submitting, check the task status in your workspace. If a mentor requests a revision, read the feedback, update the work, and resubmit the evidence requested. A submission is not an approval; the recorded review determines whether the milestone is complete.
EDBYTES