Top Node.js Interview Questions Asked in India in 2026 (With Real Answers)

This is not a list of 100 questions you will never be asked. These are the questions that companies — from TCS to Razorpay to Amazon India — are actually asking Node.js developers in 2026, organised by experience level, with answers written the way you should say them in an interview room: clear, precise, and showing that you understand the why, not just the what.

Bookmark this. Read it the week before your interview. Then read it again the day before.

Before the questions: what interviewers in India actually look for in 2026

Interviewers at Indian product companies (Swiggy, Razorpay, Zepto, Razorpay, PhonePe, CRED) have been very consistent in what they say they want: developers who understand Node.js's internals, not just its API. You can look up syntax. You cannot look up how the event loop handles setImmediate versus process.nextTick in a live interview.

At service companies (TCS, Infosys, Wipro), the bar is lower for freshers but still tests whether you understand asynchronous patterns. They do not want developers who write nested callbacks in 2026 — that is a red flag.

One thing experienced developers consistently say: "Avoid vague answers. Don't say 'Node.js is fast because it's asynchronous.' Instead say: 'Node.js uses an event-driven, non-blocking I/O model powered by libuv, which lets a single thread handle thousands of concurrent requests efficiently.'" Precision is what separates candidates.

Section 1: Fresher and Junior questions (0–2 years)

These come in the first 20–30 minutes of any Node.js interview.

Q1. What is Node.js, and what makes it different from running JavaScript in a browser?

Node.js is a JavaScript runtime built on Chrome's V8 engine that lets you run JavaScript on the server side. The key differences from the browser: there is no DOM or window object in Node.js; instead you get access to the file system, network, and OS through built-in modules like fs, http, and path. Node.js also uses the CommonJS module system (though ES modules are now supported) while browsers use their own module system. Under the hood, Node.js uses libuv, a C library that handles the event loop and asynchronous I/O.

Q2. What is the event loop? Explain it in your own words.

This is the most important question in any Node.js interview. Get it right.

The event loop is the mechanism that allows Node.js to handle asynchronous operations even though it runs on a single thread. Here is how it works: JavaScript code runs on the call stack. When the call stack is empty, the event loop checks if there are any callbacks waiting to be executed — from timers, I/O operations, or other async tasks — and pushes them to the call stack one at a time.

The event loop goes through specific phases in order: timers (executes setTimeout and setInterval callbacks), pending callbacks (handles I/O errors from the previous cycle), poll (retrieves new I/O events), check (setImmediate callbacks run here), and close callbacks.

A practical example interviewers often use:

console.log("Start");
setTimeout(() => console.log("Timeout"), 0);
console.log("End");

Output: Start → End → Timeout. Even though the timeout is 0ms, it goes through the event loop's timer phase, so synchronous code always runs first.

Q3. What is the difference between process.nextTick() and setImmediate()?

This is a "gotcha" question that many freshers get wrong.

process.nextTick() runs its callback before the event loop moves to the next phase — meaning it runs after the current operation but before any I/O events or timers. setImmediate() runs its callback in the check phase of the event loop, after I/O events are processed.

In practice: if you need something to run after the current function but before anything else (including I/O), use process.nextTick(). If you want to run something after I/O events in the current loop iteration, use setImmediate().

Be careful with process.nextTick() in recursive scenarios — it can starve the event loop because it keeps running before the next phase.

Q4. What is callback hell, and how do you avoid it?

Callback hell (also called the "pyramid of doom") is what happens when you nest multiple asynchronous callbacks inside each other, making code deeply indented, hard to read, and nearly impossible to debug.

// Callback hell — don't write this in 2026
getUserData(userId, function(user) {
  getOrders(user.id, function(orders) {
    getOrderDetails(orders[0].id, function(details) {
      // ... and so on
    });
  });
});

The solutions, in order of preference:

1. Promises — Chain .then() and .catch() instead of nesting

2. async/await — Makes async code look and read like synchronous code, far cleaner

3. Modular callbacks — Name your callback functions and define them separately

In 2026, interviewers expect you to use async/await as the default pattern. Writing nested callbacks in an interview is a red flag.

Q5. Explain require vs import in Node.js.

