How external examiners actually question
There is a pattern to it. The opening question is broad — what is your project about. The second narrows to a component. The third tests whether you understand the fundamentals behind that component. If the third answer is solid, they move on; if it is shaky, they keep going until they find the floor.
This means your goal is not to answer everything perfectly. It is to have a solid floor everywhere, so that wherever they dig, they find understanding rather than memorised phrases.
The eight questions asked in almost every viva
- Explain your project in two minutes. Practise this until it is smooth; it sets the tone for everything after.
- What problem does it solve, and who has that problem?
- Why did you choose this technology over the alternatives?
- Which part did you personally build?
- Show me this feature working. Then show me the code behind it.
- What are the limitations of your system?
- What would you do differently with more time?
- How is this different from what already exists?
Prepare answers at three depths
For each major component, prepare three versions of the explanation. The one-sentence version for the opening. The one-paragraph version with the how. The walkthrough version where you open the file and trace the logic line by line.
Most students prepare only the middle one. The failure happens at the third level, when an examiner says show me — which is exactly why you should rehearse opening your own code and reading it aloud.
Domain-specific questions to expect
| Domain | Questions that come up repeatedly |
|---|---|
| AI / ML | Overfitting, train-test split, why this algorithm, confusion matrix interpretation |
| Full stack | Password storage, JWT contents, SQL injection prevention, normalisation |
| IoT | Why this controller, MQTT versus HTTP, sensor calibration, network failure behaviour |
| Cybersecurity | Symmetric versus asymmetric, key storage, false positive rate, threat model |
| Cloud | IaaS versus PaaS versus SaaS, why serverless, IAM and credentials, cost at scale |
| Blockchain | Why not a database, gas costs, on-chain versus off-chain storage, access control |
| Mobile | State management, offline behaviour, permissions, background execution |
The fundamentals behind your own project
Examiners frequently step down from your project into the theory it rests on. If you used a random forest, expect a question about decision trees. If you used JWT, expect a question about how a signature is verified. If you used MQTT, expect publish-subscribe versus request-response.
Make a list of every non-trivial technology in your project and write two lines on how each one works underneath. That list is your revision sheet, and it is far more useful than re-reading the report.
What to do when you do not know
Say so, immediately and briefly, then give the nearest thing you do know. For example: I have not measured that, but I know it depends on the number of records, and I would test it by loading a larger dataset and timing the query.
That answer demonstrates reasoning, which is what is actually being assessed. Silence, bluffing, or looking at a teammate all cost more marks than a clean admission.
A viva preparation schedule that works
- One week before: list every technology used, write two lines on each
- Five days before: each member explains their module to the rest of the team, who ask questions
- Three days before: rehearse the two-minute project explanation until it needs no notes
- Two days before: open the code and practise walking through the three most important functions
- One day before: prepare the demo environment and rehearse it cold, twice
- On the day: arrive early, set up, and run the demo once before the panel arrives
Presentation habits that help
- Answer to the whole panel, not only to the person who asked.
- Take a breath before answering; a two-second pause reads as thoughtfulness, not hesitation.
- Keep answers to about thirty seconds unless asked to go deeper. Long answers invite interruption.
- Never contradict a teammate in front of the panel. Acknowledge, then add.
- Keep the report and a printed architecture diagram on the table for pointing at.