Most students prepare for a viva by rehearsing what their project does. Panels already know what it does — it is written on the front of your report. What they are testing is whether you built it, and there is a specific set of questions designed to establish that in under five minutes.
Below are the questions that actually get asked, grouped by what each one is really testing. The trick is not memorising answers. It is understanding why the question exists, because panels follow up.
Category 1 — Does this run, and did you run it?
The opening questions. They sound trivial and they are eliminating candidates.
- Show me the project running. Not the presentation — the application.
- Where is this deployed? Can you run it right now on this machine?
- How long does it take to set up from scratch on a fresh system?
- What are the dependencies, and why those versions?
- Show me the database. Open it and show me a real record.
What they are testing: whether you have ever run this outside a screenshot. A student who bought a project cannot usually get it running on an unfamiliar laptop, and panels know it.
Category 2 — Why did you build it this way?
This is where most of the marks live, and where memorised answers collapse. Every one of these has a follow-up.
- Why this database? Why not the other kind?
- Why did you normalise this table — or why did you not?
- Why is this a separate module instead of one file?
- Why this framework? What would break if you had used a different one?
- Why this algorithm? What is its complexity, and does that matter here?
- Where is the business logic — in the frontend or the backend? Why there?
- What happens to this design if you have a hundred thousand records?
How to answer: name the alternative you rejected and why. “I used a relational database because the data has fixed relationships and I need joins across four tables; a document store would have meant duplicating the patient record in every appointment” is a complete answer. “Because it is popular” is not an answer, and the panel will keep going until they find the bottom of your understanding.
Category 3 — What happens when it goes wrong?
The single most under-prepared category, and the easiest to score on because so few students expect it.
- What happens if two users do this at the same time?
- What if I enter a negative number here? Show me.
- What if the network drops halfway through this operation?
- Can I access this page without logging in? Try it.
- What happens if the file I upload is not the format you expect?
- Where are passwords stored, and in what form?
- What is the largest input this can handle before it becomes unusable?
What they are testing: whether you thought past the happy path. If your project handles even two of these gracefully, say so before you are asked — demonstrate the failure and show it being handled. It reframes the entire viva.
Category 4 — Do you understand your own code?
Usually delivered by opening a random file and pointing at a line.
- Explain this function. What does it return, and who calls it?
- What does this line do? Why is it necessary?
- Delete this line — what breaks?
- Where does this variable come from?
- Walk me through what happens between clicking this button and the database changing.
- Which part of this did you find hardest, and why?
That last one is not small talk. A student who built something has an immediate, specific answer with a story attached. A student who did not gives a vague one. Have a real answer ready — a genuine problem you hit and how you got past it.
Category 5 — Machine learning and AI projects
If your project involves a model, add these:
- Where did your dataset come from, and how large is it?
- How did you split training and test data? Why that split?
- What is your accuracy — and why is accuracy the wrong metric here?
- What is overfitting, and how do you know your model is not?
- What does this model get wrong? Show me a case where it fails.
- Could you have solved this without machine learning?
- If this is an LLM project: how do you stop it from making things up?
The strongest possible answer to “what does it get wrong” is a prepared example. Walk in knowing a case where your model fails and be able to explain why. It signals that you evaluated your work rather than celebrating it.
Category 6 — The closing questions
- What would you do differently if you started again?
- What would you add with another three months?
- What did you learn that you did not expect to?
- Is any of this actually useful to anyone? Who would use it?
Have a real, specific answer to the first one. “I would separate the business logic out of the route handlers, because by the end they were doing three things each and testing them was painful” tells a panel more about your ability than the entire demonstration did.
The rule that matters more than any answer
When you do not know, say you do not know — then reason out loud towards an answer. “I have not tested that, but I would expect it to fail here, because nothing validates that input before it reaches the query” will be marked well. Panels are experienced people who have watched hundreds of students bluff, and a confident invention is what turns one question into four.
How to prepare in the week you have left
- Open every file in turn. Say out loud what it does and why it exists. Anything you stumble on is a question you will be asked.
- Break your own project deliberately. Enter bad input, skip the login, disconnect the database. Know what happens.
- Write down the three design decisions you are least sure about. Those are the ones the panel will find.
- Have someone who understands code ask you “why” five times in a row about the same decision. If you reach “I do not know” at level two, that is your weak spot.
That last step is the one students cannot do alone, and it is exactly what the sessions on this site exist for. Every project is built for you and then walked through line by line, ending in a mock viva where these are the questions you get asked — while there is still time to fix the answers.