Data Engineering Internship 2026
Chapter 7
Project Submission Review
Each activity ends with a presentation to your instructor. This chapter explains how to prepare and what will be assessed.
7.1 Presentation Format
Every project presentation follows this structure. Time yourself beforehand.
| Section | Time | What to cover |
|---|---|---|
| Output demo | 3 min | Show the working output — running pipeline, query results, dashboard, or ERD. |
| Technical approach | 3 min | Explain how you built it. Key design decisions. Any patterns or libraries you used. |
| Challenges | 2 min | What went wrong. How you debugged it. What you learned. |
| Learnings | 2 min | What concept clicked this week. What you would do differently. |
7.2 Pre-Submission Checklist
- Code is committed and pushed to GitHub — instructor can clone and run it
- README explains how to reproduce the output from scratch
- No hardcoded credentials or passwords in the code
- Output is working and accessible (pipeline runs, dashboard loads)
- You can explain every line of code in your submission
- Presentation is timed — under 10 minutes
7.3 What Your Instructor Checks
| Area | What they look for |
|---|---|
| Correctness | Does the output match the requirements? Does the pipeline actually run? |
| Code quality | Modular functions. No 200-line scripts. Meaningful variable names. No copy-paste blocks. |
| Understanding | Can you explain your design decisions? Can you answer follow-up questions? |
| Documentation | README is clear. Code has comments on non-obvious sections. dbt has schema.yml. |
| Professional habits | Clean commit history. No debug print statements left in. Proper .gitignore. |
7.4 Responding to Feedback
- Read every comment before responding.
- If you agree: implement the fix, push, confirm with the instructor.
- If you do not understand: ask "Can you help me understand why this is the better approach?" — not "Why is mine wrong?"
- Feedback is about making you better. Instructors only comment on things they care about.