In this guide
The viva is not a quiz about your project — it is a defence of your thinking. Examiners already know what you built; your report and presentation deck told them. What they want to find out in the room is whether you understand why it is built that way. Prepare for that, and the viva becomes a conversation. Prepare only for "what," and it becomes an interrogation.
What examiners are actually testing
Strip away the formalities and every viva question is one of three:
- Why did you choose this? — the reasoning behind your approach, components, and methods.
- Do you understand what you built? — can you explain it without reading, including the parts that failed.
- Are the results honest? — do your claims match your evidence, and do you know the limits?
Notice that "list your features" isn't on there. Students who prepare a tour of features get blindsided by the first "why." Students who prepare the reasoning behind each decision handle nearly every question, because most questions are just that reasoning asked from a different angle.
Prepare the "why" behind every decision
Go through your project and write one honest sentence for each major choice:
- Why this microcontroller and not the cheaper alternative?
- Why this sensor — what did you compare it against?
- Why this communication method (Wi-Fi, Bluetooth, LoRa) for your use case?
- Why this approach instead of the obvious simpler one?
For each, know the alternative you rejected and the reason — cost, availability, power, accuracy, your own familiarity. "We compared X and Y; X won because…" is the single most viva-proof sentence in existence. If you genuinely can't justify a choice ("it was in the lab"), say so and say what you'd choose with a free hand — honesty about constraints beats invented justifications, which examiners detect instantly.
Tip: Do a mock viva with a friend playing a sceptical examiner — someone who asks "why?" after every answer, three levels deep. The questions that stump you in the mock are exactly the ones to prepare before the real thing.
Defending parts your teammates built
In a group project, examiners deliberately ask you about someone else's component. "I didn't do that part" is the worst possible answer — it suggests you never understood your own system. The fix: each member learns every component well enough to explain its design and purpose, even if only the owner knows the implementation details. Before the viva, have each owner give the team a 10-minute walkthrough of their component: what it does, why it's designed that way, and what went wrong during the build. You don't need to debug their code — you need to tell its story.
When the live demo fails
Demos fail. Power supplies die, Wi-Fi drops, sensors drift the moment an examiner leans in. What matters is not that it failed but how you handle it:
- Stay calm and narrate. Say what the demo was meant to show and what you expected to see.
- Switch to the recorded backup. This is why you recorded a full working demo video beforehand — play it, pointing out each stage as it runs.
- Diagnose briefly, don't debug live. A 30-second "this looks like the sensor warm-up issue we saw during testing" shows understanding; ten minutes of frantic rewiring shows panic.
- Offer to retry at the end if time allows, once you've had a moment to think.
Examiners have seen hundreds of demos; a graceful recovery often scores better than a flawless run, because it demonstrates exactly the composure engineers need.
Warning: Never blame the hardware, your teammates, or "the code someone gave me." Excuses signal that you don't own the work. Owning the failure — "we saw this intermittently during testing; here's what we think causes it" — signals the opposite.
Ditch the memorised script
Avoid memorised scripts. A memorised opening sounds confident until the first unexpected question, at which point the speaker freezes — because scripts have no branches. Instead, learn the story cold: the problem, the three key decisions, the results, the limitations. Practice explaining each in different words, out loud, several times. If you can tell the story to a friend over tea without notes, you can tell it to a panel. Bring one page of cue points (numbers, pin names, exact figures) for the details memory garbles under pressure — that's a safety net, not a script.
Prepare your limitations answer word for word
"what are the limitations of your project?" is the most predictable viva question in existence — and the one students answer worst, usually with a panicked "none, sir." Prepare an honest answer in advance: two or three genuine limits, each paired with what would fix it. "Range is limited to about 30 metres indoors; an external antenna or a LoRa module would extend it" turns a weakness into evidence of engineering judgement. This is the spoken version of your limitations slide — have both ready.
Questions to rehearse
| Question | What they're really asking | Strong answer shape |
|---|---|---|
| Why this topic? | Was there real reasoning or did you copy it? | The problem you saw + why existing solutions fell short |
| Why this component? | Did you compare alternatives? | "We compared X and Y; chose X because…" |
| What was the hardest part? | Did you actually build this? | A specific failure, what you tried, what fixed it |
| What would you do with more time? | Do you see the next steps? | One concrete improvement, not "many applications" |
| What are the limitations? | Are you honest about your work? | Two real limits + what would fix each |
| Explain this code/block | Is this your work? | Walk through the logic in your own words |
The final 48 hours
Read your own report once, end to end — examiners will quote it back at you. Charge everything, pack spares, and record that backup demo video. Sleep. A sharp, honest, slightly-nervous student who owns their work will always outscore a polished one reciting lines they don't understand.