A viva is not an interrogation you survive. It is a walkthrough you lead. The students who do well are not the ones who memorised the most answers — they are the ones who can take a panel through their own project in a clear, confident structure, so that most of the questions are already answered before they are asked. This guide is about that skill: walking your own project. For the question bank, see the viva questions panels actually ask — here we cover how to present the whole thing on your own terms.
Structure the two-minute overview
Most vivas open with some version of “so, tell us about your project.” This is the most important two minutes you will get, because it sets the frame for everything after. Do not improvise it. Rehearse it to a fixed shape:
- The problem, in one sentence — concrete, not “in today’s world”
- What you built, in one sentence
- The stack, in one sentence
- The core flow, in two sentences — what happens end to end
- One honest limitation, stated before they find it
That last line does more work than it looks. Naming a limitation yourself signals that you understand the system’s edges, and it quietly steers the panel toward the boundary you chose to discuss rather than one they went looking for. End the overview on it and you have set the agenda.
Narrate the architecture, ER and DFD
At some point you will be asked to explain a diagram — the architecture, the ER diagram, or a data flow diagram. The failure mode here is reading the diagram aloud: “this is the user table, it connects to the orders table.” The panel can see that. What they want is the why.
Narrate a diagram as a story of decisions, not a list of boxes:
- Architecture: trace one request through the system — “the user submits here, the request goes to this service, which writes to this database and returns this.” Movement, not boxes.
- ER diagram: explain why entities are separate and why the relationships are what they are — “orders and users are separate because one user has many orders, so the foreign key lives here.”
- DFD: follow the data, not the screens — where it enters, what transforms it, where it comes to rest.
This only works if the diagrams match the code you submitted. A diagram with seven tables in front of a database with four is the single fastest way to turn a panel hostile. If you are not certain yours line up, fix that before anything else — the report format guide covers which diagrams must agree with the code and why.
Answer “why did you choose X”
Every project attracts a handful of “why did you choose” questions — why this database, why this framework, why this algorithm. The trap is answering with popularity: “because it is the most used.” That invites the follow-up you cannot answer.
Answer with a trade-off instead. A good justification names the alternative and says why yours fit this project: “I used a document database because the records are nested and read far more than they are written; a relational schema would have meant several joins on every read.” You do not need the deepest answer in the room — you need to show you made a choice rather than copied one. Write these two-sentence justifications down while you build, for every real decision, and the viva version is just reading your own reasoning back.
Handle “what would you improve?”
This question is not a trap and it is not asking you to confess failure. It is checking whether you can see your own system clearly. The wrong answers are “nothing, it is complete” (nobody believes it) and a vague “I would add more features.”
Give two or three specific, informed improvements that show you understand the system’s real limits: “caching on this read path because it is the slowest,” “a queue here so this step does not block the response,” “more training data for the class the model currently confuses.” Naming the exact weakness and the exact fix is the most senior thing you can do in a viva. It reads as engineering judgment, which is what the question is actually testing.
What to do when you do not know
You will get a question you cannot answer. This is normal and it is not the disaster it feels like — how you handle it matters more than the gap itself. The one fatal move is bluffing, because panels have heard every bluff and the follow-up exposes it in seconds.
Instead:
- Say what you do know around the edge of the question, so the panel sees the boundary of your understanding rather than a blank.
- Reason out loud toward it — “I have not measured that, but I would expect it to slow down here because…” Working toward an answer earns credit that silence does not.
- If it is a decision you simply did not take, say so plainly and say what you would consider. “I did not implement that; if I did, I would approach it this way” is a strong answer, not a weak one.
A calm, honest “I do not know, but here is how I would find out” leaves a far better impression than a confident wrong answer. Panels are testing judgment as much as knowledge, and admitting a limit cleanly demonstrates exactly the judgment they want to see.
Rehearse it as a walkthrough, not a Q&A
Preparation for most students means reading a list of likely questions the night before. Do that too, but it is the smaller half. The larger half is rehearsing the walkthrough — the two-minute overview, the diagram narration, the justifications — out loud, ideally to another person, until it is smooth. When you can walk your own project confidently, you control the room, and there are simply fewer hostile questions left to be asked.
The reason vivas go wrong is rarely a hard question — it is a project the student did not fully build or fully understand, defended on nerve. If that is where you are, the honest fix is a project built and documented for you and then walked through line by line in daily live sessions, until the overview, the diagrams and the justifications are genuinely yours to give. Every tier ships with the full source code, and seats are capped per college so no two students defend the same submission. Start a custom build, see the AI college assistant for a project with plenty to explain, or read the viva questions guide next.