Q: What is the difference between Server Components and Client Components?

In the App Router every component is a React Server Component (RSC) by default — it runs only on the server, never ships JavaScript to the browser, can be async, can import server-only code (fs, database drivers, secrets, large libraries like markdown parsers), and can directly fetch data using await. A Client Component is a component you opt into by adding the 'use client' directive at the top of the file. It runs both on the server (for the initial HTML — yes, Client Components still SSR for the first render) and on the client (for hydration and interactivity), and it is the only place useState, useEffect, onClick, useRef, useContext, and any other React hooks or browser APIs work. The mental model: Server Components are for data and structure; Client Components are for interactivity. You cannot import a Server Component INTO a Client Component directly because at that point the file boundary has crossed into client-bundled code — but you CAN pass a Server Component as children or as a prop, which is the standard composition pattern. In practice you want most of your tree to be Server Components — they reduce bundle size massively because the React code never ships to the browser — and push 'use client' down to the leaves like buttons, search inputs, modals, and tabs. A common production pattern: a Server Component fetches the data, renders the layout, and passes the data as props to small 'use client' islands that handle interactivity. This keeps the bundle small while preserving rich UX. The other thing to remember: once a component is marked 'use client', everything it imports is also bundled for the client — so a small useState in a giant file accidentally ships the whole file. Split files aggressively.

Q: How do you create dynamic routes in the App Router?

Dynamic routes are folders wrapped in square brackets. /app/blog/[slug]/page.tsx matches /blog/hello, /blog/anything, etc. The dynamic segment becomes a param inside the page. In Next.js 15+ params is a Promise — you must await it (or unwrap with React.use() in a Client Component) before reading the value. This was a breaking change from Next 14 where params was a plain object; the move to a Promise was made because params can depend on dynamic server logic and the framework wants to encourage async-safe code. For catch-all routes, use [...slug] which matches /blog/a/b/c as ['a', 'b', 'c']. For optional catch-all, use [[...slug]] which also matches /blog with slug === undefined. The same pattern works for route groups (folders wrapped in parentheses like (marketing)/page.tsx that group routes for organizational purposes without affecting the URL — useful when different sections need different layouts), private folders (prefixed with _ like _components/ which are never routable and live inside /app for colocation), and parallel routes (prefixed with @ for named slots). For statically generating dynamic route pages at build time, export generateStaticParams to return the list of params to prerender — this is the App Router replacement for getStaticPaths. If a request comes in for a param that was not in generateStaticParams, Next.js will fall back to rendering on demand (and optionally cache the result, depending on dynamicParams config).

Question 1

Is Next.js worth learning in 2026 if I already know React?

Accepted Answer

Yes — almost every senior frontend job posting in India (Razorpay, CRED, Postman, Meesho, Vercel India) lists Next.js as required or strongly preferred. A pure React (Vite) developer in 2026 caps out around ₹15 LPA; adding Next.js, RSC, and the App Router pushes that to ₹18-24 LPA at the mid-senior level and over ₹30 LPA at staff.

Question 2

Should I learn the Pages Router or jump straight into the App Router?

Accepted Answer

Start with the App Router — it is what new projects use and what interviewers expect. But spend a few hours understanding Pages Router (getStaticProps, getServerSideProps, _app.tsx, _document.tsx, /pages/api) because most production codebases in 2026 still maintain Pages Router routes you will need to read and migrate.

Question 3

How much does a Next.js developer earn in India?

Accepted Answer

₹7-24 LPA in 2026 for mid-to-senior frontend developers with strong Next.js skills. Junior roles (0-2 years) start at ₹5-9 LPA; staff and principal levels at unicorns (Razorpay, CRED, Postman) cross ₹30 LPA. Specialised performance/SEO roles at e-commerce (Meesho, Nykaa) and EdTech (Unacademy, GeeksforGeeks) pay at the upper end.

Question 4

Can I run Next.js without Vercel?

Accepted Answer

Yes — Next.js is fully open source and runs anywhere Node.js or Bun runs. Self-hosting on AWS, GCP, DigitalOcean, or Coolify is common. The main thing you lose is automatic image optimization scaling (you need to size your server for sharp) and a shared ISR cache (you need to wire up @neshca/cache-handler with Redis). Vercel's pricing in India starts free (Hobby), then $20/month (~₹1,700) for Pro — for many Indian startups this is cheaper than the engineering time to self-host.

Question 5

What is the most asked Next.js interview question in 2026?

Accepted Answer

'Explain the difference between Server Components and Client Components, and when you would use each.' Variants probe caching ('what are the four Next.js cache layers?'), hydration ('why does my useState throw?'), and architecture ('why is your form a server action instead of a fetch?'). If you can answer those four families clearly with real examples, you will pass most senior frontend interviews.

Question 6

Which companies in India hire heavily for Next.js?

