yoklainterview sim
ProgressHistory

Backend Nodejs Memory Performance Interview Questions

75 verified Backend Nodejs Memory Performance interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Nodejs Memory PerformanceDifficulty 1
In Node.js, what does process.memoryUsage().heapUsed represent?
  • aThe total memory (RSS) the Node.js process occupies in the operating system, including buffers and native code
  • bThe maximum heap size Node.js is allowed to ever use, set by the --max-old-space-size flag
  • cThe amount of memory currently used by objects living on the V8 JavaScript heap✓
  • dThe amount of memory freed by the last garbage collection cycle
Explanation:heapUsed reports the bytes currently occupied on V8's JavaScript heap at the moment the call is made — mostly live objects, though it can also include garbage not yet reclaimed by the next collection cycle. It is distinct from rss (the whole process's resident memory, including native buffers and code), heapTotal (memory V8 has allocated for the heap, whether used or not), and it is not a delta produced by garbage collection.
Nodejs Memory PerformanceDifficulty 2
let cache = {};

function handleRequest(id, data) {
  cache[id] = data;
}

This function is called on every incoming request with a unique id. Over a long-running server process, what is the most likely effect on memory?
  • acache grows without bound since entries are never removed, keeping every data object reachable forever✓
  • bNone — objects assigned to a plain object's properties are automatically cleaned up once the request finishes
  • cV8 automatically evicts the oldest entries once cache exceeds a fixed size limit
  • dOnly the most recent 100 entries are kept because V8's garbage collector caps object property counts
Explanation:cache is a plain object referenced from module scope, so as long as the module is loaded, cache and everything assigned onto it stay reachable. Since id is unique per request and nothing ever deletes old keys, this is a classic unbounded-cache memory leak: memory usage climbs steadily with request volume.
Nodejs Memory PerformanceDifficulty 2
function makeLogger() {
  const bigBuffer = new Array(1000000).fill('x');
  return function log(msg) {
    console.log(msg);
  };
}

const logger = makeLogger();

bigBuffer is never used inside log. After makeLogger() returns and logger is kept alive, what happens to bigBuffer?
  • aIt becomes eligible for garbage collection immediately, since log never references it✓
  • bIt is copied by value into log's own private scope, so the original array sitting in makeLogger gets freed the moment the function returns
  • cIt is automatically moved to Node's old generation heap and frozen there, permanently, never eligible for collection again under any circumstance
  • dIt stays reachable via the closure's outer scope for as long as logger is reachable, even though log itself never touches it
Explanation:A closure only keeps alive the specific variables it actually references, not every variable declared in its enclosing scope. V8 determines at compile time which outer variables a function body captures; since log never touches bigBuffer, V8 has no reason to keep it reachable through log's closure. Once makeLogger() returns, bigBuffer has no other reference keeping it alive and becomes eligible for garbage collection immediately — this differs from the case where a sibling closure over the same scope does use the variable, which can keep it alive.
Nodejs Memory PerformanceDifficulty 1
Which statement correctly describes memory management in Node.js?
  • aDevelopers must manually call delete on every object they create, or the process will crash
  • bMemory is managed automatically by V8's garbage collector; there is no manual free()-style API for regular JS objects✓
  • cNode.js requires calling process.free(obj) to release memory held by an object
  • dGarbage collection is entirely optional in Node.js and must be explicitly enabled with a command-line flag before it will ever run at all
Explanation:Node.js runs on V8, which manages memory automatically through garbage collection: objects are freed once they become unreachable, without any manual free()-style call from application code. There is no process.free() API, delete only removes an object property (not the object itself), and garbage collection is always on by default, not an opt-in feature.
Nodejs Memory PerformanceDifficulty 2
function startTicker() {
  const state = { count: 0 };
  setInterval(() => {
    state.count++;
  }, 1000);
}

startTicker();

startTicker() is called once and its return value is discarded. What happens to state and the interval it created?
  • aThe interval keeps running forever (unless cleared), and its callback's closure keeps state reachable indefinitely✓
  • bBoth are garbage collected right away, since nothing outside startTicker references them
  • cNode.js automatically clears intervals that have no external reference to their return value
  • dstate is collected right after the very first tick fires, but the interval itself keeps running forever with count permanently fixed at 0
Explanation:setInterval registers its callback with Node's timer subsystem, which holds a reference to that callback until clearInterval is called. Since the callback closes over state, state stays reachable through that closure for as long as the interval keeps firing — nothing here ever calls clearInterval, so both the timer and state live for the rest of the process's lifetime.
Nodejs Memory PerformanceDifficulty 2
const { EventEmitter } = require('events');
const bus = new EventEmitter();

function onRequest() {
  bus.on('data', () => {
    console.log('handling data');
  });
}

for (let i = 0; i < 15; i++) {
  onRequest();
}

What is the most likely observable effect of running this loop?
  • aNothing unusual happens at all — EventEmitter silently ignores any duplicate listener functions registered for the exact same event name
  • bA TypeError is thrown synchronously the moment the 11th listener gets registered on that emitter instance
  • cA MaxListenersExceededWarning is printed, since more than the default 10 listeners were added to the 'data' event on one emitter✓
  • dOnly the first 10 listeners are kept; calls 11 through 15 are silently dropped
Explanation:EventEmitter instances default to a maximum of 10 listeners per event, purely as a leak-detection heuristic. Registering the 11th listener for 'data' on the same bus instance already exceeds that default and triggers a MaxListenersExceededWarning on the process's stderr — it is a warning, not an error, and every listener added (all 15 of them) is still kept and will still fire.

By specialization

C#/.NET 450Go 450Java 450Node.js 450PHP 450Python 450

By seniority

Backend JuniorBackend MidBackend Senior

Other fields

FrontendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3300-question Backend bank.

Start interview