require is CommonJS (Node.js's original module system). It is synchronous, works at runtime, and you can use it conditionally inside functions. import is ES Modules (ESM), which was introduced in Node.js 12+ and became stable in Node.js 14. import is static, resolved at parse time, and enables tree-shaking.

The practical difference: if you're maintaining an older Node.js codebase, you'll use require. New projects in 2026 increasingly use ESM with "type": "module" in package.json. Some frameworks like Next.js and Vite are fully ESM-first.

One common trap: exports and module.exports are not the same thing. exports is a shorthand reference to module.exports. If you reassign exports = something, you break the reference and your module will not export correctly.

Q6. What is middleware in Express.js, and how does it work?

Middleware is a function that has access to the request object (req), the response object (res), and the next middleware function in the stack (next). Middleware runs between a request arriving and a response being sent.

app.use((req, res, next) => {
  console.log(`${req.method} ${req.url} - ${Date.now()}`);
  next(); // Pass control to the next middleware
});

If you forget to call next(), the request hangs forever. If you call res.send() without calling next(), the chain stops there. Middleware functions are executed in the order they are defined.

Common uses: logging, authentication, request parsing (express.json()), rate limiting, error handling. Error-handling middleware is special — it takes four arguments (err, req, res, next) and must be defined last.

Section 2: Intermediate questions (2–5 years)

These come from product companies and mid-senior roles. Expect deeper questions.

Q7. How do you handle errors in async/await properly?

The naive approach is wrapping everything in try/catch:

async function getUser(id) {
  try {
    const user = await db.findById(id);
    return user;
  } catch (error) {
    console.error(error);
    throw error; // Re-throw so the caller knows it failed
  }
}

The problem: in Express routes, if an async function throws and you don't catch it, the error is swallowed and the request hangs. The fix is either using a wrapper utility or Express 5 (which handles async errors natively):

// Wrapper for Express 4
const asyncHandler = (fn) => (req, res, next) =>
  Promise.resolve(fn(req, res, next)).catch(next);

app.get('/user/:id', asyncHandler(async (req, res) => {
  const user = await getUser(req.params.id);
  res.json(user);
}));

Interviewers want to see that you understand the global error handler pattern and that you know unhandled promise rejections crash Node.js processes.

Q8. What are streams in Node.js, and when would you use them?

Streams are a way to handle data in chunks rather than loading everything into memory at once. Node.js has four types: Readable (data can be read), Writable (data can be written), Duplex (both), and Transform (data is modified as it passes through).

Why they matter: if you load a 1GB file into memory with fs.readFile(), your server needs 1GB of RAM to process it. With streams, you read it in small chunks, process each chunk, and keep memory usage constant regardless of file size.

const fs = require('fs');
const readline = require('readline');

const rl = readline.createInterface({
  input: fs.createReadStream('large-file.txt')
});

let lineCount = 0;
rl.on('line', () => lineCount++);
rl.on('close', () => console.log(`Total lines: ${lineCount}`));

Real-world use cases in Indian product companies: streaming large CSV exports from databases, processing video/audio uploads, piping API responses, building ETL pipelines.

Interviewers often ask: "What is backpressure?" Answer: it is when a writable stream cannot process data as fast as a readable stream sends it. Node.js streams handle this with the pipe() method, which automatically pauses the readable stream when the writable buffer is full.

Q9. How does clustering work in Node.js, and why do you need it?

Node.js runs on a single thread. A server with 8 CPU cores is using only 1 of them for your Node.js app by default. The Cluster module fixes this.

const cluster = require('cluster');
const os = require('os');
const http = require('http');

if (cluster.isMaster) {
  const numCPUs = os.cpus().length;
  for (let i = 0; i < numCPUs; i++) {
    cluster.fork(); // Create a worker process per CPU
  }
} else {
  http.createServer((req, res) => {
    res.end('Hello from worker ' + process.pid);
  }).listen(3000);
}

The master process manages the workers. If a worker crashes, the master can fork a new one. Load is distributed across workers automatically.

In production at Indian companies, many teams use PM2 (a process manager) instead of writing Cluster code manually. PM2's --cluster mode does the same thing with one command.

Q10. How would you prevent your Node.js API from being taken down by heavy requests?

This is a system design flavoured question that interviewers use to gauge your production experience. Good answers cover multiple layers:

Rate limiting — Use express-rate-limit to restrict how many requests a single IP can make in a time window. Basic protection against abuse.

Input validation — Validate and sanitise all incoming data. Malformed or extremely large payloads can cause crashes.

Timeouts — Set explicit timeouts on database queries and external API calls. A slow third-party API that never responds will hang your requests if you don't handle it.

Circuit breaker pattern — If a downstream service (database, payment gateway) is failing, stop sending requests to it immediately rather than queuing up thousands of failing calls.

Horizontal scaling — Use multiple Node.js instances behind a load balancer (Nginx, AWS ALB). No single instance becomes a bottleneck.

Caching — Use Redis to cache frequently read data. If 10,000 users request the same product page, only hit the database once.

Q11. What is the difference between == and === in JavaScript, and why does it matter in Node.js?

This seems too basic for intermediate level, but it trips up mid-level developers surprisingly often in interviews.

== is abstract equality — it performs type coercion before comparing. === is strict equality — it checks both value and type, no coercion.

0 == false   // true (coercion)
0 === false  // false (different types)
null == undefined  // true
null === undefined // false

In Node.js backend code, == can cause subtle bugs in database query results, request parameter comparisons, and config checks. Always use === in production code. If an interviewer asks this, they are checking whether you code defensively.

Section 3: Senior and system design questions (5+ years)

These are asked at product companies and MNCs for roles paying ₹20 LPA and above.

Q12. How would you design a rate limiter in Node.js from scratch?

Do not just say "use express-rate-limit." Explain the underlying algorithm.

A token bucket rate limiter works like this: each user gets a bucket with a max capacity of, say, 100 tokens. Each request costs one token. Tokens refill at a fixed rate (say, 10 per second). If the bucket is empty, the request is rejected with a 429 status.

For a distributed system (multiple Node.js instances), you cannot store rate limit state in memory — it won't be shared across instances. You use Redis with atomic operations:

const redis = require('ioredis');
const client = new redis();

async function isRateLimited(userId, limit, windowSeconds) {
  const key = `rate:${userId}`;
  const current = await client.incr(key);
  if (current === 1) {
    await client.expire(key, windowSeconds);
  }
  return current > limit;
}

This is a sliding window counter. Interviewers at companies like Razorpay and PhonePe specifically ask this because rate limiting is core to their infrastructure.

Q13. How do you find and fix a memory leak in a Node.js application?

Memory leaks in Node.js are usually caused by: global variables that grow indefinitely, event listeners that are added but never removed, closures that hold references to large objects, or caching without eviction policies.

Finding it: Use Node.js's built-in --inspect flag with Chrome DevTools to take heap snapshots and compare them over time. The clinic.js tool (from NearForm) is excellent for profiling. In production, monitor heap usage with APM tools (Datadog, New Relic, or the open-source Prometheus + Grafana stack).

Common fix pattern:

// Bug: event listener added in every request but never removed
app.get('/data', (req, res) => {
  someEmitter.on('event', handler); // Grows with every request
  res.send('ok');
});

// Fix: remove listener after use, or use .once()
app.get('/data', (req, res) => {
  someEmitter.once('event', handler);
  res.send('ok');
});

Interviewers ask this to check whether you have actually debugged production issues, not just written tutorial code.

Q14. Explain Worker Threads in Node.js and when you'd use them.

The event loop is great for I/O-bound tasks (reading files, database queries, API calls). But it is not suitable for CPU-bound tasks — things like image processing, complex mathematical calculations, or large data transformations. These block the single thread and make your entire server unresponsive.

Worker Threads (stable since Node.js 12) let you run JavaScript in parallel threads with separate memory:

const { Worker, isMainThread, parentPort } = require('worker_threads');

if (isMainThread) {
  const worker = new Worker(__filename);
  worker.on('message', result => console.log('Result:', result));
  worker.postMessage({ data: largeArray });
} else {
  parentPort.on('message', ({ data }) => {
    const result = heavyComputation(data);
    parentPort.postMessage(result);
  });
}

Real use cases at Indian product companies: generating complex PDF reports, processing large CSV uploads, running ML inference (though Python is more common for this), image resizing.

Quick-reference: Questions by company type

TCS / Infosys / Wipro (freshers and junior roles) Expect: event loop basics, async/await, REST API concepts, Express middleware, basic error handling, what is Node.js and why use it.

Mid-size product companies (Freshworks, Zoho, Sharechat, Meesho) Expect: streams, clustering, database integration patterns, JWT authentication, how you've handled production issues, system design basics (design a URL shortener or a basic notification service).

High-growth startups and MNCs (Razorpay, Swiggy, PhonePe, Amazon, Microsoft) Expect: deep event loop internals, Worker Threads, memory management, distributed rate limiting, microservices patterns, designing for 100K+ concurrent users, debugging production incidents.

The one thing most candidates get wrong

They memorise answers. Interviewers at product companies in India are experienced — they immediately know if you are reciting something versus understanding it. If you say "the event loop checks the callback queue and pushes to the call stack," they will ask "what are the phases of the event loop, and in what order do they execute?" If you cannot answer that, the memorised answer hurt you.

The way to actually prepare: build something. Build a real-time chat app with Socket.io. Build an API with rate limiting and JWT auth. Process a large CSV with streams. Debug a memory leak in a toy project. When you explain from experience in an interview, the confidence is different — and interviewers feel it.

Preparing for a Node.js interview? Drop your experience level and target company in the comments, and we'll tell you exactly what to focus on.