Sharda University Students: Preparing for the Internship Viva on Your Web Project

Sharda University Students: Preparing for the Internship Viva on Your Web Project

Facebook
Twitter
LinkedIn
WhatsApp
Email

To prepare for an internship viva on a web project, learn to explain every layer of what you built (browser, server, database) and to justify each choice with a reason tied to your own code. Examiners rarely want definitions; they want to hear why you chose this approach, what broke, and what you would change. The question bank below is graded from basic to hard, and each answer should follow one repeatable structure.

Why a viva on a web project feels different from a theory exam

A written exam checks whether you remember concepts. A viva checks whether the project is really yours. The examiner picks a file, a route or a table, asks “why is this here?”, and watches how you respond. Students who copied tutorial code tend to stall on the second follow-up question, while students who built even a small app themselves can usually reason their way through.

That is good news if you are doing a short internship. A small project you understand completely beats a large one you cannot explain. If you are running a project through the free two-week online internship from CareerSwami, which includes an offer letter and a completion certificate after successful completion, treat the 14 days as time to build something small and be able to defend it.

What the Sharda syllabi tell you about how internships are assessed

Sharda publishes programme structures on its own domain, and they show that a viva is a formal part of internship assessment, at least for some programmes. The B.Tech IT 2023-27 document lists Summer Internship-I (CSP292) as a compulsory 2-credit course in Semester III, and the B.Tech IT 2023-27 syllabus assesses the summer internship by Jury/Viva, with weightage of CA 25%, MTE 25% and ETE 50%. Half the marks sit in the end-term evaluation, so your final viva matters most.

The same document is a useful reminder that these figures belong to one batch’s scheme. Always check the version that applies to you.

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.

Apply for the free internship

The 14-day plan: build, then rehearse

A viva is won in the preparation days, not in the room. Adapt this plan to your 14-day internship.

Days Focus Output you should have
1-2 Scope a small app (for example a task tracker or notes app with login) One-paragraph problem statement, list of features, rough sketch of pages
3-4 Database design and backend routes Schema diagram, list of endpoints with methods
5-7 Core backend logic, validation, authentication Working API tested with a client such as Postman or the browser
8-10 Frontend, API integration, error states Pages that read and write real data
11 Cleanup, README, deployment or local run notes Repository anyone can run from the README
12 Write your own answers to the question bank below One page of notes per section
13 Mock viva with a friend who picks random files List of questions you stumbled on
14 Fix gaps, re-read your code once, rest A project you can explain without opening notes

A model answer structure that ties every reply to your code

Use the same four steps for any design or code question. It keeps you calm and forces you to refer to something real.

  1. Decision: state what you chose in one sentence (“I used a relational database with a users table and a tasks table”).
  2. Reason: give the reason that applied to your project, not a generic one (“tasks belong to exactly one user, and I needed to query by user”).
  3. Evidence: point to the file, route or table where it lives (“this is in the tasks model and the GET /tasks route”).
  4. Trade-off or next step: name one limit and one improvement (“with more time I would add pagination because this returns every task”).

The fourth step is what separates a strong answer from an average one. Admitting a limit honestly sounds more credible than claiming everything is perfect.

Warm-up viva questions on web basics and your project’s purpose

These should be answered in under a minute each. Fumbling here creates a poor first impression.

  • What problem does your project solve, and who would use it?
  • Walk me through what happens from the moment a user opens your page to the moment data appears.
  • What is the difference between frontend and backend in your project? Which files belong to each?
  • What is an HTTP method? Which ones did you use and where?
  • What does a status code such as 200, 201, 400, 401 or 404 mean, and where does your code return each?
  • What is JSON and why does your frontend use it?
  • Which technologies did you pick, and why those instead of alternatives?
  • How do you run your project locally? What commands and environment settings are needed?
  • What does your folder structure look like and why is it organised that way?
  • What is Git used for in your project? Show or describe your commits.

Intermediate questions on architecture and API design

Here the examiner tests whether you understand the shape of your system.

  • Draw your architecture on paper. Where does the request go first, and what does each layer do?
  • What is REST? Is your API fully RESTful, and where does it bend the rules?
  • Why did you separate routes, controllers and models (or why did you not)?
  • What is middleware? Which middleware does your app use and in what order does it run?
  • How does the frontend talk to the backend? What happens if the server is down?
  • What is CORS and did you run into it? How did you fix it?
  • Where is state stored in your frontend, and why there?
  • How do you handle form validation on the client and on the server? Why both?
  • How does login work in your project: sessions or tokens? What is stored in the browser?
  • How do you keep secrets such as database passwords out of your repository?
  • If two users use the app at once, what could go wrong?

Database choice questions you should be ready to defend

Many students pick a database because a tutorial did. Prepare a reason that fits your data.

  • Why did you choose SQL or NoSQL for this project? What would change if you chose the other?
  • Show your schema or collections. What are the relationships between them?
  • What is a primary key? What is a foreign key or reference in your design?
  • What is normalisation? Is your design normalised, and where did you deliberately deviate?
  • Write the query (or method call) that fetches one user’s records. How would it perform with a million rows?
  • What is an index and which field would you index first?
  • How do you prevent injection attacks in your database queries?
  • How do you store passwords? Why not plain text?
  • What happens to related records if a user is deleted?
  • How would you back up this data or move it to a new server?

Hard questions that probe your own code line by line

