\n\n```\n\nReact reads window.__ENV__.API_URL at runtime instead of a build-time constant. Now the exact same Docker image gets deployed to staging and production — only the environment variables passed to the container differ."}},{"@type":"Question","name":"During Kubernetes rolling deployments of an Express service, in-flight React network requests fail with connection reset errors and MongoDB transactions abort. How do you coordinate SIGTERM signal handling, server.close(), Mongoose connection disconnects, and Kubernetes preStop lifecycles?","acceptedAnswer":{"@type":"Answer","text":"There are two separate timing problems during a rolling deployment. First, Kubernetes removes a terminating pod from the Service's endpoint list asynchronously — there's a real window where the pod has received SIGTERM but iptables on some nodes hasn't updated yet, so new traffic can still land on a pod that's shutting down. A preStop hook that sleeps a few seconds before the container gets SIGTERM closes that gap.\n\nSecond, inside Node itself: server.close() stops the HTTP server from accepting new connections but lets in-flight requests finish naturally — it does not forcibly kill active sockets. Call this on SIGTERM, then only close the Mongoose connection after in-flight requests have actually completed.\n\n```js\nprocess.on('SIGTERM', async () => {\n server.close(async () => { // stop accepting new connections\n await mongoose.connection.close(); // now safe: no more in-flight DB work\n process.exit(0);\n });\n});\n```\n\n```yaml\nlifecycle:\n preStop:\n exec:\n command: [\"sh\", \"-c\", \"sleep 5\"]\nterminationGracePeriodSeconds: 30\n```\n\nterminationGracePeriodSeconds must be comfortably larger than preStop sleep plus your longest realistic in-flight request duration, or Kubernetes SIGKILLs the process before graceful shutdown finishes."}},{"@type":"Question","name":"To reduce MongoDB read load, Express caches user profile queries in Redis. How do you design a cache invalidation strategy triggered by React mutation requests so that subsequent reads from any client instance immediately see fresh data without stale read anomalies?","acceptedAnswer":{"@type":"Answer","text":"The standard approach is cache-aside: Express checks Redis first on a read, falls back to MongoDB on a miss and populates Redis with a TTL. The hard part is making sure a write anywhere invalidates the right keys immediately, so no client instance serves stale data after a mutation.\n\nThe simplest correct approach is synchronous invalidation in the same request that performs the write: the mutation handler deletes the specific cache key(s) before responding, rather than waiting on a TTL.\n\n```js\napp.patch('/users/:id', async (req, res) => {\n const user = await User.findByIdAndUpdate(req.params.id, req.body, { new: true });\n await redis.del(`user:${req.params.id}`); // invalidate immediately, same request\n res.json(user);\n});\n```\n\nIf you're running multiple Node instances that also keep a local in-process cache on top of Redis, one instance deleting the Redis key doesn't clear the others' local copies — for that you need a pub/sub broadcast (Redis PUBLISH/SUBSCRIBE, or keyspace notifications) so every instance drops its local copy when it hears the event. Also namespace keys with a version or tenant prefix (v2:user:123) so a schema change can invalidate an entire generation of cache entries by bumping the prefix."}},{"@type":"Question","name":"In a Playwright E2E test suite testing a MERN application, running tests concurrently causes data collisions in the shared MongoDB database. How do you design per-worker database isolation or transactional cleanup fixtures using mongodb-memory-server and seed data scripts?","acceptedAnswer":{"@type":"Answer","text":"Two isolation strategies work together. The simplest is a dedicated mongodb-memory-server instance spun up once per Playwright worker in globalSetup — since Playwright already runs workers as separate processes, each gets its own in-memory Mongo on its own ephemeral port, so there's no shared state to collide on at all.\n\n```js\n// global-setup.js\nconst { MongoMemoryServer } = require('mongodb-memory-server');\nexport default async function globalSetup() {\n const mongod = await MongoMemoryServer.create();\n process.env.MONGO_URI = mongod.getUri();\n}\n```\n\nThe second layer is per-test cleanliness within that shared-per-worker instance: a fixture that seeds known baseline data before each test and drops/truncates touched collections after, rather than relying on transactional rollback (multi-document transactions need a replica set, which mongodb-memory-server can run via MongoMemoryReplSet, but it's heavier than usually needed for E2E — a targeted collection.deleteMany({}) in an afterEach fixture is simpler). The key discipline: never point CI tests at the real shared MongoDB — every worker gets its own throwaway instance, so collisions become structurally impossible instead of something you're hoping tests don't trigger."}},{"@type":"Question","name":"Your React tests use Mock Service Worker (MSW) to mock Express endpoints, but production bugs slip through because Express Mongoose schemas evolved without updating MSW handlers. How do you establish a single source of truth using Zod/TypeScript schemas shared across Express validation and MSW mocks?","acceptedAnswer":{"@type":"Answer","text":"The root cause is having two independent definitions of 'what a valid User looks like' — one in the Mongoose schema/Express validation, the other hand-written into MSW mock handlers — with nothing forcing them to stay in sync when the real schema changes.\n\nThe fix is a single Zod schema both sides import from a shared module in the monorepo. Express uses it directly as request/response validation middleware; MSW handlers use the same schema to generate or validate mock payloads.\n\n```ts\n// shared/schemas/user.ts\nexport const UserSchema = z.object({\n id: z.string(),\n email: z.string().email(),\n role: z.enum(['admin', 'member']),\n});\n\n// Express\napp.post('/users', (req, res) => {\n const parsed = UserSchema.omit({ id: true }).safeParse(req.body);\n if (!parsed.success) return res.status(400).json(parsed.error.flatten());\n});\n\n// MSW handler\nhttp.get('/api/users/:id', () => HttpResponse.json(UserSchema.parse(mockUser)));\n```\n\nNow, when someone adds a required field to the real schema, both Express validation and the MSW mock either need to produce that field or a Zod parse throws — drift becomes a visible test failure at the point of the schema change, not a production bug discovered later."}},{"@type":"Question","name":"Write an end-to-end integration test scenario verifying that when a Node/Express backend drops its WebSocket connection, the React UI displays a reconnecting banner, queues outgoing user actions, and seamlessly reconciles pending state with MongoDB upon reconnection.","acceptedAnswer":{"@type":"Answer","text":"The test needs to exercise three phases: healthy connection, disconnection with graceful degradation, and reconnection with state reconciliation.\n\n1. Establish a normal WebSocket connection and confirm baseline behavior. 2. Force a drop — either kill the server-side socket in a test hook or use Playwright's CDP session (context.setOffline(true)). Assert the UI immediately shows a 'reconnecting' banner, driven by the client socket's own disconnect event. 3. While disconnected, perform a user action; assert it's queued locally (an outbox in memory or IndexedDB) rather than dropped, with a 'pending' indicator. 4. Restore the connection; assert the socket auto-reconnects, queued actions flush in order, and the banner disappears. 5. Assert the final rendered state matches a fresh fetch from MongoDB — i.e., reconciliation didn't duplicate an action if the server had actually already received it before the visible disconnect.\n\n```js\nawait context.setOffline(true);\nawait expect(page.getByText('Reconnecting…')).toBeVisible();\nawait page.getByRole('textbox').fill('queued comment');\nawait page.getByRole('button', { name: 'Send' }).click();\nawait context.setOffline(false);\nawait expect(page.getByText('Reconnecting…')).toBeHidden();\nawait expect(page.getByText('queued comment')).toBeVisible();\n```"}},{"@type":"Question","name":"Running full UI login flows before each of 200 Cypress/Playwright tests increases test suite duration to 35 minutes. How do you bypass the UI login by programmatically generating valid JWT cookies/session tokens in Node and seeding browser storage before test runs?","acceptedAnswer":{"@type":"Answer","text":"Running the full UI login form 200 times is testing the login form 200 times, when only one test actually needs to. The fix is to authenticate once, programmatically, and reuse that authenticated state everywhere else.\n\nThe cleanest version with Playwright is storageState: a single setup script logs in once (or signs a JWT with jsonwebtoken.sign() using the same secret the server uses), saves the resulting cookies to a JSON file in globalSetup, and every other test's browser context is created with storageState: 'auth.json' — so it starts already logged in.\n\n```js\n// global-setup.js\nexport default async function globalSetup(config) {\n const browser = await chromium.launch();\n const page = await browser.newPage();\n const token = jwt.sign({ userId: 'test-user' }, process.env.JWT_SECRET);\n await page.context().addCookies([{ name: 'session', value: token, url: config.projects[0].use.baseURL }]);\n await page.context().storageState({ path: 'auth.json' });\n await browser.close();\n}\n```\n\n```js\n// playwright.config.js\nuse: { storageState: 'auth.json' }\n```\n\nThis turns 200 real login flows into 1, cutting suite time dramatically, while keeping at least one real end-to-end login test elsewhere so the login UI itself doesn't go unverified."}},{"@type":"Question","name":"What is the virtual DOM and how does React use it to update the UI efficiently?","acceptedAnswer":{"@type":"Answer","text":"The virtual DOM is a lightweight, in-memory JavaScript object tree that mirrors the real DOM structure. When state changes, React builds a new virtual DOM tree, compares ('diffs') it against the previous snapshot, and computes the minimal set of actual DOM operations needed to make the real DOM match. Only that minimal patch gets applied to the real DOM.\n\nThis matters because real DOM operations are expensive (layout recalculation, repaint), while creating and comparing plain JS objects is cheap. Imagine a todo list with 1,000 items where you check off one item: without a virtual DOM, a naive re-render might touch all 1,000 DOM nodes; React's diffing figures out only one li's checkbox and class need to change, and patches just that node.\n\n```jsx\n// Before: 1000 items, item #500 toggles \"done\"\n// React diffs old vs new virtual DOM trees, finds only
changed,\n// and patches just that node's className — not all 1000
elements.\n```\n\nIt's worth being precise in an interview: the virtual DOM isn't inherently 'faster than the DOM' in some magic sense — a hand-optimized direct DOM manipulation for a known change can beat it. Its real value is a declarative programming model (describe the end state, not the mutation steps) while keeping average-case performance good, since diffing handles the optimization automatically."}},{"@type":"Question","name":"What is the difference between controlled and uncontrolled components in React?","acceptedAnswer":{"@type":"Answer","text":"A controlled component's value lives in React state — the input's value prop is set from state, and every keystroke fires onChange, which updates that state, which re-renders the input. React is the single source of truth. An uncontrolled component lets the DOM itself hold the current value, and you only read it via a ref when needed, instead of tracking every keystroke in state.\n\n```jsx\n// Controlled\nfunction ControlledInput() {\n const [value, setValue] = useState('');\n return setValue(e.target.value)} />;\n}\n\n// Uncontrolled\nfunction UncontrolledInput() {\n const inputRef = useRef(null);\n const handleSubmit = () => console.log(inputRef.current.value);\n return ;\n}\n```\n\nControlled is the default for anything you need to validate live, format as you type, or sync with other UI (a character counter, a live filter). Uncontrolled is useful for simple forms where you only care about the value on submit — it avoids a re-render on every keystroke, and is the natural fit for a plain file input, which React can't control at all since its value is read-only from JS for security reasons."}},{"@type":"Question","name":"Explain the difference between useEffect and useLayoutEffect.","acceptedAnswer":{"@type":"Answer","text":"Both run side effects after render, but at different points relative to the browser painting the screen. useEffect runs asynchronously after the browser has painted — the user can see the UI before your effect runs. useLayoutEffect runs synchronously after React has updated the DOM but before the browser paints — it blocks painting until it finishes.\n\nThe practical difference shows up when your effect needs to read layout and then synchronously adjust something before the user sees a flash of the wrong state. If you measure a tooltip's height in useEffect and reposition it, the user briefly sees it in the wrong place, then it jumps. useLayoutEffect avoids that flicker because the repositioning happens before paint.\n\n```jsx\nuseLayoutEffect(() => {\n const { height } = ref.current.getBoundingClientRect();\n if (height > maxHeight) setPosition('above'); // happens before paint, no visible flicker\n}, []);\n```\n\nThe tradeoff is useLayoutEffect blocks the browser from painting until it finishes, so overusing it for expensive work hurts perceived performance. Default to useEffect for anything that doesn't need to read/write layout synchronously (data fetching, subscriptions, logging), and reach for useLayoutEffect only for DOM measurement plus synchronous visual adjustment."}},{"@type":"Question","name":"What problem do React keys solve, and why is using an array index as a key an anti-pattern?","acceptedAnswer":{"@type":"Answer","text":"React uses the key prop to match elements in the new render to elements from the previous render, deciding which DOM nodes to reuse (preserving internal state, focus, animation) versus which to destroy and recreate. Without stable keys, React falls back to matching by position, which breaks the moment the list's order or contents change.\n\nUsing the array index as a key looks fine until the list reorders or an item is inserted/removed from the middle. Say a list [A, B, C] has keys [0, 1, 2]; delete A, and the new list [B, C] gets keys [0, 1] — React thinks 'key 0 is still B' rather than realizing A was removed and B/C shifted up. If those list items hold local state (an expanded toggle, a typed value), that state now stays attached to the wrong visual row.\n\n```jsx\n// Bad: index as key — breaks on reorder/delete\n{items.map((item, i) => )}\n\n// Good: stable, content-derived identity\n{items.map((item) => )}\n```\n\nThe fix is always a key derived from actual identity (a database _id, a UUID) — something that stays attached to the same logical item regardless of array position. Index keys are only safe for lists that are static and never reordered/filtered/mutated."}},{"@type":"Question","name":"What is prop drilling and how do Context API/state managers solve it?","acceptedAnswer":{"@type":"Answer","text":"Prop drilling is passing data through several layers of components that don't themselves use it, just to get it from a high-level ancestor to a deeply nested descendant that does. It couples every intermediate component to a prop it doesn't care about, and makes refactoring painful.\n\nContext API solves this for state that's genuinely global-ish to a subtree — theme, current user, locale — by letting any descendant read the value directly without every layer forwarding it.\n\n```jsx\nconst UserContext = createContext(null);\n\nfunction App() {\n const [user, setUser] = useState(null);\n return (\n \n {/* doesn't need `user` itself, never touches it */}\n \n );\n}\n\nfunction ProfileBadge() {\n const user = useContext(UserContext); // reads directly, no drilling through Dashboard\n return {user?.name};\n}\n```\n\nFor state that changes frequently and is read by many components, a dedicated state manager (Redux Toolkit, Zustand) is usually a better fit than Context, because Context re-renders every consumer on any value change with no built-in selector/memoization — a library gives fine-grained subscriptions so a component re-renders only when the specific slice it reads actually changes."}},{"@type":"Question","name":"Explain useMemo vs useCallback and when each is actually needed.","acceptedAnswer":{"@type":"Answer","text":"useMemo caches the return value of a computation across renders, recomputing only when its dependency array changes. useCallback caches a function reference itself — really just useMemo specialized to return a function, so it isn't recreated (a new reference) on every render.\n\n```jsx\nconst filtered = useMemo(() => items.filter(expensivePredicate), [items]);\nconst handleClick = useCallback(() => onSelect(id), [id, onSelect]);\n```\n\nThe part people get wrong is using these everywhere by default. Both have a real cost — the memoization itself takes memory and a comparison check — so they only pay off when the computation is genuinely expensive, or when a stable reference is needed to stop a child wrapped in React.memo from re-rendering unnecessarily (a new function reference on every parent render defeats React.memo's shallow comparison even if nothing meaningful changed). Wrapping a cheap inline function in useCallback 'just in case' usually adds more overhead than it saves — profile first, then memoize where it actually shows up as a bottleneck."}},{"@type":"Question","name":"What is React reconciliation and how does the diffing algorithm decide to reuse vs recreate DOM nodes?","acceptedAnswer":{"@type":"Answer","text":"React's reconciliation algorithm decides how to update the DOM by diffing the new element tree against the previous one, but it deliberately doesn't do a full, mathematically optimal tree diff (that's O(n cubed) and too slow) — it uses heuristics that are fast (O(n)) and correct for the overwhelming majority of real UI patterns.\n\nTwo rules drive it: elements of a different type at the same position get torn down and rebuilt entirely (a div becoming a span discards the whole subtree and its state), and elements of the same type get their attributes/props diffed and updated in place, preserving the DOM node and any component state. For lists, this is where key comes in — without it, React only compares by position; with stable keys, it can recognize a specific item moved and reorder the existing DOM node instead of destroying and recreating it.\n\n```jsx\n// same type at same position: patched in place, state preserved\n -> \n\n// different type at same position: torn down and rebuilt, state lost\n
...
-> ...\n```\n\nThis explains a common bug: conditionally rendering different component types at the same tree position ({isEditing ? : }) unmounts/remounts on every toggle, losing internal state — because React sees a type change, not an update."}},{"@type":"Question","name":"What are React Error Boundaries and what can/can't they catch?","acceptedAnswer":{"@type":"Answer","text":"Error boundaries are class components implementing static getDerivedStateFromError and/or componentDidCatch, which catch JavaScript errors thrown anywhere in their child component tree during rendering, and render a fallback UI instead of crashing the whole app to a white screen.\n\n```jsx\nclass ErrorBoundary extends React.Component {\n state = { hasError: false };\n static getDerivedStateFromError() { return { hasError: true }; }\n componentDidCatch(error, info) { logErrorToService(error, info); }\n render() {\n if (this.state.hasError) return ;\n return this.props.children;\n }\n}\n```\n\nWhat they explicitly do not catch: errors in event handlers (normal try/catch territory), errors in asynchronous code (setTimeout, promises, fetch callbacks), errors during server-side rendering, and errors thrown inside the boundary itself. There's no hook equivalent — you can't write a functional error boundary with just useState/useEffect — so most codebases either keep one small class wrapper or use a library like react-error-boundary that wraps that class with a hooks-friendly API."}},{"@type":"Question","name":"Explain code-splitting with React.lazy and Suspense.","acceptedAnswer":{"@type":"Answer","text":"Code-splitting breaks your JS bundle into smaller chunks that load on demand instead of all upfront, so users pay the download/parse cost only for the code the route/feature they're actually using needs. React.lazy() wraps a dynamic import() so a component's code doesn't load until it's first rendered, and Suspense lets you declare a fallback UI to show while that chunk is downloading.\n\n```jsx\nconst AdminPanel = React.lazy(() => import('./AdminPanel'));\n\nfunction App() {\n return (\n }>\n } />\n \n );\n}\n```\n\nThe most common use is route-based splitting: a marketing landing page shouldn't force users to download the admin dashboard's entire JS bundle first. Bundlers automatically generate a separate chunk for each import() call site, and the browser only fetches that chunk when someone navigates there. Common pitfalls: forgetting the Suspense boundary (lazy components must render inside one), and over-splitting tiny components where the network round-trip costs more than the bundle size saved."}},{"@type":"Question","name":"What is React 18's automatic batching and how does it differ from React 17?","acceptedAnswer":{"@type":"Answer","text":"Batching means React groups multiple state updates within the same event into a single re-render, instead of re-rendering once per setState call. In React 17, this only happened inside React's own event handlers — updates inside promises, setTimeout, or native event handlers were not batched, causing multiple separate re-renders.\n\n```jsx\n// React 17: inside a setTimeout, this causes TWO re-renders\nsetTimeout(() => {\n setCount(c => c + 1);\n setFlag(f => !f);\n}, 1000);\n\n// React 18: same code, ONE re-render — batching now happens everywhere by default\n```\n\nReact 18's automatic batching extends this everywhere — promises, timeouts, native listeners — via the new root API (createRoot). This is usually a pure performance win, but can surprise code that relied on synchronous re-renders between two state updates. For the rare case where the old synchronous behavior is needed, React 18 exposes flushSync() to opt a specific update out of batching."}},{"@type":"Question","name":"What is the Node.js event loop and how do phases like timers, poll, and check affect execution order?","acceptedAnswer":{"@type":"Answer","text":"Node's event loop is what lets a single JS thread handle many concurrent I/O operations without blocking. It runs in phases: timers (executes setTimeout/setInterval callbacks whose time has elapsed), pending callbacks, poll (retrieves new I/O events — where most callbacks like file reads and network requests fire, and where the loop can block waiting for new events), check (executes setImmediate callbacks), and close callbacks.\n\nMicrotasks (Promise .then, async/await continuations, process.nextTick) are not one of these phases — they run in a queue that fully drains between every phase transition (nextTick drains even before Promise microtasks). That's why this classic runs in a fixed order:\n\n```js\nsetTimeout(() => console.log('timeout'), 0);\nsetImmediate(() => console.log('immediate'));\nPromise.resolve().then(() => console.log('promise'));\nprocess.nextTick(() => console.log('nextTick'));\n// Output order: nextTick, promise, then timeout/immediate\n// (timeout vs immediate ordering is non-deterministic at the top level)\n```\n\nUnderstanding phases matters practically because a CPU-heavy synchronous function (a big JSON.parse, an unoptimized loop) blocks the entire event loop — no phase can advance, no timer fires, nothing — which is the real reason Node apps offload heavy computation to worker threads or a separate service instead of running it inline in a request handler."}},{"@type":"Question","name":"Explain the difference between process.nextTick, setImmediate, and setTimeout(fn, 0).","acceptedAnswer":{"@type":"Answer","text":"All three schedule a callback for later, but at different points in the event loop. process.nextTick() doesn't belong to any event loop phase — its queue is drained completely immediately after the current operation finishes, before the loop even checks microtasks or advances phases. Promise microtasks run next. setTimeout(fn, 0) and setImmediate(fn) both run in actual event loop phases (timers and check, respectively).\n\nThe order between setTimeout(fn, 0) and setImmediate(fn) at the top level is technically non-deterministic (depends on process startup overhead relative to minimum timer resolution). But inside an I/O callback, the order is deterministic: setImmediate always fires before setTimeout, because after an I/O callback completes, the loop is already past poll heading toward check, and reaches check before cycling back to timers.\n\n```js\nconst fs = require('fs');\nfs.readFile(__filename, () => {\n setTimeout(() => console.log('timeout'), 0);\n setImmediate(() => console.log('immediate')); // always logs first here\n});\n```\n\nPractically: process.nextTick defers work to run right after the current operation, before anything else — useful for keeping an API's callback timing consistent (e.g., always emitting errors asynchronously), but recursive nextTick calls can starve the event loop entirely since it fully drains before moving on."}},{"@type":"Question","name":"What is Express middleware and how does the next() function control the chain, including error-handling middleware?","acceptedAnswer":{"@type":"Answer","text":"Express middleware is a function with the signature (req, res, next) that runs in registration order, forming a pipeline. Calling next() passes control to the next middleware; not calling it (and not sending a response) leaves the request hanging forever. Calling next(err) with an argument specifically skips remaining normal middleware and jumps straight to error-handling middleware.\n\n```js\napp.use((req, res, next) => {\n console.log(req.method, req.path);\n next(); // continue\n});\n\napp.get('/users/:id', async (req, res, next) => {\n try {\n const user = await User.findById(req.params.id);\n if (!user) return res.status(404).json({ error: 'not found' });\n res.json(user);\n } catch (err) {\n next(err); // hands off to error middleware below\n }\n});\n\n// error-handling middleware: MUST have exactly 4 params —\n// Express identifies it by arity, not by name\napp.use((err, req, res, next) => {\n console.error(err);\n res.status(500).json({ error: 'internal error' });\n});\n```\n\nThe arity check is the important gotcha: an error handler with only 3 parameters is treated as regular middleware and silently never receives errors. Error middleware must also be registered last, since Express only looks forward in the stack when an error is passed to next()."}},{"@type":"Question","name":"How do you handle errors in async/await Express route handlers without try/catch boilerplate everywhere?","acceptedAnswer":{"@type":"Answer","text":"An error thrown inside an async route handler doesn't automatically become a caught Express error in Express 4 (still the most common production version) — a rejected promise that isn't awaited-and-caught just becomes an unhandled rejection, and Express never calls your error middleware, leaving the request hanging or the process crashing.\n\nWrapping every route in try/catch works but is repetitive across dozens of routes. The common fix is a small wrapper that catches the rejection and forwards it to next automatically.\n\n```js\nconst asyncHandler = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);\n\napp.get('/users/:id', asyncHandler(async (req, res) => {\n const user = await User.findById(req.params.id); // if this rejects, asyncHandler catches it\n if (!user) return res.status(404).json({ error: 'not found' });\n res.json(user);\n}));\n```\n\nThis is small enough that most teams write it once as a local utility rather than adding the express-async-errors package, though that package does the same thing by monkey-patching Express's router — either is fine, but know the underlying mechanism (unhandled promise rejection never reaches Express's error handling on its own) rather than treating the wrapper as magic."}},{"@type":"Question","name":"What is the Node.js libuv thread pool and which core APIs actually use it?","acceptedAnswer":{"@type":"Answer","text":"Node is single-threaded for your JavaScript, but not for everything under the hood — libuv maintains a thread pool (default size 4, configurable via UV_THREADPOOL_SIZE) that handles operations the OS doesn't offer a truly async, non-blocking interface for.\n\nNetwork I/O (TCP sockets, most of http) doesn't need the thread pool — modern OSes provide async socket APIs (epoll/kqueue/IOCP) the event loop's poll phase uses directly. But filesystem operations (fs.readFile on most platforms), DNS lookups via dns.lookup (not dns.resolve*, which use c-ares async directly), and some crypto functions (crypto.pbkdf2, async crypto.randomBytes) get dispatched to the thread pool, because the underlying OS APIs for these are blocking.\n\n```js\n// UV_THREADPOOL_SIZE defaults to 4 — this matters for concurrency\nprocess.env.UV_THREADPOOL_SIZE = 8; // must be set before any thread-pool work starts\n\n// bcrypt.hash and crypto.pbkdf2 both use the thread pool —\n// 5 concurrent password hashes with pool size 4 means the 5th genuinely queues and waits\n```\n\nThis is a real, non-obvious production gotcha: if your app does a lot of bcrypt.hash() calls concurrently with file uploads (also thread-pool-bound), they contend for the same 4 threads regardless of CPU core count — increasing UV_THREADPOOL_SIZE (up to roughly the core count) can meaningfully improve throughput for thread-pool-heavy workloads, a very different lever than 'add more Node processes.'"}},{"@type":"Question","name":"Why should you use the Node cluster module or a process manager like PM2, and what problem does it solve on multi-core machines?","acceptedAnswer":{"@type":"Answer","text":"Node runs your JS on a single thread, so a single Node process can only use one CPU core no matter how many cores the machine has — under real load, that leaves most of a multi-core server idle. The cluster module (or PM2's cluster mode) solves this by forking multiple Node processes — one per CPU core, typically — that share the same listening port, with the master process load-balancing incoming connections round-robin.\n\n```js\nconst cluster = require('cluster');\nconst os = require('os');\n\nif (cluster.isPrimary) {\n os.cpus().forEach(() => cluster.fork());\n cluster.on('exit', () => cluster.fork()); // restart a worker if it crashes\n} else {\n require('./app'); // each worker runs its own independent copy of the Express app\n}\n```\n\nEach worker is a fully separate process with its own memory — there's no shared in-memory state between workers, a common bug source when code relies on process-local state that behaves inconsistently depending on which worker handled a request. PM2 is usually preferred over rolling your own cluster code in production because it adds zero-downtime reloads, automatic restart on crash, log aggregation, and monitoring — cluster gives you the mechanism, PM2 (or Kubernetes replicas, solving the same problem at the infra level) gives you the operational tooling."}},{"@type":"Question","name":"What does Express's trust proxy setting do and why is misconfiguring it a security risk behind a load balancer?","acceptedAnswer":{"@type":"Answer","text":"Express's trust proxy setting controls whether Express trusts X-Forwarded-* headers set by an upstream proxy/load balancer, and uses them to determine req.ip, req.ips, req.protocol, and req.secure.\n\nBehind a load balancer (Nginx, an ALB, Cloudflare), the TCP connection Express sees comes from the proxy's IP, not the real client — so without trust proxy set, req.ip is always the load balancer's address, breaking anything relying on the real client IP (rate limiting, geo-blocking, audit logs).\n\n```js\napp.set('trust proxy', 1); // trust exactly one hop (the load balancer directly in front)\n```\n\nThe security risk is the other direction: if you naively trust X-Forwarded-For when your app is directly internet-facing (no proxy in front, or a misconfigured trust proxy: true that trusts an arbitrary number of hops), a malicious client can simply set that header themselves and spoof any IP they want — defeating IP-based rate limiting or allowlisting entirely. The correct value is the exact number of trusted proxy hops in front of your app, never a blanket true, so Express only trusts the header value your own infrastructure set, not one an attacker appended further upstream."}},{"@type":"Question","name":"What's the difference between MongoDB embedding and referencing, and how do you decide which to use?","acceptedAnswer":{"@type":"Answer","text":"Embedding nests related data directly inside a parent document as a sub-document/array; referencing stores just an ObjectId pointing to a document in another collection, resolved via populate() or a separate query.\n\nEmbed when the data is always read together, doesn't grow unbounded, and doesn't need independent querying — a blog post's few comments, an order's line items, a user's address.\n\n```js\n// Embedded: address only ever makes sense attached to this user\n{ _id: ..., name: 'Alice', address: { street: '...', city: '...' } }\n\n// Referenced: a post can have thousands of comments, queried/paginated independently\n{ _id: ..., title: '...', authorId: ObjectId('...') } // in posts\n{ _id: ..., postId: ObjectId('...'), text: '...' } // in comments, separate collection\n```\n\nReference when the related data is large/unbounded (thousands of comments risk hitting the 16MB document limit and drag along all comments on every post read), is shared across multiple parents (a product referenced by many orders), or needs independent querying/updating without touching the parent. Most real schemas mix both: reference for the one-to-many-unbounded relationship, embed for small, tightly-coupled sub-objects."}},{"@type":"Question","name":"Explain how MongoDB indexes work and how to diagnose a slow query with explain().","acceptedAnswer":{"@type":"Answer","text":"An index is a separate, ordered data structure (a B-tree by default) mapping field values to document locations, letting a query find matches by index lookup instead of scanning every document (COLLSCAN). Without an index on a filtered/sorted field, MongoDB examines every document — fine for 500 documents, ruinous for 50 million.\n\nexplain('executionStats') shows exactly what MongoDB did to execute a query — the two numbers that matter most are totalDocsExamined vs nReturned. If those are wildly different (examined 2 million to return 12 results), that's the signature of a missing or wrong index.\n\n```js\ndb.orders.find({ userId: ObjectId('...'), status: 'pending' }).explain('executionStats');\n// look at: winningPlan.stage ('COLLSCAN' = bad, 'IXSCAN' = using an index)\n// and executionStats.totalDocsExamined vs nReturned\n\ndb.orders.createIndex({ userId: 1, status: 1 }); // compound index matching the query shape\n```\n\nField order in a compound index matters: an index on { userId: 1, status: 1 } efficiently serves queries filtering on userId alone, or userId + status together, but not a query filtering on status alone — the index is only usable as a prefix match, so ordering fields from most-selective/most-commonly-filtered-alone to least is the general design rule."}},{"@type":"Question","name":"What is the aggregation pipeline in MongoDB and how does it differ from find() queries?","acceptedAnswer":{"@type":"Answer","text":"find() returns documents matching a filter, optionally shaped with projection/sort/limit — a single query with a fixed set of modifiers. The aggregation pipeline is a sequence of stages, each transforming the data and passing its output to the next, letting you do things find() can't: grouping and computing aggregates ($group, $sum, $avg), joining across collections ($lookup), and reshaping documents, all in one round-trip.\n\n```js\ndb.orders.aggregate([\n { $match: { status: 'completed' } }, // like a find() filter\n { $group: { _id: '$userId', total: { $sum: '$amount' } } }, // group + aggregate\n { $sort: { total: -1 } },\n { $limit: 10 }\n]);\n// -> top 10 users by total completed order value, computed entirely in MongoDB\n```\n\nThe performance principle: push $match and $limit as early in the pipeline as possible, ideally before expensive stages like $lookup or $group — an early $match on an indexed field lets MongoDB use the index to shrink the working set, whereas a $match placed after a $group operates on already-computed, unindexed output and can't benefit from any index at all."}},{"@type":"Question","name":"What are MongoDB transactions and when are they actually necessary given documents are already atomic?","acceptedAnswer":{"@type":"Answer","text":"Individual document writes in MongoDB are already atomic — an update to a single document, even touching multiple fields or nested arrays, either fully succeeds or fully fails. That covers a surprising number of cases people reach for transactions for unnecessarily; good schema design (embedding related data so one atomic write covers what you need) is often the better fix.\n\nTransactions become necessary when a single logical operation must atomically span multiple documents, potentially across collections — the classic example is a funds transfer: debiting one account and crediting another must either both happen or neither, and no single-document update can guarantee that across two separate documents.\n\n```js\nconst session = client.startSession();\ntry {\n await session.withTransaction(async () => {\n await accounts.updateOne({ _id: fromId }, { $inc: { balance: -amount } }, { session });\n await accounts.updateOne({ _id: toId }, { $inc: { balance: amount } }, { session });\n });\n} finally {\n await session.endSession();\n}\n```\n\nMulti-document transactions require a replica set (or sharded cluster) — they don't work on a standalone instance — and carry real overhead, so reach for them when correctness genuinely requires cross-document atomicity, not as a default safety blanket around every multi-step write."}},{"@type":"Question","name":"Explain the N+1 query problem with Mongoose populate() and how to avoid it.","acceptedAnswer":{"@type":"Answer","text":"The N+1 problem with populate() happens the same way it does in any ORM: you fetch N parent documents, and instead of one batched follow-up query, code issues one extra query per parent to resolve related data — N+1 total queries where 1 or 2 would do.\n\n```js\n// N+1: one query for posts, then one lookup PER post inside a loop\nconst posts = await Post.find();\nfor (const post of posts) {\n post.author = await User.findById(post.authorId); // N extra round-trips\n}\n```\n\nMongoose's built-in .populate() is actually not naively N+1 when used correctly — it batches all referenced ids into a single $in query behind the scenes.\n\n```js\n// Correct: Mongoose batches this into ONE extra query (User.find({ _id: { $in: [...] } }))\nconst posts = await Post.find().populate('author');\n```\n\nThe N+1 bug shows up specifically when someone bypasses populate() and manually loops with individual lookups, or chains multiple nested populates without realizing each level still adds another batched-but-separate round trip. The fix is always the same shape: replace any per-document loop that does an async DB call with populate() (single batched $in query) or, where populate can't express it, your own explicit $in query against the collected foreign keys, done once."}},{"@type":"Question","name":"What is a covered query in MongoDB and why is it faster?","acceptedAnswer":{"@type":"Answer","text":"A covered query is one where every field the query needs — both filter conditions and projected output fields — exists entirely within a single index, so MongoDB can answer it by reading only the index and never fetching the actual document (no FETCH stage in the execution plan).\n\n```js\ndb.users.createIndex({ email: 1, status: 1 });\n\n// Covered: filters on email+status (both indexed), projects ONLY email+status\ndb.users.find({ email: '[email protected]', status: 'active' }, { _id: 0, email: 1, status: 1 });\n\n// NOT covered: projects 'name', which isn't in the index — requires a document fetch\ndb.users.find({ email: '[email protected]' }, { _id: 0, name: 1 });\n```\n\nIt's faster because index entries are typically much smaller than full documents and already sorted for fast lookup, so skipping the document fetch avoids extra I/O. You can confirm a query is covered by checking explain() for totalDocsExamined: 0 alongside a nonzero totalKeysExamined. Note _id is included by default unless explicitly excluded, so forgetting to exclude it is the most common reason a query that 'should' be covered isn't."}},{"@type":"Question","name":"Explain MongoDB replica sets and how automatic failover works.","acceptedAnswer":{"@type":"Answer","text":"A replica set is a group of MongoDB nodes (typically 3+, an odd number to avoid tie votes) holding the same data: one primary accepting all writes, and one or more secondaries continuously replicating the primary's oplog and able to serve reads if the client opts in.\n\nIf the primary becomes unreachable, the remaining nodes hold an election and promote one secondary to primary, typically within a few seconds. Clients using the official MongoDB drivers (including Mongoose) are replica-set aware: they maintain a connection to the whole set, detect the primary change via driver monitoring, and redirect subsequent writes to the newly elected primary automatically — though in-flight requests during the failover window still see a transient error and need a retry (retryWrites: true handles this automatically for many operations).\n\n```js\nmongoose.connect('mongodb://host1,host2,host3/mydb?replicaSet=rs0&retryWrites=true');\n```\n\nThis is also the underlying mechanism required for Change Streams and multi-document transactions — both need an oplog to build on, which only exists in a replica-set (or sharded cluster) configuration, never a standalone instance."}},{"@type":"Question","name":"What is sharding in MongoDB and how do you choose a shard key?","acceptedAnswer":{"@type":"Answer","text":"Sharding is MongoDB's horizontal scaling mechanism: instead of one server holding the entire dataset, data is partitioned across multiple shards (each typically its own replica set), and a routing layer (mongos) directs each query to only the shard(s) that could contain relevant data, based on a chosen shard key.\n\nThe shard key is the single most consequential decision, and it's expensive to change later. A good shard key has high cardinality (many distinct values, spreading data evenly) and matches your query patterns (queries including the shard key can be routed to a single shard — 'targeted' — while queries omitting it fan out to every shard and merge results).\n\n```js\nsh.shardCollection('mydb.orders', { customerId: 'hashed' });\n// hashed shard key: spreads writes evenly, avoids hotspotting one shard,\n// but range queries on customerId now have to scan multiple shards\n```\n\nA common mistake is choosing a monotonically increasing key (a timestamp or auto-incrementing id) as the shard key — all new writes land on whichever shard owns the highest range, creating a hot shard that absorbs 100% of write traffic while others sit idle, defeating the point of sharding. A hashed shard key avoids that hotspot at the cost of losing efficient range queries on that field."}},{"@type":"Question","name":"What are Mongoose virtuals and discriminators, and when would you use discriminators for polymorphic data?","acceptedAnswer":{"@type":"Answer","text":"A Mongoose virtual is a property that exists on the document in application code but is never persisted to MongoDB — computed on the fly from other real fields, like a fullName virtual computed from stored firstName/lastName so you don't duplicate data just to make it convenient to read.\n\n```js\nuserSchema.virtual('fullName').get(function () {\n return `${this.firstName} ${this.lastName}`;\n});\n```\n\nDiscriminators let multiple related-but-different document shapes live in the same underlying collection while getting separate schemas/validation/methods each — useful for polymorphic data like a Notification model where EmailNotification and PushNotification share common fields but each has type-specific fields.\n\n```js\nconst options = { discriminatorKey: 'kind' };\nconst Notification = mongoose.model('Notification', new Schema({ userId, read: Boolean }, options));\n\nconst EmailNotification = Notification.discriminator('Email', new Schema({ subject: String }));\nconst PushNotification = Notification.discriminator('Push', new Schema({ deviceToken: String }));\n// all stored in the same 'notifications' collection, distinguished by 'kind',\n// but each discriminator gets its own validation and query/create model\n```\n\nThis avoids either one giant schema with a pile of type-irrelevant optional fields, or entirely separate collections that lose the ability to query 'all notifications for this user' sorted by date across types."}},{"@type":"Question","name":"What's the pitfall of using an arrow function for a Mongoose pre-save hook?","acceptedAnswer":{"@type":"Answer","text":"Mongoose middleware relies on this being bound to the document instance the hook runs against — that's how you read/modify the document's own fields inside the hook. Arrow functions don't have their own this; they lexically inherit it from the enclosing scope, which in a top-level schema definition is not the document at all.\n\n```js\n// Broken: arrow function — `this` is NOT the document being saved\nuserSchema.pre('save', () => {\n this.updatedAt = Date.now(); // silently does nothing useful, or throws\n});\n\n// Correct: regular function — `this` is the document\nuserSchema.pre('save', function (next) {\n this.updatedAt = Date.now();\n next();\n});\n```\n\nThis is an easy mistake because arrow functions are the default style almost everywhere else in modern JS, and the code doesn't throw an obvious error — it just silently fails to do what you meant, which makes it a good interview question precisely because it tests whether someone understands this-binding rather than just having memorized the Mongoose API. The same applies to instance methods defined on schema.methods — always a regular function, never an arrow, whenever the code needs this to refer to the document."}},{"@type":"Question","name":"Explain write concern and read concern in MongoDB and the tradeoff with performance.","acceptedAnswer":{"@type":"Answer","text":"Write concern controls how many nodes in a replica set must acknowledge a write before MongoDB reports it as successful — a durability-vs-latency dial. { w: 1 } (default) only waits for the primary, which is fast but means a primary crash right after acknowledging (before replication catches up) can lose that write. { w: 'majority' } waits for a majority of the set, surviving a primary failure at the cost of extra latency.\n\nRead concern controls what guarantee a read gives. 'local' (default) can return data that hasn't been majority-replicated yet, meaning a subsequent failover could theoretically roll it back. 'majority' only returns data confirmed on a majority of nodes; 'linearizable' gives the strongest guarantee at the highest latency cost.\n\n```js\n// A payment write: durability matters more than a few extra ms of latency\nawait db.collection('payments').insertOne(doc, { writeConcern: { w: 'majority' } });\n\n// A high-frequency analytics counter: default is fine, durability of any single write barely matters\nawait db.collection('pageViews').updateOne(filter, { $inc: { count: 1 } });\n```\n\nThe interview-relevant tradeoff: don't blanket-apply w: 'majority' everywhere 'to be safe' — it adds real latency to every write, so the right call is per-collection based on how bad losing that specific write actually is."}},{"@type":"Question","name":"What's the difference between JWTs and server-side sessions for authentication, and when would you pick one over the other?","acceptedAnswer":{"@type":"Answer","text":"Server-side sessions store the actual session data in a database or in-memory store keyed by a random session id, and the client just holds that opaque id (usually a cookie) — the server looks the data up on every request. JWTs instead encode the data directly into a signed token the client holds; the server verifies the signature and trusts the payload without a database lookup.\n\nSessions are trivially revocable — delete the session record server-side and the user is instantly logged out everywhere. JWTs are stateless by design, which scales better (no shared session store, no per-request lookup), but that same statelessness makes revocation hard: a JWT is valid until it expires, unless you build your own tracking layer on top (a blocklist, or the short-lived-access + database-checked-refresh pattern), at which point you've reintroduced a database lookup anyway.\n\n```\nSession: client holds session_id=abc123 -> server looks up abc123 in Redis/Mongo -> { userId, roles }\nJWT: client holds eyJhbGciOiJIUzI1NiJ9... -> server verifies signature -> payload trusted directly\n```\n\nThe practical MERN default: use short-lived JWTs for stateless API authorization, paired with a database-backed refresh token specifically so you retain the ability to revoke a compromised session — pure stateless JWTs with no revocation path are rarely right beyond a toy app."}},{"@type":"Question","name":"REST vs GraphQL: what tradeoffs matter when choosing for a MERN app?","acceptedAnswer":{"@type":"Answer","text":"REST models your API as resources at fixed URLs, each returning a fixed shape of data. GraphQL exposes a single endpoint with a typed schema, and the client specifies exactly which fields it wants — the server returns precisely that shape.\n\nThis solves REST's two classic pain points: over-fetching (a /users/:id endpoint returning 20 fields when the UI needs 3) and under-fetching/N+1 round trips (a screen needing a user, their last 5 posts, and each post's comment count might need 3+ REST calls). One GraphQL query expresses all of that in a single request.\n\n```graphql\nquery {\n user(id: \"123\") {\n name\n posts(limit: 5) {\n title\n commentCount\n }\n }\n}\n```\n\nThe tradeoffs that matter: GraphQL shifts complexity from many small REST endpoints to one schema/resolver layer, which needs its own N+1-avoidance tooling (DataLoader) or you relocate the same problem instead of solving it. Caching is also harder — REST gets HTTP-level caching almost free (GET + Cache-Control + CDNs), while GraphQL's single-endpoint nature means application-level caching instead. For a MERN app with a small number of well-known screens, REST is often simpler to build and cache; GraphQL earns its complexity when many different clients need very different shapes of the same data."}},{"@type":"Question","name":"How do WebSockets differ from HTTP polling/long-polling, and when is Socket.io overkill?","acceptedAnswer":{"@type":"Answer","text":"HTTP polling means the client repeatedly asks the server 'anything new?' on a fixed interval, whether or not anything changed — simple, but wasteful and inherently laggy (average delay is half the poll interval). Long-polling improves this by having the server hold the request open until there's something to send, but still reopens a new HTTP request after every response.\n\nWebSockets open a single persistent, full-duplex connection — after the initial handshake upgrades it, either side can push messages at any time with no repeated request/response overhead, and latency is near-instant.\n\n```js\n// Polling: simple, but wasteful and laggy\nsetInterval(() => fetch('/api/messages/latest').then(updateUI), 3000);\n\n// WebSocket (Socket.io): server pushes the instant something happens\nsocket.on('newMessage', (msg) => updateUI(msg));\n```\n\nSocket.io is overkill when you don't need bidirectional, low-latency push — a dashboard fine refreshing every 30 seconds is simpler and cheaper with plain polling (no persistent connections to manage at scale, no sticky-session complications). Reach for WebSockets when the product genuinely needs real-time (chat, live cursors, collaborative editing) — the operational cost is worth paying because polling can't deliver the latency needed, not as a default for 'live-ish' data."}},{"@type":"Question","name":"How do you design an idempotent POST endpoint in Express to safely handle duplicate network retries?","acceptedAnswer":{"@type":"Answer","text":"A network retry (client timeout, a dropped connection, a load balancer retry) can cause the exact same POST to arrive twice. For a non-idempotent operation like 'create an order' or 'charge a card,' processing it twice means a duplicate order or duplicate charge — a real user-facing bug.\n\nThe standard fix is an idempotency key: the client generates a unique key (a UUID) once per logical operation and sends it as a header on every attempt/retry. The server checks whether it has already processed that key before doing any real work — if so, it returns the original response instead of repeating the operation.\n\n```js\napp.post('/orders', async (req, res) => {\n const idempotencyKey = req.headers['idempotency-key'];\n const existing = await IdempotencyRecord.findOne({ key: idempotencyKey });\n if (existing) return res.status(existing.statusCode).json(existing.responseBody);\n\n const order = await Order.create(req.body);\n const responseBody = { orderId: order._id };\n await IdempotencyRecord.create({ key: idempotencyKey, statusCode: 201, responseBody });\n res.status(201).json(responseBody);\n});\n```\n\nThe tricky part is the race between checking for an existing key and creating the record — under real concurrency, you need a unique index on the idempotency key so a duplicate insert fails at the database level, and you catch that error and return the existing result, rather than relying on the read-then-write check alone, which has a race window."}},{"@type":"Question","name":"How would you debounce a search-as-you-type React input to avoid hammering an Express/MongoDB text search endpoint?","acceptedAnswer":{"@type":"Answer","text":"Firing a network request on every keystroke means a five-character query generates five separate requests, most wasted — the server processes a query for 'r', then 're', then 'rea', when only the final one matters.\n\nDebouncing delays firing the request until the user pauses typing for a set interval, canceling any pending timer if a new keystroke arrives first — so a burst of fast typing collapses into one request.\n\n```jsx\nfunction useDebouncedValue(value, delayMs) {\n const [debounced, setDebounced] = useState(value);\n useEffect(() => {\n const timer = setTimeout(() => setDebounced(value), delayMs);\n return () => clearTimeout(timer); // cancel if value changes before the delay elapses\n }, [value, delayMs]);\n return debounced;\n}\n\nfunction SearchBox() {\n const [query, setQuery] = useState('');\n const debouncedQuery = useDebouncedValue(query, 300);\n useEffect(() => {\n if (debouncedQuery) fetch(`/api/search?q=${debouncedQuery}`).then(() => {});\n }, [debouncedQuery]);\n return setQuery(e.target.value)} />;\n}\n```\n\nOn top of debouncing, it's worth also cancelling any in-flight request that's now stale (via AbortController) when a newer one fires — otherwise a slow response to an earlier, outdated query can arrive after a faster response to a more recent one and overwrite the UI with stale results, a race condition independent of the debounce delay itself."}}]}
50+ Real Questions
MERN Stack Interview Questions & Answers
Commonly-asked and hard-to-find MERN Stack interview questions, each with a clear, example-based answer.
