This Node.js skills test guide is for hiring managers and recruiters who need to know whether a backend candidate can build and run real Node services. Below you'll find what to measure at each level, 9 original sample questions with answers, a comparison of test formats, and a 1 to 4 scoring rubric. Pick five or six questions that match the level you're hiring for.
What a Node.js skills test should measure
Weight async control flow most heavily. Mistakes there often show up as silent data bugs rather than crashes, so they slip past code review and into production.
Sample Node.js test questions
The questions mix three formats: concept checks, debugging from a short snippet, and practical scenarios. They're different from the ones in our Node.js interview questions, so you can use both sets without repeats.
1. Junior, concept: why is Buffer.from('café').length 5 when 'café'.length is 4?
What good looks like: a string's length counts UTF-16 code units, while a Buffer holds bytes. Buffer.from encodes as UTF-8 by default, and "é" takes two bytes in UTF-8, so the buffer is 5 bytes long. It matters for upload size limits and the Content-Length header. Strong candidates mention Buffer.byteLength() for measuring size before encoding.
2. Junior, debugging: this code logs "done" before any record is saved. Why? items.forEach(async (item) => { await save(item); }); console.log('done');
What good looks like: forEach ignores the promise each callback returns, so nothing waits for the saves. The log runs right away, and any failed save turns into an unhandled rejection. The fix is a for...of loop with await to save one at a time, or await Promise.all(items.map(save)) to save in parallel, with a concurrency cap if the list is long.
3. Junior, reasoning: a teammate set ENABLE_CACHE=false, but the cache is still on. The code is if (process.env.ENABLE_CACHE). What's wrong?
What good looks like: environment variables are always strings or undefined. "false" is a non-empty string, so it's truthy. Compare explicitly, as in process.env.ENABLE_CACHE === 'true', and convert numbers with Number(). The best answers parse all config in one module that fails fast at startup.
4. Mid, reasoning: a service crashes with "Unhandled 'error' event" from a file stream. Why does one missing listener take down the whole process?
What good looks like: EventEmitter treats the 'error' event specially. If it's emitted and no listener is attached, the emitter throws, and with nothing to catch it, the process exits. Attach error handlers, or use pipeline() from stream/promises, which forwards errors and cleans up every stream in the chain.
5. Mid, debugging: an Express route sometimes logs ERR_HTTP_HEADERS_SENT. The handler is if (!user) res.status(404).json({ error: 'not found' }); res.json(user);
What good looks like: the 404 branch sends a response but doesn't return, so the code keeps going and tries to send a second response. The fix is return res.status(404).json(...) or an else branch. Calling next() after responding causes the same error.
6. Mid, concept: what versions can npm install for "^4.17.0", "~4.17.0" and "^0.4.2"?
What good looks like: the caret allows any change that keeps the left-most non-zero number: ^4.17.0 means at least 4.17.0 and below 5.0.0. The tilde allows patch updates only: ~4.17.0 means at least 4.17.0 and below 4.18.0. For 0.x versions the caret is stricter, so ^0.4.2 means at least 0.4.2 and below 0.5.0. The lockfile pins the exact versions actually installed.
7. Mid to senior, scenario: your in-memory rate limiter allows 100 requests a minute per user. After scaling to four instances behind a load balancer, some users get through up to about 400. Why, and what do you change?
What good looks like: each process keeps its own counter, so a user whose requests spread across instances gets four separate budgets, and every restart or deploy resets the count. Move the counter to a shared store with atomic increments and expiry, such as Redis, or enforce the limit at the gateway. Strong candidates also decide what happens when the shared store is down.
8. Senior, design: an endpoint builds a PDF report that takes 40 seconds. Requests time out at the load balancer, and users click again. Design a better flow.
What good looks like: accept the request and return 202 Accepted with a job ID. Put the job on a queue, let a separate worker build the PDF, and let the client poll a status endpoint or get notified, then download from a link. Make job creation idempotent with an idempotency key, so repeat clicks don't start duplicates, and add retry limits and timeouts. Workers then scale on their own while the API stays fast.
9. Senior, debugging: under load, requests hang for 30 seconds and then fail, and the database is at its connection limit. You run 20 instances, each with a pool of 25. What's going on?
What good looks like: 20 times 25 is 500 possible connections, which can be more than the database allows, so instances wait for a free connection until they time out. Also look for leaks: a connection checked out and never released on an error path, fixed by releasing in a finally block or using the pool's own query helper. Then size each pool from the database limit divided by the instance count, leaving headroom for admin access, or add a connection pooler, and alert on pool wait time.
Test formats compared
Most teams pair a short screen for every applicant with a work sample for the few who pass. Decide your AI tool rules in advance; our guide on how to detect AI interview cheating covers the options. If you're new to the term, see what a technical screen is for.
Scoring rubric
Score each question on its own, and note one line of evidence per score so a second reviewer can check it.
Running a Node.js test with NTRVSTA
Node.js is part of NTRVSTA's exam library. Our live AI interviewer asks questions in this style and adapts the difficulty to each answer: a candidate who spots the forEach bug quickly moves on to pool sizing, while one who struggles gets a simpler follow-up. It can offer a hint and see what the candidate does with it, and it follows up on reasoning instead of accepting a correct keyword. For senior roles, the system-design whiteboard lets candidates sketch a design like the queue and worker flow in question 8.
Your engineers get a score breakdown (technical skills, English proficiency and communication), video snippets of the key moments and a shareable report, then decide who moves on to a live exercise. If you mainly want automated coding tests, compare options in our guide to coding assessment tools. Related tests: JavaScript and DevOps. Writing the job post too? Start from our software engineer job description template.
Questions
How long should a Node.js skills test be?
For a first round, 30 to 45 minutes covers five or six questions with follow-ups. Save longer work samples for later stages, when fewer candidates are left and the extra time is easier to justify.
Should candidates be allowed to use AI tools during a Node.js test?
Decide per stage and tell every candidate up front. In a first-round reasoning test, ask them not to, because you want their own understanding. In a work sample, allowing an AI assistant can mirror the real job, so score how well they check and correct its output.
What if a candidate knows another backend language but not much Node?
Score the skills that transfer, such as HTTP, databases, testing and concurrency, separately from Node specifics. For many roles, a gap in fundamentals matters more than a gap in Node trivia.
Want to watch an adaptive Node.js interview from the candidate side? Try a sample interview yourself, or book a 20-minute demo with our team.