Accepted Answer

Razorpay, CRED, Postman, Meesho, Nykaa, Cure.fit, Unacademy, GeeksforGeeks, Vercel India, Hashnode, and most YC-backed Indian SaaS (Zoho subsidiaries are an exception — they still mostly use Vue / Ember). Even Tata Neu and ICICI's newer customer-facing surfaces use Next.js. The single biggest demand cluster is fintech and EdTech, where SEO and Core Web Vitals directly drive business. International companies with significant Indian engineering presence — Netflix, TikTok, Hulu, Vercel itself — also hire Next.js engineers from India for both India-based and remote roles, and these typically pay 1.5-2x the local market rate. If you are early-career and targeting Next.js specifically, prioritise TypeScript fluency alongside it — every senior interview will assume it, and starting in TypeScript from day one saves weeks of rework later.

Question 7

What is Next.js and what problems does it solve over plain React?

Accepted Answer

Next.js is a React meta-framework built by Vercel that adds server-side rendering, static generation, file-system routing, image optimization, and a unified data-fetching model on top of React. Plain React (Create React App or a Vite SPA) ships a near-empty HTML shell and hydrates everything on the client — that hurts SEO, time-to-first-byte, and Core Web Vitals on slow networks. Next.js solves four real problems: (1) HTML is rendered on the server so search crawlers and slow Indian 4G clients see content immediately, (2) routing is derived from the file system instead of needing a separate router config, (3) images, fonts, and scripts are optimized automatically via the Image, Font, and Script components, and (4) data fetching, caching, and revalidation are first-class — you can mark a fetch as static (cached forever), revalidated (ISR), or dynamic (per-request) with a single option. In 2026 the App Router also unlocks React Server Components, which let you keep heavy data-fetching logic on the server without shipping it as JavaScript to the browser.

Question 8

What is the difference between the Pages Router and the App Router?

Accepted Answer

The Pages Router (in /pages) is the original Next.js routing system: every file is a route, data fetching happens in getStaticProps / getServerSideProps / getStaticPaths, and the whole tree is a client React component by default. The App Router (in /app), introduced in Next.js 13 and stabilised in 13.4, is the modern default: every file is a React Server Component by default, data fetching happens directly inside async components, and the framework supports nested layouts, loading.tsx, error.tsx, route groups, parallel routes, and intercepting routes. Pages Router files are .js/.tsx files like /pages/blog/[slug].tsx; App Router uses folders with special files like /app/blog/[slug]/page.tsx. Both routers can coexist in the same project — most production apps in 2026 still have a hybrid, with new features built in App Router and legacy pages still in Pages Router. The App Router is what interviewers expect you to know in depth; Pages Router is what you will actually maintain.

Question 9

What is the difference between SSR, SSG, ISR, and CSR in Next.js?

Accepted Answer

These are four rendering strategies Next.js supports, and understanding when to use each is one of the most-asked Next.js interview questions in India. SSG (Static Site Generation) renders pages to HTML at build time — fast, cacheable on a CDN, but the content is frozen until you rebuild. Good for marketing pages, documentation, and any page where content changes rarely. The HTML is shipped directly from edge caches like Cloudflare or Vercel's CDN, so TTFB is often <50ms even from India. SSR (Server-Side Rendering) renders on every request — fresh data on each load, but every request hits your server. Good for dashboards, personalised pages, and any page where each user sees different content. The trade-off: every request costs server CPU and network round-trip time. ISR (Incremental Static Regeneration) is the middle ground: pages are statically generated, but Next.js re-renders them in the background after a configured interval (revalidate: 60 means every 60 seconds the next request triggers a rebuild, and the previous static version is served until the rebuild completes — so no user waits). It gives you static performance with eventually-consistent freshness — perfect for blogs, product pages, e-commerce listings, and SEO landing pages where you want to push content updates without redeploying. CSR (Client-Side Rendering) renders only on the client — the server sends a shell, React fetches and renders in the browser. Used for highly interactive parts of the page (charts, dashboards behind auth, real-time data) that do not need to be SEO-friendly. In the App Router these map to: default static for Server Components without dynamic APIs, dynamic = 'force-dynamic' for SSR, revalidate = N for ISR, and 'use client' components that fetch in useEffect for CSR. The Next.js sweet spot is to mix all four in the same application: marketing pages SSG, product listings ISR, user dashboard SSR, real-time chart CSR — and now with Partial Prerendering you can mix them within the same page.

Question 10

What is the difference between Server Components and Client Components?

Accepted Answer

