A good ten-minute Java demo spends about one minute on the problem, five minutes on a live walkthrough of one working flow, two minutes on design and code, and two minutes on questions and next steps. Plan a recorded or screenshot fallback before you plan the slides, because a demo that depends on one live server will eventually fail at the worst moment.
This guide is written for NorthCap University (NCU) students who finish a 14-day Java internship and must show the work to a faculty member, a mentor, a placement-unit contact or an interview panel. It gives you a minute-by-minute script, a talking-point outline, a fallback plan, a rehearsal checklist and a bank of likely questions.
Why a 14-day Java project needs a narrower demo than you think
Two weeks is short. A realistic Java internship output is one small service or application with a handful of endpoints or screens, a data layer and some tests. Trying to show everything produces a rushed, shallow demo. Showing one flow well produces a confident one.
Pick a single user journey that proves the system works end to end. For a Spring Boot task manager, for instance, that might be: create a task through the API, see it stored in the database, fetch it back, and see a validation error for bad input. Everything else goes into a “what else exists” slide you can mention in ten seconds.
If you are doing the free two-week online Java track from CareerSwami’s free internship, which comes with a free offer letter and a free completion certificate after successful completion, treat the final days as demo preparation. Build the feature set by about day 10 and keep days 11 to 14 for polishing, testing and rehearsal.
The ten-minute Java demo script with minute-by-minute timing
Use this table as your master template. Adjust the content, not the proportions.
| Time | Segment | What you do | What the audience should learn |
|---|---|---|---|
| 0:00–1:00 | Problem and scope | State the problem in one sentence, who the user is, and what you built in 14 days. | Why this exists and how big it is |
| 1:00–2:00 | Architecture at a glance | Show one diagram: client, controller, service, repository, database. | How the pieces fit |
| 2:00–6:30 | Live walkthrough | Run one end-to-end flow, including one failure case. | It works, and it handles bad input |
| 6:30–8:00 | Code and design choices | Open two or three files only: a controller, a service method, a test. | You understand your own code |
| 8:00–8:30 | Limits and next steps | Name two honest gaps and what you would do next. | You can judge your own work |
| 8:30–10:00 | Questions | Answer briefly; offer to show code if asked. | Depth of understanding |
Keep a visible timer on a second screen or a phone placed on the desk. Most overruns happen in the live walkthrough, so set a hard stop at 6:30 and move on even if you have not shown every feature.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
Talking-point outline for each segment of a Java demo
Opening (one minute)
- One sentence on the problem: “Small teams lose track of who owns which task.”
- One sentence on your solution: “I built a REST service in Java with Spring Boot and a relational database that manages tasks and owners.”
- One sentence on the stack: Java version, framework, database, build tool.
- One sentence on the plan: “I will show one flow, then the code behind it.”
Architecture (one minute)
- Show a single labelled diagram, not a wall of boxes.
- Name the layers: controller for HTTP, service for business rules, repository for persistence.
- Mention where validation lives and where exceptions are translated into HTTP responses.
Live walkthrough (four and a half minutes)
- Start from a clean, known state: the app running, the database seeded with two or three records.
- Make a successful request, then show the stored data.
- Make a deliberately invalid request and show the error response.
- Say what you are doing before each click or command, so the audience is never guessing.
Code and design (one and a half minutes)
- Open the controller method behind the request you just made.
- Open the service method and point to one business rule.
- Open one unit test and say what it protects.
- Explain one design choice and its trade-off, such as using DTOs so the database entity is not exposed directly.
Limits and next steps (thirty seconds)
- Name two real gaps, for example no authentication yet and limited test coverage on the repository layer.
- Name the next improvement you would make first and why.
Worked example: scripting a demo of a Java library-book service
This example is illustrative. It describes a plan for a hypothetical project; no code or tests were run for this article.
Suppose your 14-day project is a library-book service built with Java, Spring Boot and an in-memory or local database. Here is how the script might read.
- 0:00 Problem. “Hostel libraries often track book loans on paper. This service lets a librarian add books, issue them to members and see overdue items.”
- 1:00 Diagram. One slide: Postman or browser, BookController, LoanService, BookRepository, database.
- 2:00 Demo flow. Add a book, issue it to member 12, fetch the loan list, then try to issue the same book again. The service should refuse with a clear message and an appropriate HTTP error status.
- 5:30 Edge case. Submit a book with an empty title to show validation.
- 6:30 Code. Open
LoanService.issueBook, point out the availability check, then open the test that covers the double-issue case. - 8:00 Limits. “There is no login yet, and overdue fines are not calculated. Authentication would be my next step.”
Notice what is missing: no tour of every endpoint, no scrolling through configuration files, no apology. The demo proves one rule, shows one failure case and ends with honest next steps.
Fallback plan for when the server, database or network fails
Assume something will break: the port is busy, the database will not connect, the Wi-Fi drops or the laptop projector handshake fails. Build layers of fallback so that you lose seconds, not the whole demo.
| Failure | Quick check (under 30 seconds) | Fallback |
|---|---|---|
| Application will not start | Check the console for “port already in use” or a missing environment value | Start on a second pre-tested port, or switch to the recorded run |
| Database connection error | Is the DB service running? Are credentials in the config correct? | Switch to the in-memory profile (for example H2) prepared for exactly this case |
| Network or hosted server is down | Try opening a local page | Run everything on localhost; keep a deployed link only as a bonus |
| Projector or screen sharing fails | Try another cable or reconnect the share once | Present from exported PDF slides and a screen recording on a pen drive |
| Laptop crashes | Restart once only if time allows | Use a backup copy of the project on a pen drive or cloud folder, and the screen recording on a phone |
What to prepare before the demo day
- A two- to three-minute screen recording of the full flow, saved on your laptop, a pen drive and your phone.
- Screenshots of each key step pasted into the backup slides, with the request and response visible.
- A second Spring profile or configuration that uses an in-memory database and seeded data, so the app starts without external services.
- A short README with the exact start command and the sample requests, so you can recover quickly under pressure.
- A pre-saved collection of requests in Postman or a set of
curlcommands in a text file, so you are not typing during the demo.
How to speak while recovering
Say it plainly: “The database is not connecting, so I will switch to the in-memory profile I prepared for this.” Then act. Evaluators generally respond well to calm troubleshooting, and a candid switch to a recording shows more maturity than silent clicking.
Rehearsal checklist for a ten-minute Java demo
- Run the full script aloud at least three times with a timer, and note where you overrun.
- Do one rehearsal on the actual laptop and the same screen resolution you will use on the day.
- Restart the machine, then start the app from zero using only your README to confirm it works on a clean boot.
- Reset the database to the known seed state before each run.
- Close chat apps, mute notifications and hide personal browser tabs and bookmarks.
- Increase the font size in the IDE and terminal so the back row can read it.
- Check that no passwords, API keys or tokens appear in any file you will open.
- Charge the laptop and carry the charger and any adapter.
- Test the screen recording and the PDF slides on a different device.
- Rehearse once with a friend who interrupts with questions, and once with the server deliberately switched off.
- Write the three most important sentences of your opening on a card and memorise them.
Likely questions after a Java internship demo, with answer strategies
| Likely question | What the questioner wants to know | How to answer |
|---|---|---|
| Why did you choose Spring Boot (or plain Java, or another framework)? | Whether the choice was reasoned | Give one practical reason, such as faster setup and wide use, and one trade-off |
| What happens if two users issue the same book at the same time? | Concurrency awareness | Admit whether it is handled; mention transactions or optimistic locking as the fix |
| How did you validate input? | Basic robustness | Point to annotations or checks in the code and show the error response |
| What does this unit test actually prove? | Whether tests are meaningful | State the behaviour covered and one thing it does not cover |
| Why a DTO instead of returning the entity? | Layer separation | Explain that it avoids exposing internal fields and decouples the API from the schema |
| How would you secure this API? | Awareness of production needs | Mention authentication, authorisation and HTTPS as next steps, without overclaiming |
| What was the hardest bug you fixed? | Real hands-on experience | Tell a short true story: symptom, cause, fix, lesson |
| What would you do with another two weeks? | Prioritisation | Pick two items and justify the order |
| Which parts did you write yourself and which did you adapt? | Honesty about sources | Be exact; name tutorials or libraries you relied on |
| How would this scale to a thousand users? | System thinking | Mention a real database, indexing, caching and stateless services, and say you have not built these yet |
If you do not know an answer, say so, then reason aloud: “I have not implemented that, but I would start by checking how the transaction boundary is set.” This is better than guessing.
NorthCap University and your Java internship demo: what is verified and what to check
NCU was set up as a private university in 2009-10 as ITM University and was rebranded as The NorthCap University in August 2015, according to the Haryana State Higher Education Council’s university profile. Because it is a single university rather than an affiliating one, academic timing is set centrally. The Dean-Academic Affairs memo of 25 June 2026 issues one General Academic Calendar for the odd semester that applies to all programmes. It shows classes ending on 27 November 2026 and even-semester classes beginning on 18 January 2027. With today being 13 November 2026, any demo you plan to give within this semester has a short runway.
On internships, NCU’s placement page says the university has a mandatory credit-based internship with the period set by each course’s academic requirement, and names the School of Professional Attachment as the unit handling placements, summer internships and industry connects. That page gives no credit count, duration or regulation year. The calendar lists a Summer Internship Evaluation window of 22 August to 5 September 2026, which has already passed this year, so check the equivalent window for 2027. The B.Tech Robotics and AI programme page lists summer internships after the 2nd or 3rd year, which shows that programme pages can differ by course.
What is not verified: the evaluation rubric, the required documents, and whether an online internship such as a free two-week programme can be counted toward any university requirement. Treat your demo as a portfolio and interview asset unless your department confirms otherwise.
Verification steps for NCU students before the demo
- Email the School of Professional Attachment and ask in writing whether an online two-week internship can be presented or counted for your programme, and in which semester.
- Ask your department coordinator for the internship scheme or regulation document for your batch, and look for duration, credits, evaluation format and required documents.
- Ask whether the internship evaluation has a prescribed presentation format, time limit or report template, so your ten-minute script matches it.
- Check the student notices page regularly for the Summer Semester Registration form and the next academic calendar.
- If you are in CSE, ask the department whether its industry internship arrangements, mentioned on the Department of CSE page, apply to your situation.
- Keep the replies, and save your offer letter and completion certificate with your project files.
Frequently Asked Questions
How many slides should a ten-minute Java demo have?
Four to six is enough: problem, architecture, a limits-and-next-steps slide, and one or two backup slides with screenshots. The live demo and code walkthrough carry most of the time, so slides should support them rather than replace them.
Should I show code or the running application first?
Show the running application first. Evaluators want proof that it works before they care how. Move to the code once you have shown one successful flow and one failure case.
Is a recorded video acceptable instead of a live demo?
Use a recording as a fallback, not as the plan. A live run shows confidence and lets you respond to questions. If something breaks, say so and switch to the recording quickly.
Can I demo a project I built with help from tutorials?
Yes, but be exact about what you wrote, adapted or copied. Be ready to explain every file you open. Questions about your own design choices are where unfamiliar code is exposed fastest.
Which Java topics should I be ready to explain?
Be ready on whatever your project uses: collections, exception handling, the layered structure, dependency injection, REST basics, JDBC or JPA, and unit testing. Do not claim topics your project does not touch.
What should I do if the demo overruns?
Skip to the limits-and-next-steps segment and offer to show more code during questions. Cutting the walkthrough short is better than losing the closing segment, which shows judgement.
Does the internship demo count for credit at NCU?
The placement page describes a mandatory credit-based internship but gives no details on how external online internships are treated. Confirm in writing with your department or the School of Professional Attachment before assuming anything. The CareerSwami internship offers a free offer letter and completion certificate, not academic credit.
How do I handle a question I cannot answer?
Say you have not done that, explain how you would approach it, and name where you would look. A short reasoned answer is stronger than a confident guess that falls apart on the next question.
Related Java & Enterprise Software guides
- Institute of Advanced Research Students: Ethical Habits for Java Interns Handling Company Data
- XIM University Students: Java Internship Opportunities for Business and Management Majors
- Rama Devi Women's University: Finding and Asking for a Java Internship Mentor
- All Java & Enterprise Software internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Java & Enterprise Software. The internship, the offer letter and the completion certificate are free.