These are the questions that expose copied work. Open your code before the viva and be ready to explain any block.

  • Pick any function in your project and explain it line by line. What are its inputs and outputs?
  • Where is the most complicated piece of logic? Why is it complicated?
  • Which bug cost you the most time? How did you find the cause and what was the fix?
  • What happens if the user submits an empty or malformed request to this route?
  • Why is this function asynchronous? What would happen if it were not?
  • Which part of the code would you rewrite first and why?
  • How would you test this feature? What cases would you include besides the happy path?
  • What security weaknesses remain in your app? List three honestly.
  • If traffic grew a hundred times, which part would break first?
  • Which parts did you write yourself, and which came from libraries, documentation or tutorials? Be specific.
  • Add a small feature right now: where would you change the code?

Worked example: answering a database question with the four-step structure

This example is illustrative. The project and details are invented to show the method, and no code has been run.

Suppose your project is a simple expense tracker. The examiner asks: “Why did you choose this database?”

Step Weak answer Strong answer
Decision “Because it is popular.” “I used a relational database with a users table and an expenses table.”
Reason (none) “Each expense belongs to one user, and I mostly query by user and by date, so joins and filters fit naturally.”
Evidence (none) “The relationship is the user_id column in the expenses table; the main query is in the expenses route that returns a month’s records.”
Trade-off (none) “A document database would be fine too, but reports across users would be harder. I have not added an index on date yet; that would be my first improvement.”

If the examiner follows up with “what if the user is deleted?”, the strong answerer checks their own schema and says honestly whether deletion cascades or leaves orphaned rows, then describes the fix.

Self-scoring sheet for your mock viva

Ask a friend to run ten questions from the bank above and score each answer using this table. Aim to fix any category that averages below 2.

Criterion 0 points 1 point 2 points
Accuracy Wrong or guessed Partly right Correct and precise
Link to own code No reference to project Vague reference Names the exact file, route or table
Reasoning No reason given Generic reason Reason specific to your project
Honesty about limits Claims perfection or bluffs Admits limit when pushed Volunteers a limit and a fix
Clarity Rambling Understandable Short and structured

Sharda University internship viva: what the published structures show and what to check yourself

Sharda’s regulatory approvals page says the university was established as a State Private University in Greater Noida under Uttar Pradesh Act No. 14 of 2009, and its schools issue programme structures centrally. This matters for you because the rules for your internship come from your school’s own documents, not from a general template.

Those documents differ by programme and batch. The B.Tech CSE structure (2019-20 scheme, SET0101) lists Summer Internship-I (CSP299) at 1 credit, with later internships also at 1 credit, plus Major Project-1 (CSP497) and Major Project-2 (CSP498) and Project Based Learning courses. The IT 2023-27 structure, linked earlier, shows 2-credit internships, a Capstone and PBL courses. Because those are older or batch-specific documents, treat them as indicators, not as your final rules.

One practical point: a web project built in an online internship may also help you prepare for PBL or capstone vivas, but whether it can count for any assessed course is something only your department can say. The published pages do not state a university-wide rule on online internships, required documents or duration in weeks, so ask rather than assume.

The academic calendar page lists 2026-27 calendars as separate PDFs by school and programme, so check yours for the term dates that fit your viva window.

Five steps to verify your own viva requirements

  1. Download the programme structure PDF for your exact programme and batch from the Sharda website and find the internship course code, credits and assessment weightage.
  2. Email your internship coordinator or faculty mentor asking: “Is the viva on the internship project, a report, or both, and who will be on the panel?”
  3. Ask in writing whether an online internship is acceptable for your course and which documents (offer letter, certificate, report) you must submit.
  4. Request the report format, submission deadline and viva date, and keep the reply email.
  5. Check your school’s 2026-27 academic calendar PDF so your 14 days do not clash with exams.

Preparing the day before and the day of the viva

  • Run the project from a clean clone of your repository so you know setup works.
  • Keep a one-page architecture sketch and a schema diagram within reach.
  • Re-read the three most complex files in your code.
  • Prepare a 90-second introduction: problem, stack, your role, one challenge, one improvement.
  • Have the project running in a browser and the code open in your editor.
  • If you do not know an answer, say what you do know, describe how you would find out, and move on. Bluffing is easier to catch than you expect.

Frequently Asked Questions

How long should my answers be in an internship viva?

Aim for 30 to 90 seconds on most questions. Use the four-step structure (decision, reason, evidence, trade-off) and stop. If the examiner wants more depth, they will ask a follow-up.

Do I need to memorise code for the viva as a Sharda University student?

No, but you should understand every file well enough to explain it. Reading your code the day before and knowing where each feature lives is more useful than memorising syntax.

What if I used a tutorial or library for part of my project?

Say so openly and explain what you changed or understood. Examiners generally expect learners to use documentation and libraries; what they test is whether you understand what the borrowed part does.

Is my project too simple for a viva?

A small project you can defend deeply is better than a large one you cannot explain. Complexity matters less than clear reasoning about your choices and honest awareness of its limits.

Will my viva at Sharda follow the Jury/Viva weightage in the IT syllabus?

That weightage is documented for the B.Tech IT 2023-27 summer internship. Your programme or batch may differ, so check your own programme structure PDF and confirm with your coordinator.

Can the CareerSwami internship count as my university internship?

CareerSwami offers a free two-week online internship with an offer letter and a completion certificate after successful completion, but it makes no claim about academic credit. Ask your department in writing whether it will accept an online internship for your course.

Which topics are most commonly missed by students?

Authentication, password storage, input validation and what happens on errors. These are areas where students often built something that works but cannot explain why it is safe. Prepare these answers carefully.

What should I do if I freeze during a question?

Pause, restate the question in your own words, and begin with what you are sure of. Moving from the known part to the unknown part shows reasoning, which is what the panel is looking for.

Related Full Stack Web Development guides

Ready to put this into practice?

Join the free two-week CareerSwami online internship in Full Stack Web Development. The internship, the offer letter and the completion certificate are free.

Start your free 2-week internship

Web Stories

Scroll to Top