How to Prepare for Your FYP Viva and Presentation
The viva is not a test of whether your project worked. It is a test of whether you understand what you built and can reason about its limits.
Prepare for your FYP viva by structuring the talk around five parts: problem, existing approaches, what you built, results, and limitations. Practise out loud with a timer. Expect questions on your dataset, your baseline, why you chose your method, and what your system cannot do. When you do not know something, say so and describe how you would find out rather than guessing.
Students lose marks in vivas for two reasons that have nothing to do with their code. They run out of time describing the problem, and they cannot answer questions about their own evaluation.
Both are fixable in a week, and both are about preparation rather than knowledge.
A structure that survives the time limit
The most common failure is spending six of ten minutes on background. Examiners already know the domain. Spend that time on what you built.
| Part | Share of time | What goes here |
|---|---|---|
| Problem | 1 min | One concrete user and their problem |
| Existing work | 1 to 2 min | What exists and where it falls short |
| Your system | 4 to 5 min | Architecture and the hard component |
| Results | 3 min | The numbers and what they mean |
| Limitations | 1 min | What it cannot do, and next steps |
Reading your slides silently takes three minutes. Speaking them takes eight. Rehearse with a timer at least three times before the real thing, and cut whatever pushes you over. Almost every overrun in a viva traces back to rehearsing silently.
Questions examiners reliably ask
Vivias follow patterns. Prepare answers to these and you will cover most of what comes.
Why did you choose this method over the alternatives?
Answer with a constraint, not a preference. Not because it is popular, but because the deployment target has no GPU, or because the dataset was too small for a larger model. Reasoning under constraints is exactly what examiners want to hear.
What is your baseline?
If you did not use one, this will hurt, so prepare an honest answer. Explain what a reasonable baseline would have been and what you expect the gap to look like. Better: add the baseline before the viva. It is usually a small amount of work and it is often the single highest value addition you can make.
How large was your dataset, and why is that enough?
Know your numbers without looking them up: how many samples, how many classes, how you split them. If the dataset is small, say how you mitigated it, such as cross validation or data augmentation. Do not claim the result generalises beyond your data.
What happens when your system fails?
This tests whether you understand your own system. Describe the failure modes you observed and what the user sees. Acknowledge them plainly. Systems that fail gracefully score better than systems that only work in ideal conditions.
What would you do differently with more time?
Have a specific answer ready, ideally one you have actually thought through. Not more features, but a concrete improvement to the weak point you already identified.
If you cannot remember an accuracy figure, say you will check rather than guessing. Examiners frequently ask follow up questions about stated numbers, and an invented figure unravels immediately. An approximate answer labelled as approximate is fine. A false precise one is not.
Handling the demo
Record your main demo in advance. Live demos fail for reasons that have nothing to do with your work: meeting room wifi, a cold backend, an expired token. A three minute screen recording removes that risk entirely, and you can narrate over it.
Keep a live instance running anyway. If the panel asks to see the real thing, switching over shows confidence. Just make sure the demo account is pre seeded so the first screen is not an empty state.
The last week
Three days out, do a full run through with someone who is not on your project. They will ask the obvious question you stopped noticing. Two days out, freeze the code and take your screenshots and recording on the frozen version, so what you present matches what exists. The day before, check that your figures are readable at projector distance and that every number in your slides matches your report exactly.
On the day, the goal is not to sound clever. It is to sound like someone who understands their own work, including its limits. That is a considerably easier thing to prepare for.
Frequently asked questions
How long should an FYP presentation be?+
Follow your department's limit, which is usually ten to fifteen minutes. Structure it as roughly one minute for the problem, two for existing approaches, four to five for what you built, three for results, and one for limitations and future work. Practise out loud with a timer at least three times, because a presentation that felt fine in your head is usually thirty percent longer when spoken.
What if I do not know the answer to a viva question?+
Say so directly, then describe how you would find out. Examiners respect an honest boundary far more than invented reasoning, because they can tell when you are guessing. A good answer is: I have not tested that, but I would measure it by doing X. That shows judgement, which is what the viva is assessing.
How do I present a project where some features did not work?+
State the limitation and explain what you learned from it. Every real project has unfinished parts, and examiners know this. What they penalise is pretending a broken feature works. Describe what you tried, why it did not work, and what you would do differently. A clear failure analysis often scores better than a feature that was trivially easy.
Should I demo my FYP live or use screenshots?+
Use a recorded video for the main demo and keep a live version ready as a backup. Live demos fail at the worst moment for reasons unrelated to your work: network, login, environment. A short screen recording guarantees the examiners see the working system, and if they ask to see it live you can still switch over.
Start your project on MyUni
Browse notes from Operating Systems, Machine Learning, Computer Vision and more, or publish your own work to the project showcase so the next batch can learn from it.