FYP viva questions and how to answer them
The final year project viva is not a test of whether your project is impressive. It is a test of whether you built it, understand it, and know its limits. Groups that fail the viva usually built something fine and could not explain a decision they made eight months earlier.
Below are the questions that come up in almost every FYP defense in Pakistani CS and SE departments, what the examiner is actually checking, and how to prepare so the answers are ready.
What the panel is really assessing
| They ask about | They are checking |
|---|---|
| Your problem statement | Whether a real need exists, or the project was reverse-engineered from a technology you wanted to use. |
| Design decisions | Whether you chose, or copied. Any answer beginning “because it is popular” loses marks. |
| Individual contribution | Whether all members worked. This is why they separate you and ask each person about the same module. |
| The live demo | Whether the system runs outside your laptop, with data you did not prepare in advance. |
| Limitations | Whether you know your own system. Claiming none is the fastest way to lose the panel. |
| Future work | Whether you understand where the project sits and what a next version would need. |
Questions about the project itself
- Explain your project in two minutes. Have this rehearsed word for word: the user, the problem, what your system does, the result. It is asked first in almost every viva and it sets the tone.
- Why is this a problem worth solving? Name who suffers and what it costs them today. “There was no proper system” is not an answer.
- What already exists, and why is yours different? Name two or three existing systems and one concrete gap each.
- Which objective did you not meet? Answer honestly and say why. A group that names a missed objective and explains the trade-off scores better than one that insists everything was delivered.
- Who used it apart from you? Even five real test users is a strong answer. None is a weak one.
Technical questions you should expect
- Why this technology stack? Prepare a reason per choice that is about the project, not the trend: team familiarity, hosting cost, offline support, library availability.
- Walk me through your database schema. Know every table, every key and why the relationships are the way they are. Be ready to justify any denormalisation.
- What happens when two users do the same thing at once? Concurrency comes up often and few groups prepare for it.
- How do you store passwords? If the answer is plain text, expect the viva to go badly. Hashing with a modern algorithm is the expected answer.
- How does the system handle invalid input? Show validation on both client and server, and be honest if only one exists.
- What happens if the internet drops mid-operation? Even “the transaction fails and the user must retry” is an acceptable answer if you know it.
- Where is it deployed and how do you deploy an update? Running only on a laptop is a common weakness. Know the hosting and the steps.
- Show me the code for this feature. Be able to open the file and read it aloud. Any part nobody in the group can explain will be found.
If your project uses machine learning, add: where the data came from, how you split training and testing, which metric you used and why, and what the model gets wrong. “Ninety eight percent accuracy” with no confusion matrix invites a hard follow-up.
Questions aimed at the group
Examiners separate the contribution question deliberately. Each member should be able to say precisely which modules they wrote and explain one of them in depth, including the parts their teammates built that connect to it.
Agree in advance who answers what, but never let one person answer everything. A panel that hears a single voice for twenty minutes will start asking the quietest member the hardest questions.
Preparing in the last week
- Run the demo on a different machine and network at least twice. Most demo failures are environment failures.
- Record a backup demo video. If the live system fails, you continue instead of stopping.
- Prepare fresh test data. Panels often ask you to enter a new record rather than show a prepared one.
- Re-read your own documentation. Questions come straight from the report, and groups routinely forget what they wrote.
- Write down your three weakest points and prepare an honest answer for each. They will be found; being first to name them changes how they land.
- Do one full rehearsal with a teacher or senior who has not seen the project.
FYP viva questions
How long is an FYP viva?
Usually twenty to forty minutes per group: a short presentation, a live demo, then questions. Departments differ, and the question phase is almost always the longest part.
What happens if the demo fails during the viva?
Stay calm, say what should have happened, and switch to your backup recording. Panels have seen networks fail before. What damages you is freezing or pretending the failure did not occur.
Can one member fail while the rest pass?
Yes. Most departments mark individually as well as by group, which is the point of asking each member about their own modules. Someone who cannot explain any part of the system can fail while their group passes.
Should I admit that something does not work?
Yes, and say what you would do about it. Examiners already know systems have gaps; they are testing whether you know yours. A limitation you name yourself is treated far more generously than one they uncover.
Do they ask questions outside the project?
Often, but anchored to your work: a database concept because of your schema, a security principle because of your login, a software engineering model because of your methodology. Revise the fundamentals your project touches rather than everything.
What should we bring?
A laptop with the system running offline if possible, a backup demo video, the bound documentation, your slides on a drive as well as online, and a charger. Arrive early enough to test the projector.
Related
Viva preparation, including a one-on-one walkthrough of the code so you can defend every part of the system, is part of our FYP development service.
Earlier stages: FYP proposal format, FYP documentation and SRS, and 70 FYP ideas. For the job hunt after: technical interview questions for freshers and internships for computer science students.