In the App Router every component is a React Server Component (RSC) by default — it runs only on the server, never ships JavaScript to the browser, can be async, can import server-only code (fs, database drivers, secrets, large libraries like markdown parsers), and can directly fetch data using await. A Client Component is a component you opt into by adding the 'use client' directive at the top of the file. It runs both on the server (for the initial HTML — yes, Client Components still SSR for the first render) and on the client (for hydration and interactivity), and it is the only place useState, useEffect, onClick, useRef, useContext, and any other React hooks or browser APIs work. The mental model: Server Components are for data and structure; Client Components are for interactivity. You cannot import a Server Component INTO a Client Component directly because at that point the file boundary has crossed into client-bundled code — but you CAN pass a Server Component as children or as a prop, which is the standard composition pattern. In practice you want most of your tree to be Server Components — they reduce bundle size massively because the React code never ships to the browser — and push 'use client' down to the leaves like buttons, search inputs, modals, and tabs. A common production pattern: a Server Component fetches the data, renders the layout, and passes the data as props to small 'use client' islands that handle interactivity. This keeps the bundle small while preserving rich UX. The other thing to remember: once a component is marked 'use client', everything it imports is also bundled for the client — so a small useState in a giant file accidentally ships the whole file. Split files aggressively.

Question 11

How do you create dynamic routes in the App Router?

Accepted Answer

Dynamic routes are folders wrapped in square brackets. /app/blog/[slug]/page.tsx matches /blog/hello, /blog/anything, etc. The dynamic segment becomes a param inside the page. In Next.js 15+ params is a Promise — you must await it (or unwrap with React.use() in a Client Component) before reading the value. This was a breaking change from Next 14 where params was a plain object; the move to a Promise was made because params can depend on dynamic server logic and the framework wants to encourage async-safe code. For catch-all routes, use [...slug] which matches /blog/a/b/c as ['a', 'b', 'c']. For optional catch-all, use [[...slug]] which also matches /blog with slug === undefined. The same pattern works for route groups (folders wrapped in parentheses like (marketing)/page.tsx that group routes for organizational purposes without affecting the URL — useful when different sections need different layouts), private folders (prefixed with _ like _components/ which are never routable and live inside /app for colocation), and parallel routes (prefixed with @ for named slots). For statically generating dynamic route pages at build time, export generateStaticParams to return the list of params to prerender — this is the App Router replacement for getStaticPaths. If a request comes in for a param that was not in generateStaticParams, Next.js will fall back to rendering on demand (and optionally cache the result, depending on dynamicParams config).

Question 12

How do you handle API routes in Next.js?

Accepted Answer

In the App Router, API routes are called Route Handlers and live in /app/.../route.ts. You export one async function per HTTP verb: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Each function receives a Request object and returns a Response (or NextResponse for the Next.js-specific helpers). The Pages Router equivalent is /pages/api/.../filename.ts with a single default export taking (req, res) — different shape entirely. Route Handlers run on the Node.js runtime by default, but you can opt into the Edge runtime with export const runtime = 'edge' for lower latency at the cost of restricted APIs (no fs, no native modules, limited bundle size). Route Handlers are by default cached for GET requests in Next.js 14 but in Next.js 15 GET handlers are also uncached by default — the framework has been moving towards explicit caching. To opt out of caching explicitly, set export const dynamic = 'force-dynamic', or use cookies(), headers(), or read NextRequest.url with searchParams — any of these mark the handler as dynamic. For most CRUD work, Route Handlers are enough; for full backends you would still pair Next.js with a dedicated server (Express, FastAPI, Hono) or use server actions for mutations. Route Handlers are also where you put public webhooks (Stripe, Razorpay, Twilio) and any endpoints consumed by mobile apps or third parties — server actions cannot serve that role because their endpoints are Next.js-internal and not stable URLs.

Question 13

What is next/link and why should you use it instead of an anchor tag?

Accepted Answer

