How a final year project viva runs
The panel is usually three people: your guide, an internal examiner from the department and an external examiner from another college or from industry, appointed by the university. The team gets fifteen to thirty minutes: a presentation of eight to twelve slides, a live demo, and then questions to each member in turn. The external's marks usually dominate the final-semester project grade, and the split between report, presentation, demo, viva and individual contribution is set by your university's scheme, which you should read before you build the slides.
- 1
Opening (one minute)
Team introduces itself, names the guide, states the project title and the one-sentence problem. The person speaking first should be the most confident, not the team leader by default.
- 2
Presentation (six to eight minutes)
Problem, existing solutions and their gap, your approach, architecture, implementation highlights, results, limitations, future scope. Each member presents the part they built.
- 3
Demo (five to ten minutes)
The live run of the thing you built, on the happy path, with one planned error case. The external often interrupts here with 'what if I enter this?'
- 4
Questions (ten to fifteen minutes)
The external asks the thirty questions below in some order, directing specific ones to specific members. The guide stays mostly silent; a guide who answers for you costs you marks.
Why this topic, novelty and the literature gap (questions 1 to 8)
1. Why did you choose this topic?
We chose crop disease detection from leaf images because two of us come from farming families in Nashik and had watched a grape crop lost to late blight that a timely diagnosis could have saved. We wanted a problem where a working prototype would matter to someone we could name, and where a mobile camera was the only hardware the user needed. Our guide confirmed that the dataset and the deep learning tools were within reach for a four-month project.
Personal reason, real user, feasibility, in that order. Never say 'our guide gave it to us'.
Say this answer out loud2. What problem does your project solve, in one sentence?
A grape farmer photographs a leaf on a basic Android phone and gets, within three seconds and without internet, a diagnosis of the three commonest fungal diseases and the recommended action, with about 92 per cent accuracy on our held-out test set.
User, input, output, constraint, number. If you cannot say it in one sentence, the panel assumes you do not know what you built.
Say this answer out loud3. What is new in your project? Hundreds of leaf-disease apps exist.
The novelty is not the classifier; it is that ours runs offline on a 2 GB phone, because we quantised a MobileNetV2 model to under 4 MB and tested it on photographs taken in Nashik field light rather than on the lab-quality PlantVillage images every published app trains on. On our field set, two existing open-source apps dropped to about 60 per cent accuracy; ours stayed above 85.
Say what is not new first; the panel respects honesty, and it makes your real contribution stand out.
Say this answer out loud4. What gap in the literature did you find?
We reviewed 22 papers from 2018 to 2025. Almost all reported accuracy on PlantVillage, which has uniform backgrounds and lighting, and only three tested on field images; none of those three addressed on-device inference. The gap we targeted was the combination: field-image robustness and offline deployment for low-end phones.
Number of papers, the pattern you saw, the gap in one line. Have the three papers' author names ready.
Say this answer out loud5. Which existing solution is closest to yours, and how are you different?
The closest is Plantix, a commercial app with a much larger disease coverage. It needs internet and sends the image to a server, which fails in the field areas we tested where 2G is the norm. We cover three diseases instead of hundreds, but we do it offline, in Marathi, and we show the confidence so the farmer knows when to ask an expert.
Name a real competitor. Admit where it is better. State your difference as a trade-off, not a victory.
Say this answer out loud6. Why did you choose this method over the alternatives?
We tried three approaches on the same data split: a hand-crafted colour and texture feature set with an SVM, a ResNet-50 fine-tuned model and MobileNetV2. The SVM reached 78 per cent; ResNet reached 94 per cent but was 98 MB and took eleven seconds on the test phone; MobileNetV2 gave 92 per cent at under 4 MB and two seconds. We chose the method that met the user's constraint, not the highest number.
Comparison, numbers, the constraint that decided it. 'Because it is popular' is an answer that loses marks.
Say this answer out loud7. Who is the user and did you talk to any?
The user is a smallholder grape farmer with a basic Android phone. We spoke to nine farmers in two villages near Nashik in August, showed them a paper prototype, and learned two things that changed the design: they wanted the result in Marathi, and they did not trust a result without a photo of what the disease should look like for comparison. Both are in the final app.
A number of users, where, when, and one design change that came from them. This single answer separates projects from assignments.
Say this answer out loud8. What were your objectives, and did you meet all of them?
We set four objectives: a field-image dataset of at least 1,500 labelled photos, a classifier above 85 per cent on field images, offline inference under three seconds on a 2 GB phone, and a Marathi interface tested with farmers. We met the first three. The Marathi interface is built, but we tested it with only four farmers instead of the ten we planned, because of the harvest season; that is listed as a limitation.
Objectives as a numbered list, a clear met or not met for each. Admit the miss before the panel finds it.
Say this answer out loudMethodology, dataset and implementation (questions 9 to 17)
9. Walk me through your methodology.
Five stages. Data collection: 1,640 leaf photos from six farms, labelled with a plant pathologist from the KVK. Preprocessing: resizing, augmentation with rotation and brightness changes to simulate field conditions. Model: MobileNetV2 pre-trained on ImageNet, fine-tuned for four classes. Evaluation: stratified 70-15-15 split, accuracy, per-class recall and a confusion matrix. Deployment: TensorFlow Lite with 8-bit quantisation inside an Android app in Kotlin.
Stages, in order, one sentence each, with one number per stage. This is the answer you should be able to say in your sleep.
Say this answer out loud10. Where did your dataset come from, and how was it labelled?
We collected 1,640 images ourselves between July and September on six farms, with permission from the farmers, and added 2,000 PlantVillage images for the healthy class. Labels for the field images were given by a plant pathologist at the Krishi Vigyan Kendra, Nashik, who checked each photo; 112 images she was unsure about were removed. The dataset split is by farm, so no farm appears in both training and test sets.
If you used a public dataset, say its name, size, licence and exactly what you added. 'From Kaggle' alone is not an answer.
Say this answer out loud11. Why is your test set trustworthy? Could the model be memorising?
Three safeguards. The split is by farm, so test images come from fields the model never saw. We held the test set out from the start and ran it exactly once, after all tuning was done on the validation set. And we checked for near-duplicate photos with perceptual hashing and removed 38 pairs that straddled the split. Without the farm-wise split, accuracy was 97 per cent, which was the first sign of leakage.
The 'leakage' story shows the panel you found and fixed a real problem. Tell it even if not asked.
Say this answer out loud12. What are the inputs and outputs of your system?
The input is a single JPEG from the phone camera, resized to 224 by 224. The output is one of four classes, healthy, downy mildew, powdery mildew or anthracnose, with a confidence score, a reference image of that disease and a recommended action in Marathi and English. If the confidence is below 60 per cent, the app says 'unsure, consult an expert' rather than guessing.
The 'unsure' behaviour is a design decision; name it as one.
Say this answer out loud13. Which technologies did you use and why?
Python with TensorFlow and Keras for training, because of the pre-trained models and the direct export to TensorFlow Lite; Kotlin for the Android app, because the TensorFlow Lite support library is best documented there; SQLite on the phone to store the diagnosis history; and GitHub with a branch per member for version control. We considered Flutter but dropped it because camera access on older phones was unreliable in our tests.
One reason per technology and one you rejected. 'Because we knew it' is acceptable for one item, not all.
Say this answer out loud14. Explain your architecture diagram.
There are three layers. The camera and user interface layer captures the image and shows results. The inference layer loads the quantised model and runs it on the device CPU, returning class probabilities. The data layer keeps the diagnosis history and the reference images locally. There is no server; the only network call is an optional weekly check for a newer model file. The arrow from the inference layer back to the UI carries the confidence, which drives the 'unsure' screen.
Point at each box as you name it. The examiner is checking you drew the diagram, not copied it.
Say this answer out loud15. What was the hardest technical problem and how did you solve it?
Field photos taken in afternoon light had strong shadows, and the model confused shadow edges with the dark lesions of anthracnose. We added brightness and shadow augmentation, collected 200 more afternoon photos, and added a simple check that rejects images where more than 40 per cent of the leaf is below a brightness threshold, asking the user to retake. Anthracnose recall rose from 71 to 89 per cent.
Problem, cause, fix, number. Pick a problem you personally solved.
Say this answer out loud16. Did you follow any software engineering process? How did you test?
We ran two-week sprints with a shared board, a review on every pull request, and a tested main branch. Unit tests cover the preprocessing and the confidence threshold logic, about 60 tests with pytest. The app went through manual test cases for the camera, permissions and offline mode on three phones, and we logged crashes with a free tool during a two-week field pilot with four farmers.
If you did not follow a process, say what you would do differently; do not invent one.
Say this answer out loud17. How long did the project take and how did you plan it?
Sixteen weeks from topic approval. Weeks one to three were the literature review and farmer interviews; four to eight the data collection, which ran in parallel with building the app skeleton; nine to twelve model training and the three-method comparison; thirteen and fourteen integration and the field pilot; the last two weeks the report and this presentation. We slipped by about a week in data collection because of rain.
A Gantt chart on a backup slide answers this question in ten seconds.
Say this answer out loudResults, limitations, future scope and contribution (questions 18 to 30)
18. What are your results, and how do you know they are good?
On the 246-image farm-wise test set we reached 92.3 per cent accuracy, with per-class recall of 95, 93, 90 and 89 per cent. The confusion matrix shows the only serious confusion is between powdery mildew and healthy leaves under dust. The baseline SVM scored 78 per cent on the same split, and the best published field-image result we found reported 88 per cent on a different dataset, so we are competitive but not directly comparable.
Headline number, per-class detail, the baseline, and an honest note on comparability.
Say this answer out loud19. Your accuracy is 92 per cent. What does that mean for a farmer?
It means roughly one in twelve diagnoses is wrong, which is why the app never gives a treatment alone. It shows the confidence, a reference photo, and advises an expert for anything under 60 per cent. For a farmer currently diagnosing by eye, where the agricultural officer we interviewed estimated about 70 per cent accuracy, it is a useful second opinion, not a replacement for one.
Translate every metric into a consequence for the user; it is the question external examiners from industry ask most.
Say this answer out loud20. What are the limitations of your project?
Four. It covers only three diseases of one crop. It was tested in one district, so other lighting and soil colours may reduce accuracy. The farmer usability test had four participants, too few for firm conclusions. And the model cannot detect two diseases on one leaf, because it is a single-label classifier. We list all four in chapter seven of the report.
Numbered, specific, no excuses. A project with no stated limitations is marked as unreflective.
Say this answer out loud21. What would you do differently if you started again?
I would start data collection in the first week rather than the fourth, because the data turned out to be the project, and I would design the split by farm from day one instead of discovering leakage in week ten. I would also build the Marathi interface earlier so that more of the farmer interviews could use the real app.
Two or three concrete changes. This answer shows learning, which is what the project course is actually grading.
Say this answer out loud22. What is the future scope?
Three realistic extensions. Multi-label detection for leaves with more than one disease, which needs a differently labelled dataset. Adding pomegranate and onion, the other two crops in the district, with the KVK's help. And a feedback loop where farmers confirm or correct the diagnosis after an expert visit, so the model can be retrained with field-verified labels. The first two are doable in one more semester.
Future scope should be something you could start on Monday, not 'integrate blockchain and IoT'.
Say this answer out loud23. What exactly was your individual contribution?
I built the data pipeline and trained the models: the collection protocol, the augmentation code, the three-method comparison and the quantisation to TensorFlow Lite. Priya built the Android app and the Marathi interface, Rahul ran the farmer interviews and the field pilot and wrote the evaluation chapter, and we all shared the report. My code is in the training and model folders of the repository, which the panel can see in the commit history.
Your part in one sentence, then the others' parts fairly, then where the evidence is. Vague 'we all did everything' answers fail this question.
Say this answer out loud24. Can you explain this line of code or this formula?
This is the confidence threshold check. The model returns four probabilities from the softmax layer; we take the maximum, and if it is below 0.6 the app returns the 'unsure' state. We chose 0.6 by plotting accuracy against threshold on the validation set: above 0.6, accuracy on the accepted images was 96 per cent while only 11 per cent of images were rejected.
Be ready for any line on your slides and any formula in your report. The external picks the one you look least comfortable with.
Say this answer out loud25. How is your project useful to society or to industry?
Grapes are Nashik's main cash crop, and the KVK officer told us that late diagnosis is the most common reason for fungicide overuse, which raises costs and residue. A free offline second opinion in the farmer's language can shorten the time to the right treatment. For industry, the quantisation and field-image approach applies to any on-device crop or product inspection task.
One real stakeholder's words, one concrete benefit, one transferable idea.
Say this answer out loud26. What did you learn from this project?
Technically, that model accuracy on a clean dataset means very little until the data looks like the real world, and how to quantise and profile a model on a weak phone. Personally, that interviewing users early changes the design more than any paper, and that a shared board and pull-request reviews are the difference between a team and three people in a room.
One technical and one personal lesson; both specific.
Say this answer out loud27. Is your work publishable, or has any part been published?
We presented the field-image comparison as a poster at our college's technical symposium in March, and our guide has suggested submitting a short paper to a national agricultural informatics conference after we expand the dataset. The dataset itself, with the farmers' consent, is being prepared for release on a public repository with a non-commercial licence.
If nothing is published, say what would need to be true for it to be. Do not oversell.
Say this answer out loud28. Did you face any ethical or data privacy issues?
Yes, two. The photos were taken on private farms, so we took written consent from each farmer and recorded no location data beyond the village name. And because the app gives agricultural advice, we show a clear disclaimer, never recommend a specific pesticide brand, and route low-confidence cases to the KVK helpline rather than guessing.
Consent, data minimisation, and the consequence of a wrong output. This question is now standard.
Say this answer out loud29. What was the cost of the project, and could it scale?
Direct cost was under five thousand rupees: travel to the farms and a second-hand test phone. Training ran on free cloud GPU credits. Because inference is on-device, scaling to ten thousand users adds no server cost; the only recurring cost would be updating the model file, which is a 4 MB download. That was a deliberate design choice given who the users are.
Industry externals ask this; answer with numbers and the design decision behind them.
Say this answer out loud30. If I ask you to add a feature right now, what would you add and how?
I would add a 'compare with last week' view, because farmers told us they want to see whether a treated plant is improving. The diagnosis history is already stored in SQLite with timestamps and the photo path, so it needs a new screen that shows the two photos and classes side by side, about two days' work in the app layer and no model change.
Show that you know your own codebase well enough to estimate. That is what this question tests.
Say this answer out loudHow to run the ten-minute demo
- 1
Rehearse the happy path until it is boring
One scripted run, start to finish, that shows the core value in under four minutes: open the app, photograph a prepared leaf, show the diagnosis, open the reference image, show the history. Run it ten times on the exact device and network you will use in the room.
- 2
Plan one error case
Show what happens with bad input: a blurred photo, an empty form, an invalid login. Panels trust systems that fail gracefully more than systems that only work.
- 3
Pre-load everything
Data already in the database, the app already installed, the server already running, logins already saved. Nothing in a demo should be typed from memory that could be pre-filled.
- 4
Keep three fallbacks
A screen-recorded video of the full run, a set of annotated screenshots in the slide deck, and a local copy of the project that does not need the college network. Test all three the night before.
- 5
Narrate, do not just click
Say what you are about to do, do it, say what the panel is now seeing. 'I am taking a photo of a leaf with powdery mildew; the app is running the model on the phone; it reports powdery mildew with 91 per cent confidence.' Silence during a demo reads as uncertainty.
- 6
Invite one input from the external
'Would you like to try a leaf yourself?' This is risky only if you have not tested with real inputs. If you have, it is the single most convincing minute of the viva.
Slide structure that survives interruptions
The interruption rule
Externals interrupt around slide three or four. When they do, answer the question fully, then say 'that is on slide eight, I will come back to it' and continue. Never skip ahead; the panel loses the thread and so do you. If the interruption eats your time, drop the implementation slide, never the results or limitations.
How a panel scores a project viva
The exact rubric is in your university's scheme and your department's project handbook, and the weights differ between engineering, computer applications, science and management programmes. The components, however, are nearly universal. This table shows what typical rubrics look for in each; use it to check your preparation, not as your college's official sheet.
What to do when the demo breaks
Demos break in about one viva in four: the college Wi-Fi drops, the projector shows the wrong resolution, a database that was fine at nine is empty at eleven, the phone battery dies. The panel does not mark you on whether it broke; they mark you on the next sixty seconds.
- 1
Say what happened, in one sentence, calmly
'The app cannot reach the database; it looks like the college network has dropped.' Do not apologise repeatedly and do not blame a teammate.
- 2
Try one fix, for no more than thirty seconds
Switch to mobile hotspot, restart the app, reconnect the cable. One attempt, timed. A panel watching you troubleshoot for five minutes is a panel that has stopped listening.
- 3
Switch to the fallback without asking permission
'I will show you the recorded run of the same flow while my teammate restores the connection.' Play the video with the same narration you would have used live. If the connection comes back, finish the live run after the video.
- 4
Turn it into an answer
'This is actually why we moved inference on-device; the diagnosis itself still works offline, as you can see here.' A failure you can explain the architecture around becomes a demonstration of judgement.
- 5
Offer a second look
At the end: 'The system is running now, if the panel would like to see any part live.' Most panels say no; the offer is what they remember.
Defend your project to an AI panel first
The ExamPilot final-year project viva mock puts you in front of an AI examiner for about twelve minutes. You describe your project in two minutes, and the examiner then asks from the thirty questions above in the order a real external would: the problem, the novelty, the data, a line of your reasoning, the results, the limitations and your individual contribution, pushing one level deeper each time you answer well and giving one hint when you stall. It speaks to you the way an external from industry does, interrupts, and closes without revealing marks.
The report gives you a transcript, the questions where your answer lacked a number or a reason, and a tighter rewrite of each. Run it once per team member, because the external questions each of you separately. For lab vivas in the same semester, use the engineering viva questions hub, with subject pages for DBMS, Python and HTML. Postgraduate and research students defending a dissertation should use the thesis defence mock, where the same thirty questions are asked with more statistics. For the presentation itself, the presentation skills course and handling Q and A drill the delivery.
Practise out loud
Defend your project to an AI examiner
A twelve-minute project viva: you describe your project, then an AI external asks why this topic, what is new, your data, results, limitations and your own contribution, with a scored transcript.
Engineering Viva · Final-year project viva
Frequently asked questions
- What questions are asked in a final year project viva?
- Externals ask about nine things in some order: why this topic, what is new, what gap in the literature you found, your methodology, where the data came from and whether the test is trustworthy, the results against a baseline, the limitations, the future scope, and your individual contribution with evidence. Expect one question on a specific line of code or a formula from your slides, and one 'what if' asked during the demo. The thirty questions above cover every one of these.
- How long is a project viva and how many marks does it carry?
- A team usually gets fifteen to thirty minutes with the panel: a presentation of six to eight minutes, a demo of five to ten, and questions to each member. The project is typically the largest single component of the final semester, and the split between report, presentation, demo, viva and individual contribution is set by your university's scheme and your department's project handbook. Read both before you build the slides, because the weights tell you where to spend your preparation time.
- How do I answer 'what is your individual contribution'?
- State your part in one sentence with the specific modules or chapters, state your teammates' parts fairly, and say where the evidence is, usually the commit history or the report's contribution table. Then be ready to go one level deeper on your own module: a design decision, a bug you fixed, a number you measured. Vague answers such as 'we all worked on everything' are marked down, and so is claiming a module you cannot explain when the external opens the code.
- What should I do if the demo fails in the viva?
- Say what happened in one calm sentence, try one fix for no more than thirty seconds, then switch to your fallback, a screen-recorded video or annotated screenshots, with the same narration you planned for the live run. If you can, explain what in your architecture made the failure possible and what still works. Panels mark the sixty seconds after a failure, not the failure itself, so rehearse the switch to the fallback as carefully as the demo.
- How many slides should a final year project presentation have?
- Ten to twelve main slides for a ten-minute presentation: title, problem, existing solutions and gap, objectives, methodology, architecture, implementation highlights, results, a demo title card, limitations, future scope and conclusion, and individual contributions. Keep a backup section with the Gantt chart, dataset details, hyperparameters, extra results and references, so that any question can be answered with a slide rather than from memory.
- What is the difference between a project viva and a thesis defence?
- The questions are the same thirty; the depth and the panel differ. A thesis defence for an M.Tech, MSc, MPhil or PhD is longer, the external has already read and reported on the written thesis, and the questions go further into statistics, validity, novelty against the published literature and your own papers. The undergraduate viva weighs the working demo and the team's individual contributions more heavily.
- How can I practise the project viva out loud?
- Run a full mock in front of your guide or a senior who has not seen the project, with a hard ten-minute limit and interruptions. Then run the ExamPilot project viva mock, where an AI examiner asks the thirty questions in a realistic order, challenges your numbers, and scores your problem statement, novelty, trade-offs, ownership and composure with a transcript. Each team member should do it separately, because the external questions each of you separately.