How should SPPU students prepare for a full stack web development internship interview? Prepare six areas in this order: HTTP, REST API design, authentication, database design, front-end state management and debugging. For each one, learn a short spoken answer and keep a small project you can walk through. Interviewers for internships usually test whether you understand how a request moves through a whole application, so depth on fundamentals beats a long list of frameworks.
How to use this question bank
The bank below has 48 questions in six groups. Each group has a table with a model answer outline. An outline is a skeleton: the points a good answer should hit, in a sensible order. Do not memorise sentences. Practise saying each outline aloud in about 60 to 90 seconds, then attach one example from your own mini-project, college assignment or practice build.
A workable study plan for two weeks:
- Days 1-2: HTTP and browser basics.
- Days 3-4: REST design and status codes.
- Days 5-6: Authentication and sessions.
- Days 7-9: Database design, SQL and indexing.
- Days 10-11: State management on the front end.
- Days 12-13: Debugging drills and a project walkthrough.
- Day 14: Mock interview with a friend, timed.
SPPU engineering rules and a full stack internship: what to check before the interview
For students on the engineering side, a university document sets out the internship framework. The UG Choice Based Credit System rules for the 2019 pattern were issued under the Faculty of Science and Technology and apply from academic year 2019-20. They are a 2019-pattern document, so newer cohorts should confirm whether a later version has replaced them. They say nothing about non-engineering programmes, so BCA, BCS, MCA or MBA students should ask their own department which rules apply.
Under that document, the internship is completed after semester 5 and assessed in semester 6, lasting 4 to 6 weeks at most. For a full stack candidate, this suggests interviewing and accepting an offer before the end of semester 5, and choosing a project scope that fits a short window, such as one feature or API module rather than a whole product.
The same document lists the internship at 4 credits, evaluated by term work worth 100 marks. Because assessment rests on term work, what you record during the internship matters. Students must keep documentary proof of their activities, which is evaluated by the programme head, cell in-charge, project head, faculty mentor or industry supervisor, with a participation certificate where applicable. In practice, keep commit history, pull request links, weekly notes and screenshots of what you built, since the same material also works in a project walkthrough.
The document also says the requirement can be met at an industry, government body, NGO, MSME or rural setting, or through innovation, IPR or entrepreneurship work, with conduction, monitoring and evaluation following AICTE guidelines. It does not use the words online, virtual or remote for internships, so do not assume a remote role qualifies without asking.
Questions to settle with your department before accepting an offer
- Ask your department whether the 2019 rules still govern your batch or a newer pattern applies, and request the current document.
- Ask whether a remote or online full stack internship is acceptable for the semester 6 component, and get the answer in writing.
- Confirm the permitted duration and the exact dates by which the internship must finish, so the evaluation in semester 6 is not missed.
- Ask who your evaluator is (faculty mentor, cell in-charge or programme head) and what format of report or log they expect.
- Check what the host company will issue as a certificate and whether the college needs a specific format or signatory.
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.
Group 1: HTTP and the browser
Most interviews open here because it is quick to test and hard to fake. Expect follow-up questions that go one level deeper than your first answer.
| # | Question | Model answer outline |
|---|---|---|
| 1 | What happens when you type a URL and press Enter? | DNS lookup, TCP connection, TLS handshake for HTTPS, HTTP request, server processing, response, browser parses HTML, fetches CSS, JS and images, renders. |
| 2 | Difference between GET and POST? | GET retrieves and should be safe and idempotent; parameters sit in the URL. POST submits data in the body and can change server state. Mention caching and bookmarkability. |
| 3 | What is idempotency? | Repeating the request leaves the server in the same state. GET, PUT and DELETE are idempotent by convention; POST is not. Example: retrying a payment POST can double-charge. |
| 4 | Explain 200, 201, 301, 400, 401, 403, 404, 500. | Success, created, permanent redirect, malformed request, unauthenticated, authenticated but not allowed, not found, server fault. Stress 401 vs 403. |
| 5 | What are HTTP headers used for? | Metadata: Content-Type, Authorization, Cache-Control, Cookie, Accept. Give two examples you have set yourself. |
| 6 | What is CORS and why does it exist? | Browser policy restricting cross-origin requests. Server must send Access-Control-Allow-Origin headers. Preflight OPTIONS for non-simple requests. It is enforced by browsers, not by the server. |
| 7 | HTTP vs HTTPS? | HTTPS wraps HTTP in TLS: encryption, integrity, server identity via certificates. |
| 8 | How do cookies differ from localStorage? | Cookies are sent automatically with requests and can be HttpOnly, Secure and SameSite; localStorage is client-only, readable by scripts, and persists until cleared. |
Group 2: REST API design
| # | Question | Model answer outline |
|---|---|---|
| 9 | What makes an API RESTful? | Resources identified by URLs, standard HTTP methods, stateless requests, consistent representations (usually JSON), proper status codes. |
| 10 | Design endpoints for a blog. | GET /posts, GET /posts/:id, POST /posts, PUT or PATCH /posts/:id, DELETE /posts/:id, nested GET /posts/:id/comments. Nouns, plural, no verbs in paths. |
| 11 | PUT vs PATCH? | PUT replaces the whole resource; PATCH changes specified fields. |
| 12 | What does stateless mean? | Each request carries all information needed; the server keeps no per-client conversation state between requests, which eases horizontal scaling. |
| 13 | How do you handle pagination? | Limit and offset, or cursor-based. Return total or next cursor. Mention why offset gets slow and inconsistent on large changing tables. |
| 14 | How do you version an API? | URL prefix such as /v1, or a header. Explain why: avoid breaking existing clients. |
| 15 | How should errors be returned? | Correct status code plus a consistent JSON body with a message and a machine-readable code. Never leak stack traces. |
| 16 | REST vs GraphQL? | REST has multiple endpoints and fixed shapes; GraphQL has one endpoint where the client picks fields. Trade-offs: over-fetching, caching simplicity, learning curve. |
Group 3: Authentication and authorization
| # | Question | Model answer outline |
|---|---|---|
| 17 | Authentication vs authorization? | Who are you versus what may you do. Login is the first; role checks are the second. |
| 18 | How do you store passwords? | Never plain text. Use a slow salted hash such as bcrypt or argon2. Explain why a fast hash like plain SHA-256 is a poor choice. |
| 19 | Session-based vs token-based auth? | Sessions keep state on the server with a session ID cookie. Tokens such as JWT carry signed claims and are verified without a lookup. Discuss revocation difficulty with tokens. |
| 20 | What is inside a JWT? | Header, payload, signature, Base64URL-encoded. Payload is readable, not secret. Signature prevents tampering. |
| 21 | Where should a token be stored in the browser? | Discuss trade-offs: HttpOnly cookie resists XSS theft but needs CSRF protection; localStorage is easy but exposed to XSS. |
| 22 | What is CSRF and how do you prevent it? | Forged request riding on the user’s cookies. Use SameSite cookies, CSRF tokens, checking Origin. |
| 23 | What are access and refresh tokens? | Short-lived access token for API calls; longer-lived refresh token to obtain new ones; rotate and store carefully. |
| 24 | How does OAuth login (“Sign in with Google”) work at a high level? | Redirect to provider, user consents, app receives an authorization code, exchanges it on the server for tokens, reads profile, creates a local session. |
Group 4: Database design
| # | Question | Model answer outline |
|---|---|---|
| 25 | SQL vs NoSQL: how do you choose? | Relational for structured data with relationships and transactions; document stores for flexible, nested or fast-changing shapes. Say what your project used and why. |
| 26 | What is normalization? | Organising tables to reduce redundancy and update anomalies. Explain 1NF to 3NF in plain words, then when denormalising is acceptable. |
| 27 | Primary key vs foreign key? | Unique row identifier versus a reference enforcing relationships between tables. |
| 28 | Model students and courses. | Many-to-many, so a junction table (enrollments) with two foreign keys plus attributes such as enrolled date. |
| 29 | What is an index and what is its cost? | Structure (often B-tree) that speeds reads on a column. Costs storage and slows writes. Index columns used in WHERE, JOIN and ORDER BY. |
| 30 | INNER JOIN vs LEFT JOIN? | Inner returns matches only; left keeps all rows from the left table, with NULLs where no match. |
| 31 | What is a transaction? Explain ACID. | Group of operations that succeed or fail together. Atomicity, consistency, isolation, durability. Use a bank-transfer example. |
| 32 | What is the N+1 query problem? | One query for a list, then one per item. Fix with a join, eager loading or batching. |
| 33 | How do you prevent SQL injection? | Parameterised queries or prepared statements; ORM binding; never concatenate user input into SQL; least-privilege database user. |
Group 5: State management
| # | Question | Model answer outline |
|---|---|---|
| 34 | What is state, and how is it different from props? | State is data owned by a component that changes over time and triggers re-render; props are inputs passed from a parent and treated as read-only. |
| 35 | What is lifting state up? | Moving shared state to the nearest common parent and passing it down with callbacks. |
| 36 | What is prop drilling and how do you avoid it? | Passing props through many layers. Use context, composition or a store. |
| 37 | When would you use a store such as Redux or Zustand? | When many distant components share state, updates need to be predictable, or you need dev tools. Do not add one for a small app. |
| 38 | Local state vs server state? | Server state is cached remote data with loading, error and staleness concerns; libraries such as React Query or SWR handle it. Local UI state is things like open modals. |
| 39 | Why must state be updated immutably? | Change detection compares references; mutation can cause missed re-renders and hard bugs. |
| 40 | How do you handle forms? | Controlled inputs, validation on client and server, disabled submit during request, error display. |
| 41 | What does useEffect do and what is a common mistake? | Runs side effects after render. Mistakes: missing dependencies, no cleanup, fetch loops from state set inside the effect. |
Group 6: Debugging
| # | Question | Model answer outline |
|---|---|---|
| 42 | The page is blank after deployment. What do you check? | Browser console for errors, network tab for failed bundles, base path or routing config, environment variables, server logs. |
| 43 | An API call returns 500. Walk through your approach. | Reproduce with curl or Postman, read server logs, isolate input, check database connectivity, add a failing test, fix, verify. |
| 44 | Works locally but not in production. Why? | Environment variables, versions, case-sensitive file paths, CORS origins, database contents, build mode differences. |
| 45 | How do you use browser dev tools? | Network tab for request and response, Elements for DOM and CSS, Sources for breakpoints, Application for cookies and storage. |
| 46 | A query is slow. What now? | Run EXPLAIN, look for full scans, add or fix indexes, avoid N+1, limit returned columns, paginate. |
| 47 | How do you debug an intermittent bug? | Add structured logging, capture inputs, look for race conditions or async ordering, narrow with binary search, write a reproducer. |
| 48 | What is your general debugging process? | Reproduce, form a hypothesis, isolate, change one thing at a time, confirm the fix, add a test. |
Worked example (illustrative): answering a login-flow question
This example is illustrative. It shows how to structure a spoken answer; it is not a record of a real interview and no code here was executed.
Interviewer: “Walk me through how login works in your project.”
Weak answer: “The user enters email and password and we check the database and log them in.”
Stronger answer, built from the outlines above:
- The React form sends a POST request to
/api/auth/loginover HTTPS with the credentials in the JSON body. - The server looks up the user by email with a parameterised query, then compares the submitted password with the stored bcrypt hash.
- On success it issues a short-lived access token and sets it in an HttpOnly, Secure, SameSite cookie. On failure it returns 401 with a generic message, so attackers cannot tell which field was wrong.
- Protected routes pass through middleware that verifies the token and attaches the user to the request. Role checks, such as admin-only endpoints, return 403.
- On the front end, the logged-in user lives in context so the navbar and route guards can read it. Server data such as the profile is fetched and cached separately.
- Limitations I would improve next: add refresh-token rotation and rate limiting on the login route.
A minimal sketch of the middleware idea, labelled illustrative:
// illustrative sketch only
function requireAuth(req, res, next) {
const token = req.cookies.access_token;
if (!token) return res.status(401).json({ error: "Not logged in" });
try {
req.user = verifyToken(token);
next();
} catch (e) {
res.status(401).json({ error: "Invalid or expired token" });
}
}Notice what the stronger answer does: it follows the request in order, names the status codes, states a security choice and its reason, and ends with an honest next improvement. That last step signals maturity more than claiming the design is perfect.
Self-scorecard before the interview
Rate yourself from 0 (cannot explain) to 2 (can explain with an example from my own work). A total below 20 of 32 suggests another study pass before applying.
| Skill | 0 | 1 | 2 |
|---|---|---|---|
| Trace a request from browser to database and back | |||
| Choose correct status codes for five scenarios | |||
| Design CRUD endpoints for a new resource | |||
| Explain password hashing and token storage | |||
| Draw an ER diagram with a many-to-many link | |||
| Write a join and a grouped query from memory | |||
| Explain where state lives in my project and why | |||
| Describe a bug I fixed and how I found it |
Preparing your project walkthrough
Almost every internship interview includes “tell me about a project.” Prepare a three-minute version with this structure:
- Problem: one sentence on who the app is for.
- Stack and reasons: why this database, why this front-end approach.
- Architecture: a simple diagram you can sketch: client, API, database.
- One hard problem: a bug or design decision, what you tried, what worked.
- What you would change: pagination, tests, caching, better validation.
Keep your repository tidy before sharing it. A clear README with setup steps, environment variable names (never the secrets themselves), and screenshots makes a reviewer’s job easy. Commit messages that describe changes help too.
Practising with a real internship
Reading answers is not the same as building. A short structured internship gives you something concrete to discuss. CareerSwami offers a free two-week online internship with 26 tracks, a free offer letter and a free completion certificate after successful completion. If you pick a web development track, use the 14 days to ship one small feature end to end and then practise explaining it with the outlines above. It does not come with a stipend, academic credit or any promise of a job, so treat it as practice and a portfolio item.
Common mistakes in full stack interviews
- Listing frameworks without being able to explain the underlying HTTP or database behaviour.
- Confusing 401 and 403, or using 200 for every response including errors.
- Saying “JWT is encrypted” when its payload is only encoded.
- Designing tables with repeated comma-separated values in one column.
- Reaching for a global store in a small app and being unable to justify it.
- Silence while debugging. Think aloud: state your hypothesis and the next check.
- Claiming credit for team work without describing your own contribution.
Frequently Asked Questions
Do I need to know both React and a back-end framework for an internship interview?
Usually you need working knowledge of one front-end approach and one back-end approach, such as React with Node and Express, or a similar pairing. Interviewers care more about whether you understand the HTTP exchange between them.
How much SQL should I know?
Be able to write SELECT with WHERE, ORDER BY, GROUP BY, joins, and basic INSERT, UPDATE and DELETE from memory. Understand indexes and transactions conceptually.
Will my college syllabus be enough?
Coursework gives a base in web pages, scripting and databases, but topics such as token authentication, REST conventions and state libraries often require self-study. Compare your syllabus document with the six groups in this guide to find gaps.
Should I put my academic mini-project on my resume?
Yes, if you can explain its architecture and your own contribution. Add a live link or repository and describe measurable features, not vague claims.
What if I cannot answer a question?
Say what you know, reason aloud from related concepts, and state how you would look it up. Guessing confidently and being wrong costs more than honest reasoning.
Are coding rounds common for full stack internships?
Many include a small task, such as building a CRUD endpoint, fixing a bug in given code, or basic array and string problems. Practise in the language you plan to use, with a timer.
How do I know if an internship counts for my degree?
That is decided by your programme and college, not by the host organisation. Ask your department in writing before you start, and keep the reply.
How many full stack projects should an SPPU student show in an internship interview?
One well-explained full stack project is better than four you cannot discuss. Two is a comfortable target if the second shows a different skill, such as a third-party API or deployment.
Related Full Stack Web Development guides
- University of Mumbai Students: Comparing MERN, Django and Java Paths for a Full Stack Internship
- JNTUH Students: Building a Demo-Ready Full Stack Web Development Internship Project
- JNTUK Students: Skills Checklist to Prepare for a Full Stack Web Development Internship
- All Full Stack Web Development internship 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.