next/link is the Next.js client-side navigation component. When the user clicks a Link, Next.js performs a soft navigation: it fetches only the data needed for the next route (the RSC payload, not a full HTML reload), updates the URL, and re-uses any layouts that have not changed. Plain anchor tags trigger a full browser navigation, throwing away the React tree and re-downloading all the JavaScript. Link also prefetches the target route automatically when it enters the viewport, so the click feels instant. In Next.js 15 prefetching of dynamic routes is on-demand (you opt in with prefetch={true}) to avoid wasted server work. For external links (https://...) plain <a> is correct — Link is only for internal routes.

Question 14

How does the next/image component improve performance?

Accepted Answer

next/image is a wrapper around the native img element that adds five optimizations Next.js handles automatically: (1) it serves WebP or AVIF when the browser supports it, falling back to JPEG/PNG, which can reduce image payloads by 30-50% over JPEG, (2) it generates multiple sizes and uses srcSet so phones download a small image and laptops download a large one — this is huge for mobile-first Indian traffic, (3) it lazy-loads images that are below the fold using the native loading='lazy' attribute, so the browser does not waste bandwidth downloading images the user has not scrolled to, (4) it reserves space using the width/height props to prevent Cumulative Layout Shift (CLS), a Core Web Vitals metric that Google factors into search rankings, and (5) on Vercel it runs the optimizer at the edge and caches the result on the CDN so repeat visitors get the optimized image without round-tripping to your origin. For Indian users on slow 4G, this is often the single biggest perceived-speed improvement you can make to a Next.js site — replacing 2 MB of unoptimized JPEGs with 200 KB of optimized AVIFs typically cuts LCP from 4-5 seconds to under 2 seconds. Gotcha: external images need their domain added to images.remotePatterns in next.config.js, or Next.js refuses to optimize them. On self-hosted Docker, you need sharp installed (auto-included in 13+) and enough memory for the optimizer (~512 MB recommended, more for very high traffic). For self-hosted at scale, consider offloading image optimization to Cloudflare Image Resizing or BunnyCDN's image processor to avoid your Next.js servers becoming CPU-bound on sharp.

Question 15

What is getStaticProps and getServerSideProps?

Accepted Answer

These are the Pages Router data-fetching functions. getStaticProps runs at build time on the server, returns props for the page, and produces static HTML. Combined with revalidate: N it becomes ISR — the page is regenerated in the background every N seconds on the next visitor. getServerSideProps runs on every request on the server, returns props, and renders fresh HTML each time. They both run only on the server (so you can safely use database drivers and secrets) and they both deliver props to the page component. In the App Router these are gone — you fetch directly inside async Server Components, and the caching behaviour is controlled by the fetch options (cache: 'force-cache' for SSG, no-store for SSR, next: { revalidate: 60 } for ISR). Interviewers still ask about Pages Router functions because most production apps still have them.

Question 16

What is the difference between fetch() in a Server Component and useEffect fetch in a Client Component?

Accepted Answer

In a Server Component, fetch runs on the server during the render — the user never sees a loading state because the HTML arrives with data already in it. The data is part of the initial response, which means better SEO (crawlers see content immediately), better Largest Contentful Paint, and no client-side waterfall. Next.js extends the standard fetch with caching options: by default fetch is memoized within a single render so calling it twice for the same URL hits the network once. You also get cache, revalidate, and tags options for cache control. In a Client Component, fetch inside useEffect runs in the browser after the component mounts — the user sees a loading state, the bundle has to ship the fetching code as JavaScript, and you usually need a library like SWR or TanStack Query (React Query) to handle deduplication, retries, error states, and caching. There is also a hidden cost: client-side fetches happen AFTER hydration, which means after the browser has parsed and executed your JavaScript bundle. On a slow Indian 4G connection this can add 2-3 seconds before the data even starts loading. The rule of thumb in 2026: fetch on the server whenever possible (faster, smaller bundle, no waterfalls, better SEO), and only use client-side fetching for data that depends on user interaction (search-as-you-type, polling, real-time updates, optimistic mutations). When you do need client-side data, prefer the new useSWR or useQuery hooks pre-populated with server-fetched initialData so the first paint shows real data and only subsequent updates hit the client fetch.

Next.js Interview Questions

What is Next.js and what problems does it solve over plain React?

What is the difference between the Pages Router and the App Router?

What is the difference between SSR, SSG, ISR, and CSR in Next.js?

What is the difference between Server Components and Client Components?

How do you create dynamic routes in the App Router?

How do you handle API routes in Next.js?

What is next/link and why should you use it instead of an anchor tag?

How does the next/image component improve performance?

What is getStaticProps and getServerSideProps?

What is the difference between fetch() in a Server Component and useEffect fetch in a Client Component?

What is the purpose of layout.tsx and how does it differ from page.tsx?

How do you deploy a Next.js application?

How does the Next.js fetch cache work and what are the four cache layers?

What are server actions and when should you use them?

How do you handle loading and error states in the App Router?

What are parallel routes and intercepting routes?

What is middleware in Next.js and how is it different from middleware in Express?

What is partial prerendering (PPR) and why is it interesting?

How do you optimize fonts in Next.js?

How do you handle authentication in a Next.js app?

How do you migrate from Pages Router to App Router?

How do you debug hydration mismatches in Next.js?

What is the difference between revalidatePath and revalidateTag?

How do you handle environment variables in Next.js?

How do you handle internationalization (i18n) in Next.js?

How do you optimise a Next.js app for the lowest possible Largest Contentful Paint (LCP) in India?

How would you architect a self-hosted Next.js deployment for an Indian SaaS at scale (1M+ MAU)?

How does the dynamicIO mode in Next.js 15+ change the way you think about caching?

How would you implement on-demand ISR with a webhook from a headless CMS, in a multi-instance self-hosted setup?

What are the trade-offs between Next.js, Remix, and Astro for a content-heavy SEO product in India?

Companies Hiring Next.js

Salary Insights

Frequently Asked Questions