Mahatma Jyoti Rao Phule University: Preparing a Java Internship Project for Viva Questions

You prepare for a Java internship project viva by being able to defend three things out loud: why you built it the way you did, how your database is structured, and what your project does not do well. Practise with a one-page sheet, rehearse answers in under 90 seconds each, and have a friend score you with a rubric. The sheet and rubric below are built for a 14-day project.

What examiners tend to probe in a Java project viva

Examiners rarely ask you to recite syntax. They test whether you built the thing and understand it. Questions usually fall into five groups:

• Purpose and scope: What problem does it solve, and for whom?
• Design choices: Why this class structure, this collection, this framework or none?
• Data: What tables exist, how they relate, and why.
• Behaviour under stress: What happens with bad input, empty data, or two users at once?
• Honesty about limits: What would you change with another month?

A short project you can explain deeply beats a large one you cannot. Two weeks is enough for a small, coherent application such as a library desk tool, an expense tracker or a student record manager, provided you know every part of it.

A 14-day plan that leaves time for viva preparation

If you join the free two-week online internship from CareerSwami, you get a 14-day window, a free offer letter and a free completion certificate after successful completion. Use that window so the viva is not an afterthought:

The one-page viva preparation sheet for a Java project

Copy this structure into a document and fill every line in your own words. If you cannot fill a line, that is a gap to fix before the viva.

1. Problem statement: two sentences, no jargon.
2. Users and main flows: who uses it and the three most important actions.
3. Architecture in one breath: for example, “console menu calls service classes, which call DAO classes, which use JDBC against a relational database.”
4. Top five design choices: each with the alternative you rejected and why.
5. Schema summary: tables, primary keys, foreign keys, one sentence per relationship.
6. Exception strategy: what you catch, what you let propagate, what the user sees.
7. Known limitations: at least four, stated plainly.
8. What you would do next: two improvements, ranked.
9. Your contribution: exactly which parts you wrote, and which came from tutorials or libraries.

Explaining design choices without sounding rehearsed

Use a three-part pattern: choice, reason, trade-off. It keeps answers short and shows judgement.

• Choice: “I used an ArrayList for the in-memory book list.”
• Reason: “Reads by index and iteration dominate, and the list is small.”
• Trade-off: “Searching by ISBN is linear; a HashMap keyed by ISBN would be faster if the catalogue grew.”

Design questions to practise aloud

• Why did you separate service and data-access classes?
• Where did you use an interface, and what would break if you removed it?
• Why is this field private and that method static?
• Which class has the most responsibilities, and is that a problem?
• Why a checked exception here and an unchecked one there?
• Did you use inheritance or composition anywhere? Why?
• How would you add a new feature without editing five classes?

If you used a framework such as Spring Boot, expect “what does this annotation actually do?” Be ready to explain one or two annotations at the level of “it tells the framework to create and manage this object”, and admit what you have not yet studied.

Explaining your database schema clearly

Draw the ER diagram from memory before the viva. Then be ready for these question types:

• Keys: Which column is the primary key, and is it natural or generated? Why?
• Relationships: One-to-many or many-to-many? How is it represented?
• Normalisation: Is any data duplicated across tables? Was that deliberate?
• Constraints: What is NOT NULL, UNIQUE or a foreign key, and what does the database reject?
• Queries: Can you write the query behind your most important screen?
• Safety: Do you use PreparedStatement, and what attack does it prevent?

Illustrative example: a library desk project, answered in viva style

This example is illustrative. It describes a hypothetical project and was not run or tested.

Suppose your project is a small library desk tool with tables members, books and loans.

members(member_id PK, name, email UNIQUE)
books(book_id PK, title, isbn UNIQUE, copies_available)
loans(loan_id PK, member_id FK, book_id FK, issue_date, due_date, return_date NULL)

Examiner: Why a separate loans table?

Strong answer: “A member can borrow many books and a book is borrowed by many members over time, so it is many-to-many. loans resolves that and also stores facts about each borrowing, like dates. The trade-off is that finding who currently holds a book needs a query where return_date is null.”

Examiner: What are the limitations?

Strong answer: “There is no login, so anyone at the desk can issue books. Fines are not calculated. copies_available is updated in code, so two simultaneous desks could issue the last copy twice; I would use a transaction with a row lock to fix that. Search is by exact title only.”

Notice that the answer names a concrete failure and a concrete fix. That reads as understanding rather than excuse-making.

Writing the known-limitations list honestly

Examiners usually find limitations anyway; naming them first earns credit. Build your list from these prompts:

• Input validation you skipped (negative numbers, blank strings, duplicate entries).
• Missing authentication or role separation.
• Concurrency: what happens with two users?
• Scale: what slows down with 100,000 rows?
• Missing tests: say what you checked by hand and what you did not.
• Hard-coded values such as database credentials or file paths.
• Error messages that expose technical detail to the user.

State each as “limitation, impact, fix”. Avoid vague lines like “UI could be better”.

Mock-viva scoring rubric a friend can use

Ask a friend to sit with the project closed and ask you eight to ten questions drawn from the sheet. They score each row from 0 to 4 (0 = could not answer, 2 = partly correct or hesitant, 4 = clear, correct and with a trade-off). Maximum is 32.

Reading your total

• 26-32: ready; polish delivery only.
• 18-25: revisit the two lowest rows and repeat the mock the next day.
• Below 18: trace your code line by line, redraw the ER diagram and rehearse the walk-through before re-testing.

MJRP University students: how to align this sheet with your department’s viva

The only institution detail available here comes from a Wikipedia excerpt, which is not an official source. It says the university is in Jaipur, Rajasthan, and was established under the Mahatma Jyoti Rao Phoole University Act, 2009. Treat that as background and check the current official version. Note also that the name is spelled “Phoole” in that source, so use the spelling printed on your own university documents.

What this means in practice: nothing in this article tells you how your department evaluates internships or project work. Rules on duration, credits, report format, who sits on the viva panel, and whether an online internship is accepted can differ by programme, scheme year and department. Do not assume that a CareerSwami certificate, which is free and issued after successful completion, will be accepted for any academic requirement. Also remember that CareerSwami is an independent guide and is not affiliated with or approved by the university.

Your viva sheet is still useful in any format, because it covers the questions nearly every technical panel asks. What you need from the university is the format around it.

Verification steps for your viva and internship rules

1. Ask your department coordinator or project guide in writing (email or a signed note) whether an online internship project can be presented at your viva or submitted for your programme.
2. Request the current scheme or syllabus document for your semester and look for the project, internship or industrial-training clause, including evaluation split and report format.
3. Ask who forms the viva panel (internal guide, external examiner) and whether a demo on your own laptop is expected.
4. Check the training and placement cell or department notice board for forms, certificates or formats that must accompany the report.
5. Confirm the submission deadline and the semester break dates with the exam or academic office, so your 14 days fit around them.

Final-day checklist before a Java project viva

• Project runs from a clean start on the machine you will use; database script is ready to re-create tables.
• Printed or digital ER diagram and class diagram within reach.
• Sample data that shows a normal case, an empty case and an error case.
• Your viva sheet reread once; do not memorise scripts.
• Source code backed up and a copy of the report and certificate on a pen drive or cloud folder.
• Two answers prepared for “what would you do differently?”

Frequently Asked Questions

How long should my answer to each viva question be?

Aim for 60 to 90 seconds: a direct answer first, one reason, and one trade-off. Stop and let the examiner ask a follow-up rather than filling silence.

What if I used code from a tutorial or an AI tool?

Say so, and be ready to explain every line you submitted. Examiners usually accept reference material; they penalise code you cannot explain. Mark borrowed sections in comments and in your report.

Do I need to know Spring Boot or Hibernate for the viva?

Only if your project uses them. If it does, explain what the framework does for you and how you would do the same task in plain Java and JDBC. If it does not, plain Java, collections, exceptions and SQL are the priority.

How do I explain a schema I designed quickly in two weeks?

Redraw it from memory, name each primary and foreign key, and state one relationship per table. Then mention one thing you would change, such as adding an index or splitting a table, to show you understand the design critically.

Is it a bad sign to list many limitations?

No. A concrete list of four to six limitations, each with an impact and a fix, signals maturity. Vague or missing limitations is what looks weak.

Can my friend run the mock viva if they do not know Java?

Yes, partly. They can score problem statement, clarity, delivery and ownership using the rubric. For technical rows, ask them to check that your answers match what your sheet says, or invite a senior who knows Java for one session.

Will the internship certificate count for credit at my university?

That cannot be assumed. CareerSwami offers a free offer letter and a free completion certificate after successful completion, but it makes no claim about academic credit. Ask your department in writing whether it will be accepted.

What should I do if I cannot answer a question?

Say what you do know, state your best reasoning, and say you would verify it. Then move on calmly. Bluffing is usually exposed by the next follow-up question.

Related Java & Enterprise Software guides

• Career Point University Students: A Beginner's Route Into Java Web Apps With Servlets and JSP
• Central University of Punjab Students: Combining Research Skills With a Java Internship
• Mahayogi Gorakhnath University: Building a Student Fee Management System as a Java Internship Project
• All Java & Enterprise Software internship guides