If you are in the final semester of B.Tech or BE in Computer Science, the project viva is the one exam where there is no question bank. Your guide knows your work, but the external examiner is seeing it for the first time, and that person has maybe fifteen minutes to decide whether you built what you claim to have built. That is where most of the nervousness comes from.
The good news is that viva questions follow a pattern. Whether your university is JNTU, Anna University, VTU, AKTU, Mumbai University, or an autonomous college, examiners circle the same seven areas: why you picked the problem, how the system is designed, what tools you used and why, how data is stored, how you tested it, what is new about it, and what you personally did. This guide walks through each area with real questions and answers you can adapt to your own project.
What the Viva Actually Tests?
Students often prepare for the viva like it is a theory exam, revising definitions of OOP, normalisation, and SDLC models. Those come up, but they are not the point. The panel wants to confirm three things: that the project is your own work, that you understand the decisions behind it, and that you can explain a technical system clearly to someone who has not seen it before. A student who built a modest attendance system and can explain every design choice usually scores better than one who downloaded a flashy ML repository and cannot say why the learning rate is 0.001.
It helps to know how marks are split. Evaluation sheets differ by college, but the broad shape is similar. The IIT Madras CSE department, for example, marks the B.Tech project out of 100 with 60 marks for the quality of the work, 20 for the report, and 20 for the presentation and viva. Most state universities use a comparable internal plus external pattern, with the external examiner’s viva carrying anywhere from 20 to 40 percent of the project marks.
Figure 1: Mark distribution on the IIT Madras CSE B.Tech project evaluation sheet. Your college sheet will differ, so ask your guide for the exact split.
| Component | What the examiner looks for | Common mistakes |
| Project work | Working demo, correct outputs, handling of edge cases, code that matches the report | Demo crashes, hard-coded data, features in the report that are not in the code |
| Report | Clear problem statement, proper literature review, diagrams, results with analysis, references in IEEE format | Copied text, missing results section, screenshots without explanation |
| Presentation | Ten to twelve slides, one clear flow, speaker knows every slide | Reading slides, 40 slides for a 10-minute slot, one teammate doing all the talking |
| Viva | Direct answers, honesty about limits, understanding of alternatives | Guessing, blaming the guide or a teammate, saying ‘it is in the code’ without explaining |
Which Questions Come Up Most Often?
The chart below is an indicative split, based on the kind of questions that recur across college vivas, not a measured survey. Use it to budget your preparation time. Implementation and tech stack questions dominate because that is where an examiner can quickly test whether the work is genuinely yours.
Figure 2: Indicative share of viva questions by category. Treat the percentages as a guide for how to divide your preparation, not as fixed data.
Round 1: Problem Statement and Motivation
The viva almost always opens here. The examiner is checking whether you can state the problem in two sentences without reading from a slide. Practise this until it is automatic.
| Question the panel may ask | How to answer it well |
| What problem does your project solve? | State the problem, who faces it, and what happens today without your system. Example: ‘Small clinics in tier-2 cities still maintain paper appointment registers, which leads to double booking. Our system lets a receptionist book, reschedule and send SMS reminders from a single dashboard.’ |
| Why did you choose this topic? | Give one practical reason and one technical reason. Avoid ‘because our guide suggested it’. A good answer connects the topic to something you observed or a technology you wanted to learn deeply. |
| Who are the end users? | Name specific roles, not ‘everyone’. Admin, staff, customer, student. For each, mention one action they perform in the system. |
| What are the objectives of the project? | List three to four measurable objectives. ‘Reduce booking time to under 30 seconds’ is better than ‘make the process efficient’. |
| What is the scope and what is out of scope? | Examiners like this question because it shows maturity. Say clearly what you did not attempt and why, for example payment integration or multi-language support. |
Round 2: Architecture and System Design
Be ready to draw. Most panels will ask you to sketch the architecture on the board or whiteboard, and they will watch whether you draw it confidently or glance at your teammate.
| Question the panel may ask | How to answer it well |
| Explain the architecture of your system. | Walk from the user to the data: client, API or server layer, business logic, database. Name the pattern if there is one, such as MVC, three-tier, or microservices, and say why it fits the project size. |
| Why did you choose this architecture over the alternatives? | Have one alternative ready. ‘We considered a monolith but kept the ML inference as a separate service so it could be retrained without redeploying the web app.’ |
| Show me your ER diagram and data flow diagram. | Know every entity and every arrow on your diagrams. If a Level 1 DFD has a process you cannot explain, remove it from the report before submission. |
| Where does the business logic live and why? | For web projects the expected answer is the service or controller layer, not the database or the UI. Mention why keeping it out of the UI makes testing easier. |
| How does one request travel through the system? | Pick one feature, such as login or placing an order, and trace it end to end: form submit, validation, API call, query, response, UI update. Rehearse this trace aloud. |
| What design patterns did you use? | Only name patterns you actually used. Singleton for a database connection, Observer for notifications, Factory for creating report types. One honest example beats five memorised names. |
Round 3: Technology Stack and Implementation
This is the longest round and the one where examiners test ownership. Expect them to open a random file in your code and ask what it does. If your project is on GitHub, keep the repository public and tidy, because a clean commit history is itself evidence that the work is yours. If you have not used version control before, the GitHub documentation on getting started covers everything from your first commit to branching, and it is worth a weekend before submission.
| Question the panel may ask | How to answer it well |
| Why did you use Python / Java / Node.js for this project? | Tie the language to the project need. Python for ML libraries and fast prototyping, Java for a large multi-module system with strong typing, Node.js for real-time features with WebSockets. Mention one drawback you accepted. |
| Why React / Flutter / Django and not something else? | Name the alternative and the trade-off. ‘Flutter gave us one codebase for Android and iOS; the cost was a larger app size compared to a native Kotlin build.’ |
| Which module did you build yourself? | Answer with a specific module and a specific file or function. ‘I wrote the recommendation module, mainly recommender.py, which computes cosine similarity over user ratings.’ Be ready to open that file. |
| Explain this function. What does this line do? | Read it slowly, explain inputs, processing, and output. If it is library code, say so and explain what the library call does rather than pretending you wrote it. |
| How does authentication work in your project? | Mention hashing (bcrypt or similar), sessions or JWT, and the difference between authentication and authorisation. Never say passwords are stored directly. |
| Which APIs did you use and how did you handle failures? | Name the API, the endpoint, the rate limit if any, and what the user sees when it fails. Examiners probe error handling because student projects often ignore it. |
| What is the time complexity of your main algorithm? | Know the Big O of your core logic, whether it is a search, a sort, a graph traversal, or model inference. If you used a library, know the complexity of the underlying method. |
| How did you deploy the project? | Localhost is acceptable, but a deployed link on Render, Vercel, AWS Free Tier, or a college server earns respect. Know the deployment steps even if your teammate did them. |
Round 4: Database Questions
Even an ML or IoT project usually stores something somewhere, so database basics are fair game for every CSE student.
| Question the panel may ask | How to answer it well |
| Why SQL or NoSQL for this project? | Relational for structured data with relationships and transactions; document stores for flexible, nested data or rapid iteration. Give one concrete field or collection as an example. |
| Explain the tables and their relationships. | Name primary keys, foreign keys, and the cardinality. ‘One student can have many submissions; submission_id is the primary key and student_id is the foreign key.’ |
| Is your database normalised? Up to which normal form? | Most student projects are in 3NF. Be able to point to one table and explain why it satisfies 2NF and 3NF. If you deliberately denormalised for speed, say so. |
| How do you prevent duplicate entries? | Unique constraints, composite keys, and validation at the application layer. Mention both the database-level and code-level checks. |
| How do you prevent SQL injection? | Parameterised queries or an ORM. Show one query from your code that uses placeholders. |
| What indexes did you create and why? | If you created none, say so honestly and explain which column you would index first and why, usually the one used in WHERE clauses most often. |
Round 5: Testing, Debugging and Results
Panels in 2026 ask about testing far more than they did five years ago, partly because placement interviews do. A simple test folder with ten unit tests puts you ahead of most batchmates.
| Question the panel may ask | How to answer it well |
| How did you test the project? | Describe unit tests, integration tests, and manual test cases. Show the test cases table from your report. If you used pytest, JUnit, or Jest, name it. |
| What was the hardest bug and how did you fix it? | Tell a short, true story: the symptom, how you narrowed it down, the root cause, and the fix. This single answer often convinces the examiner the work is yours. |
| What are your results? How did you measure them? | For ML: accuracy, precision, recall, F1, and the dataset split. For software: response time, number of test cases passed, user feedback. Have the numbers memorised. |
| Why is your accuracy 92 percent and not higher? | Discuss dataset size, class imbalance, and the model’s limits. Showing you understand why it is not 99 percent is more impressive than claiming it is. |
| How did you validate that the system works for real users? | Mention a pilot with classmates, a faculty member, or a small business. Even a feedback form from ten users counts. |
Round 6: Literature Review, Novelty and Comparison
This round separates the ‘good’ projects from the ‘excellent’ ones. The examiner wants to know whether you read anything before building, and whether your work adds anything to what already exists.
Reference at least four or five papers in your report, cited properly. Standard sources for CSE projects include IEEE Xplore, the ACM Digital Library, and Google Scholar, and most college libraries give you IEEE Xplore access through the campus network. Read the abstract, methodology, and results of each paper you cite, because examiners sometimes pick one reference from your list and ask what it did.
| Question the panel may ask | How to answer it well |
| What existing systems or papers did you study? | Name two or three and state in one line what each did and what gap it left. ‘Sharma et al. (2023) used an SVM for the same task with 85 percent accuracy on a smaller dataset.’ |
| What is new or different in your project? | Be modest and specific. A new combination of techniques, a dataset for an Indian context, a lower-cost deployment, or a usability improvement all count. Do not claim ‘nobody has done this before’. |
| How does your system compare to the existing solution? | Prepare a comparison table in your slides: feature, existing system, your system. Three or four rows is enough. |
| Why not just use an existing tool like X? | Acknowledge the tool, then explain cost, customisation, data privacy, or learning objectives. ‘Google Forms could collect the data, but we needed role-based access and offline sync.’ |
Round 7: Limitations, Future Scope and Your Role
| Question the panel may ask | How to answer it well |
| What are the limitations of your project? | Name two or three real ones without being defensive. Dataset size, no mobile version, single-language support, no load testing. |
| What would you do differently if you started again? | A thoughtful answer here signals maturity. Mention a design decision you regret and what you would change. |
| What is the future scope? | Keep it realistic and connected to the limitations. ‘Add regional language support using an open-source translation model’ is better than ‘integrate blockchain and AI’. |
| What was your individual contribution? | Every team member should have a clear, non-overlapping answer. Decide this as a team before the viva and make sure it matches the contribution table in your report. |
| What did you learn from this project? | Give one technical learning and one process learning, such as version control discipline or communicating with a non-technical client. |
Domain-Specific Questions to Expect
| Project domain | Questions examiners tend to add |
| Machine learning / AI | Why this algorithm? How did you handle overfitting? What is your train-test split? What is the confusion matrix? Why not a simpler model? Where did the dataset come from and is it licensed? |
| Web application | How do you handle sessions? What happens on concurrent updates? How is the app secured against XSS and CSRF? What is the page load time? Is the site responsive? |
| Mobile app | Why Flutter / React Native / native? How is data cached offline? How are permissions handled? What is the APK size? Have you tested on low-end Android devices? |
| IoT / embedded | Which protocol, MQTT or HTTP, and why? How is sensor data validated? What is the power consumption? How do you handle network drops? Where is data stored and for how long? |
| Blockchain | Why does this need a blockchain at all? Which consensus mechanism? What is the gas cost? How is private data kept off-chain? What happens if a node fails? |
| Cybersecurity | What threat model did you assume? How did you test the detection rate? What are false positives? Is the tool legal to run on third-party systems? |
Mistakes That Cost Marks
| Mistake | Why it hurts | What to do instead |
| Opening the laptop only at viva time | Wrong Python version, missing environment variable, database not running. The demo fails before the first question. | Run the full demo on the viva laptop the previous evening. Keep a screen recording as a backup. |
| Reading slides word for word | Signals that you do not own the content. | Slides carry diagrams and keywords; you carry the explanation. |
| Saying ‘my teammate did that part’ | The panel marks individuals. Not knowing a module is a mark deduction for you, not for your teammate. | Every member should be able to explain the whole system at a high level and their own module in depth. |
| Over-claiming results | One probing question exposes it, and credibility for every other answer drops. | Present actual numbers with their limitations. |
| Arguing with the examiner | Even if you are right, the tone costs you. | Say ‘that is a good point, we had not considered it’ and move on. |
| Report and code that do not match | Examiners cross-check. A feature in the report that is missing in the demo looks like copying. | Do a final pass comparing the modules chapter against the actual codebase. |
A 10-Day Preparation Plan
| Days | Focus | Output by the end |
| Day 1 to 2 | Re-read your own report cover to cover. Note every term, diagram, and number. | A one-page cheat sheet of objectives, architecture, tech stack, and results. |
| Day 3 to 4 | Go through the codebase file by file. Trace one request end to end. | You can explain any file an examiner opens. |
| Day 5 | Revise the fundamentals your project touches: OOP, DBMS, networking, ML basics as relevant. | Short written answers to the theory questions in this guide. |
| Day 6 | Prepare the slide deck: 10 to 12 slides, including a comparison table and a results slide. | Deck reviewed by your guide. |
| Day 7 | Mock viva with a senior or a faculty member who has not seen the project. | A list of questions you stumbled on. |
| Day 8 | Fix the stumbles. Rehearse the opening two-minute summary and the architecture sketch. | Both can be delivered without notes. |
| Day 9 | Full demo run on the actual viva laptop. Record it. | Backup video and a checklist of what to start before the viva. |
| Day 10 | Light revision only. Sleep. | Calm. |
Quick Answers to Common Theory Questions
These short definitional questions are often used as warm-ups or to fill the last two minutes. Keep the answers to one or two sentences and, wherever possible, add ‘in our project we used this for…’.
- SDLC model used and why: most student projects follow an iterative or agile approach because requirements change as the guide gives feedback. Say that, and name the number of iterations.
- Difference between verification and validation: verification checks you built the product right; validation checks you built the right product. Map one of your tests to each.
- Difference between process and thread, if your project uses either: a thread shares memory within a process; relate it to your server handling multiple requests.
- What is an API: a defined contract for one program to talk to another. Name one endpoint of your own, with its method and response.
- What is normalisation: organising tables to reduce redundancy. Point to a table in your schema.
- Difference between HTTP and HTTPS, GET and POST, cookies and sessions: know these cold if you built anything with a browser.
- What is a confusion matrix, precision, recall: mandatory for ML projects, and increasingly asked even for non-ML projects.
Final Word
The project viva is not an interrogation. Most external examiners are faculty from a neighbouring college who want to see that you learned something and built something real. Walk in with a working demo, a two-minute summary you can deliver without slides, a clear answer to ‘what did you do personally’, and honest answers about the limits of your work. That combination gets you through almost any panel in the country.