What demo day is
Demo day is the session at the end of the cohort where each of you spends a few minutes showing the rest of us the project you built. You open it, run it in front of us, say a little about it, and sit back down. If your stomach is fluttering reading this, that is fine. Everybody who has shown their work to other people has felt that. It does not mean you are not ready. It means you care.
I want to walk you through what happens, what to prepare, and what to do if something goes sideways.
How long you have, and what to show first
Each of you gets between three and five minutes. That is shorter than it sounds, so what you show in the first thirty seconds matters more than anything else.
Show the working thing first. Not the code. Your audience are your classmates, and they want to see the program do something. If you built a small app that tracks books you have read, the first thing on screen should be you adding a book. The technical word for this is a demo — a live showing of the software actually working — and the rule of a good demo is that the working version is on screen as fast as possible.
Open everything before your turn starts. Have your project ready to run. Have your terminal open — the text window where you type commands like python myproject.py to start a program. Have the page you want to show already loaded. Three minutes is not enough time to fumble for the right tab.
The shape of a three-minute demo
You do not need to write a speech. You do need a shape so you do not ramble. Four parts, always in this order.
First, one sentence about what your project is. Just one. "It is a program that helps me keep track of the chores in my house." Resist the urge to apologise or explain your whole life story. Then move on.
Second, the live show. Run it. Click through it. Type into it. Pick the one path you are most proud of and show that. You do not have to demo every single feature — in fact, please do not. Pick the best one and show it well.
Third, one limitation. One thing your project cannot do yet, or one thing that is rough. This is not an apology. It is honesty, and honesty makes you look like a real engineer instead of someone pretending. Example: "Right now if you type a date in the wrong format it crashes — I know how to fix it, I just ran out of time."
Fourth, what you would add next. One thing you would build if you had another week. Keep it realistic. "I would add a button to mark a chore as done" is better than "I would turn it into a mobile app with notifications." The small honest answer is more interesting than the big vague one.
What it is, live show, one limitation, what is next. You can practise it in your kitchen tonight in five minutes.
What your README should have
Before your demo, your project needs to be on GitHub with a README. The README is the page that introduces your project on GitHub — the first thing anyone sees when they click on your project's link. It is written in Markdown, a plain-text format with a few small rules for headings and lists. If you have written a WhatsApp message with asterisks around a word to make it bold, you have already written Markdown.
Your README needs four things:
- The name of your project and a one-sentence description.
- How to run it. The actual command someone would type, like
python tracker.py. Pretend the reader has never seen your project before, because they have not. - What it does, in two or three sentences.
- One thing you learned while building it. Be specific. "I learned my code is much easier to read when I split it into small functions" is better than "I learned a lot."
That last bullet is the one most people skim. Do not skim it. It is half of what I look at.
When the live demo fails
It will sometimes fail. The internet will drop. Your terminal will throw an error you have never seen. This happens to every working engineer I know, including me, in front of paying clients. It is not a sign you are bad at this. It is a sign you are doing something real.
Here is the rule that will save you: record a short screen video of your project working the day before, and have it ready in a tab. A screen recording is a video of what is happening on your screen — every laptop can make one. On a Mac, press Shift + Command + 5 and pick "Record". On Windows, press the Windows key + G. Record yourself running the project from start to finish, narrating quietly. Save the file. Keep it ready. If the live version breaks, you say, calmly, "Looks like the live version is being difficult — let me show you the recording instead," and you play it. The room will not even blink. You will look prepared, because you were.
When someone asks a question you cannot answer
After your demo, your classmates and I will ask a couple of questions. Sometimes one will be a question you do not know the answer to. That is normal.
The good way to handle it: say "I am not sure — my best guess is X, but I would have to check." You acknowledge the question, offer your honest best guess, and say you would verify. That answer makes you look thoughtful, not unprepared. The bad ways are pretending you know, making something up, or going quiet. "I do not know yet" is a complete sentence and a perfectly good one.
How feedback works on the day
Right after your demo, I will give you one piece of warm feedback — something you did well — and one piece of useful feedback — something to think about. Your classmates can add to either. The whole round is short, maybe two minutes. We do not pile on. We do not nitpick. You walk away with one thing you are proud of and one thing to chew on.
A few days later I will also send you a short written note privately, summarising what you shipped and two or three concrete next steps.
A word about the nerves
If you are nervous, you are in good company. Every cohort I have run, the people who were most nervous beforehand gave the demos I remember most clearly. The nerves mean the work matters to you. That is the right starting point.
Two small things help. First, do your demo out loud once the night before, even alone in your room. The first time you say the words is always the worst — get that out of the way, so demo day is your second time. Second, drink water. If your mouth goes dry mid-sentence, take a sip. Nobody minds the pause.
Pre-demo-day checklist
The day before your slot, run through this list:
- Project is on GitHub and you can open the link in a private browser window.
- README is filled in with the four things above.
- You have run the project end-to-end at least twice, today, on the machine you will demo from.
- You have a screen recording of the project working, saved and easy to find.
- The font size in your terminal and editor is big enough to read from across a room.
- You have written your one opening sentence on a sticky note next to your laptop.
- A glass of water is nearby.
Closing
Four weeks ago, most of you had never written a line of code. On demo day, you are going to stand up and show a working program that you built with your own hands. That is the thing. Not the polish, not the cleverness — the fact that it exists and that you made it. Walk in proud. I am already proud of you.