The project presentation is the second and final part of your project assessment. It is your opportunity to step away from the keyboard, orally explain your workflow, demonstrate your code, and prove that you fully understand your design decisions.
In SDS210, the presentation is not a separate afterthought. Tt is a core component of the project itself. A reproducible repository is vital, but it only holds value if you can confidently articulate what you built, why you built it, and what your results actually mean.
This component accounts for 50% of your final project grade. It consists of a 5-minute presentation followed by a 5-minute Q&A discussion. You will bring your laptop and use your actual code as the visual guide. There are no PowerPoint slides required or expected.
1. The Purpose of the Presentation¶
The presentation allows you to demonstrate something a written report cannot: your genuine fluency with your own workflow. While your Jupyter Notebook proves your code executes, the live presentation reveals whether you can clearly define the spatial problem, justify your technical choices, meaningfully interpret your outputs, and confidently answer questions about your implementation.
Why oral explanation matters: In any professional data science role, writing code is only half the job. You must frequently present your findings to stakeholders, defend your design choices, and openly discuss analytical limitations. This 10-minute session provides a low-stakes environment to practice exactly that.
The Discussion Phase: The 5-minute Q&A is not an interrogation designed to trip you up. It is a professional conversation about a project you know intimately. Assessors will simply ask you to clarify why you chose a specific function, how you handled a certain edge case, or what a specific spatial pattern signifies.
2. Booking Your Slot¶
Presentations are scheduled using this shared Excel sheet, which will be published on Monday, 04 May 2026.
Once the sheet is live, select a single available time slot that fits your schedule. Please book within that week to ensure your appointment with us. The spreadsheet will also indicate the specific room for your presentation. Make sure you know where it is before your time arrives.
If you encounter a severe scheduling emergency, contact the teaching team immediately via the X-Projects channel on Teams.
3. Structuring Your 5 Minutes¶
Five minutes is extremely short. You cannot show every single line of code, nor should you try. Your goal is to construct a clear, coherent storyline that connects your initial spatial question directly to your final output.
We recommend the following structure for your 5-minute pitch:
The Problem (1 min): Hook the audience. What is the core spatial question, and why does it matter?
Data & Workflow (1 min): Briefly state where your data came from and summarize the high-level steps of your analysis.
Key Implementation (1.5 mins): This is the core of your demo. Show the one or two most important code cells, the “engine” of your project (e.g., a complex spatial join, a clever loop, or how you handled missing data).
Results (1 min): Display your final map or chart and interpret what it means.
Reflection (30 sec): Honestly share one major technical challenge you faced or a limitation of your current approach.
This structure helps you stay focused and makes it incredibly easy for the audience to follow the logic of your project.
4. The Live Code Demo¶
Leave PowerPoint behind. You will bring your laptop to the session, open your Jupyter Notebook, and use your running code and active visualizations as your presentation material.
Your project should not just be static screenshots. Be prepared to navigate your repository and show the relevant parts of the workflow live. However, because time is so strictly limited, do not attempt to run your entire notebook live. Have your notebook pre-run and the outputs already loaded on your screen. Running a 3-minute data-download script during a 5-minute presentation will consume your entire slot.
Avoid scrolling rapidly through endless setup cells or dwelling on basic import statements. Jump straight to the most interesting logic and the final visual outputs. Your demo should prove that the workflow is entirely your own and that you know exactly how to navigate it.
Good demo practice
Before your presentation, test whether you can smoothly show the following in under two minutes:
The main notebook structure.
One key code section (your “engine”).
One important visual output.
Your repository or README file.
If you can navigate between these elements smoothly without getting lost, your demo is well prepared.
5. Assessment of the Presentation¶
The presentation counts for 50% of your final project grade. We evaluate how well you can explain and justify your work, not just your public speaking style.
Assessors are looking for a clear explanation of the project question, a logical summary of the workflow, and a focused demo. They want to see confidence when you explain your code and honest reflection regarding any limitations. They will ask themselves: Does the student truly understand the project logic? Are their design choices justified? Does their live demo support their written report?
(Note: If the final project assessment is not passed, students have the opportunity to retake it once at the end of August).
6. Preparation Checklist¶
Good preparation is the best remedy for presentation nerves. Because the session is so short, even small preparation steps make a massive difference.
Tech Check: Ensure your laptop is fully charged, your notebook is pre-run with all maps visible, and your repository link is active. Avoid making last-minute code changes the morning of your presentation that might accidentally break your environment.
Rehearse the Flow: You do not need to memorize a script word-for-word, but you should practice explaining your workflow aloud with a timer. If your practice runs consistently hit 8 minutes, you must cut material.
Anticipate Questions: Prepare short answers for obvious questions: Why did you choose this dataset? Why did you use this specific spatial operation? What was the hardest bug to fix? What would you improve if you had another week?