The project viva: what to expect and how to pass

How the viva works, what examiners look for, a demo script, and a checklist.

What the viva is, and what is (and is not) known

Think of it like this

Think of the project viva as a driving test for the app you built. The examiner does not care that a car exists; they want to see that you can drive it, explain what the pedals do, and handle a small surprise ("please turn left here"). In the viva that surprise is usually: "change one thing in your code, right now."

Tip

Be careful about what is official. The official IIT Madras pages for the project courses (BSCS2003P for MAD1, BSCS2006P for MAD2) describe the skills only. They do not publish the viva format, the marking scheme or the deadlines. Everything about levels, marks and rules below comes from student write-ups and summaries, and each point is tagged. For your own term, the project statement and the announcements on the course portal are the only authority: read them before you trust anything here.

Point	What we found	Confidence
The project is checked in a one-to-one viva	IIT Madras BS programme material mentions project vivas	official, general
MAD1 project: a multi-user Flask app (Jinja2 templates, SQLite, Bootstrap/CSS, secure login) that automates a manual task	student write-ups and the "best projects" site	medium
MAD2 project: Flask API + Vue frontend, token authentication, optional Celery/Redis jobs and caching	official course page text, student repos	high for the skills, medium for details
The viva has two levels: you must clear Level 1 to be taken to Level 2	secondary summary of student documents	medium
One summary of a MAD2 orientation session quotes Level 1 as 40 marks and Level 2 as 60 marks, with a roughly 80 percent originality expectation	an automatic video summary, so it may be garbled	low to medium: verify
Viva is scheduled only after you submit; the submission is a one-time upload (a zip, under a size limit)	same orientation summary	medium: verify

What examiners seem to check

From student reports (not official), the questions fall into five families:

Explain your project. What does it do, who are the users, which features are core, how is the code organised?
Explain a piece of your code. "Open this route. What does redirect(url_for(...)) do? Why POST here and not GET?"
Explain the basics behind it. HTTP methods and status codes, sessions vs tokens, what an ORM is, what a template is, what cache means, what RBAC means, how hashing works.
Prove it works. Demo each core feature, with the database visible, with a normal user and an admin.
Change something live. Add a field, change a rule, add a filter, fix a small bug. This is the family that separates people who built the project from people who copied it.

The idea

The one rule that decides everything: ownership. You will be judged on whether the project is yours. If you can explain every file, every route and every table without opening the editor first, you will pass the "explain" questions. If you can add a small feature in five minutes, you will pass the "live" questions.

Your two-minute project story (fill in the blanks)

Practise saying this out loud until it is smooth. Do not read it.

My project is <name>. It helps <who> to <do what>.
There are <n> kinds of users: <admin / creator / user> and each can <...>.
The stack is Flask for the backend, <Jinja2 + Bootstrap | Vue> for the frontend, SQLite with <SQLAlchemy> for data.
The main tables are <A>, <B> and <C>; <A> has many <B> (one-to-many), and <B> and <C> are many-to-many through <link table>.
Login works by <session cookie | token>. Passwords are stored as <hashes>, never as plain text.
The hardest part was <problem> and I solved it by <idea>.
Extra features: <search / charts / CSV export / daily reminder / caching>.

The five-minute demo script

Start the app from a clean terminal (virtual environment, one command). It should start with no errors and create the database by itself if it does not exist.
Log in as admin: create something, edit it, delete it. Show that the change is visible in the database (for example with sqlite3 or a DB browser).
Log in as a normal user in a private window: show that the user can do their own tasks and cannot open an admin page by typing its URL.
Show one validation: submit an empty form or a duplicate and show the friendly error.
Show search or filter, then your extra feature.
For MAD2, additionally: show the API with a tool such as the browser network tab or curl, a token in the request header, and the Celery job or cache working (a log line, a CSV file arriving, a repeated request becoming faster).

Checklist before the viva

Your turn: 1. Run through it honestly

Tick each item only if you could demonstrate it right now.

Need a hint?

Anything you cannot demonstrate is a hole that an examiner may find.

Show the full solution

The app starts from a fresh clone with the steps in your README, on a clean virtual environment.
requirements.txt is complete and README has the run steps and the login details for admin and a test user.
Every core feature works with bad input too (empty fields, long text, a quote character, a repeated submit).
A normal user cannot reach admin URLs; every route checks the role on the server (hiding a button is not security).
Passwords are hashed (never stored or printed in plain text); secrets are not hard-coded in files you upload.
You can draw your ER diagram on paper and name every foreign key.
You can say what every file and folder does in one sentence.
You can explain each HTTP method and status code your routes use.
(MAD2) You can explain the token flow: login, token returned, token sent on each request, token checked, token expiry.
(MAD2) You can explain your cache key, its expiry (TTL) and when you invalidate it; and the difference between a scheduled task (beat) and an asynchronous task (a worker started by a request).
You have no copied code you cannot explain. Delete it or learn it.

Five live-change drills (do them on your own project)

Time yourself. Each should take under five minutes. Do not use a chatbot.

Add a new column to one table and show it on the page (and decide how you handle old rows).
Add a filter or search box to a list page.
Make one page admin-only and show what a normal user sees.
Change a validation rule (for example a longer minimum password or no duplicate names) and show the error message.
(MAD2) Add one more API endpoint and call it from the Vue page; or change the cache expiry and show the effect.

Watch out - real exam trap

"It worked yesterday." Run the whole demo on the computer you will use, a day before.
Role checks only in the frontend. An examiner types the admin URL. Always check on the server.
Plain-text passwords or secrets in the code.
No delete rules. Deleting a parent row that has children (a user with bookings, a category with items) crashes or leaves orphans; decide what happens (cascade, block, or soft-delete) and be ready to explain it.
Not knowing your own folder structure.
Learning the answers to the question bank but not your project. The question banks on this site teach the ideas; the examiner will ask them about your code.

How to use this site for the viva

Finish the lessons for the ideas your project uses and do the "Viva: say it out loud" box at the end of each lesson.
Work through the MAD1 question bank and the MAD2 question bank. Open an answer only after you have said yours out loud.
Take two or three mock vivas, then revise the questions you marked "need to revise".
Rehearse your two-minute story, the five-minute demo and the five live-change drills on your own project.