How to assess · For hiring teams

How to Assess Node.js Skills When Hiring

The test formats that actually work for Node.js, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess Node.js with a task, not a conversation: debug a small failing service, build a small api with a constraint, ai-scored assessment (e.g. cohesyve) or architecture conversation with a production scenario. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Never leaves a promise unhandled; understands what an unhandled rejection does to the process
Keeps CPU-heavy work off the event loop and can explain why a synchronous loop stalls every request
Uses streams for large payloads instead of buffering, and understands backpressure
Designs error handling so that operational errors are handled and programmer errors crash loudly

Build a Node.js assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

Node.js is where a lot of production incidents come from, and most of them trace back to the same handful of misunderstandings: an unawaited promise, a blocking call on the event loop, an unhandled rejection that took the process down, a stream that buffered a 2GB file into memory. None of these show up in a conversation about frameworks. They show up when you hand a candidate a small service with a bug in it, or ask them to build one and watch what they do under load. This page covers how to assess Node.js as it is actually used in backend work: async correctness, the event loop, streams, error handling and operational sense.

Why Node.js is worth testing

Node.js is easy to start with and unforgiving in production. A developer who has shipped Express endpoints for two years may never have reasoned about backpressure, memory under load, or what happens when the database is slow. Testing separates people who understand the runtime from people who have used a framework on top of it. The second group writes code that works in development and fails at 2am, and the on-call rota pays for it.

What strong Node.js looks like

Never leaves a promise unhandled; understands what an unhandled rejection does to the process
Keeps CPU-heavy work off the event loop and can explain why a synchronous loop stalls every request
Uses streams for large payloads instead of buffering, and understands backpressure
Designs error handling so that operational errors are handled and programmer errors crash loudly
Reasons about concurrency: `Promise.all` versus sequential awaits, and when either is wrong
Knows what to put in middleware and what not to
Thinks about graceful shutdown, health checks and timeouts as part of the code, not the deployment

Ways to assess Node.js

Debug a small failing service

Provide a 200-line HTTP service with three planted defects: an unawaited async call, a synchronous file read in a hot path, and an error handler that swallows failures. Ask the candidate to find and fix them and explain the impact of each.

Pros

Tests runtime understanding directly; the bugs are the ones that cause real incidents.

Cons

A candidate who has seen the classic bugs may pattern-match without deep understanding — follow up with "why".

Best for Mid and senior backend roles.

Build a small API with a constraint

Ask for an endpoint that accepts a large CSV upload and returns aggregated results, with a memory limit stated up front. Sixty to ninety minutes, or a capped take-home.

Pros

Forces a streams-versus-buffering decision and shows how they structure a service from scratch.

Cons

Time pressure favours people who have done exactly this; a take-home is harder to verify.

Best for Roles that build services rather than only maintain them.

AI-scored assessment (e.g. Cohesyve)

Generate a Node.js task from the job description — a debugging scenario, a design question about a queue consumer, or a code review — with a rubric. Each candidate gets a different variant; reasoning is scored alongside code.

Pros

Consistent across a large pool; unique per candidate; scores the explanation of event-loop and error-handling decisions.

Cons

Cannot observe a candidate running a real load test; keep a human read for finalists.

Best for Screening before interviews when applicant volume is high.

Architecture conversation with a production scenario

Describe a real symptom — p99 latency spikes every few minutes, memory climbing until restart — and ask how they would investigate and what they suspect.

Pros

Reveals operational experience and diagnostic method quickly.

Cons

Talk-based; verify with a hands-on task for anyone below senior.

Best for Senior and lead engineers with on-call responsibility.

Cohesyve

Run a Node.js assessment on your next opening

Cohesyve generates a unique Node.js task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Async correctness

Whether their promise handling is right under the conditions that break it.

Find the unawaited promise in a handler and explain what the client seesRewrite a sequential chain of independent awaits to run concurrently, and say when you would notAdd a timeout to an upstream call without leaking the pending work

Event loop and performance

Whether they know what blocks the loop and what to do about it.

Identify the synchronous call stalling a request handlerMove a CPU-heavy transform to a worker and explain the trade-offExplain why a `for` loop over a million items freezes every other request

Streams and memory

Whether they can handle large data without loading it all.

Pipe an upload to storage without bufferingExplain backpressure and show where a naive pipe breaksProcess a large file line by line with bounded memory

Errors and operations

Whether the service fails safely and tells you why.

Distinguish operational errors from programmer errors in a handler and treat each correctlyAdd graceful shutdown that drains in-flight requestsWrite the health check that a load balancer should actually use

Sample Node.js questions

What happens if a promise rejects and nothing catches it in a Node process?

Entry

Look for Knows the process can crash (default in modern Node), knows why that is preferable to silent failure, and mentions where to handle it instead.

This handler reads a file with `fs.readFileSync`. What is the impact under load, and what would you change?

Entry

Look for Explains event-loop blocking in concrete terms — every request waits — and moves to the async API or a stream.

Design an endpoint that accepts a 5GB upload on a container with 512MB of memory.

Mid

Look for Streams end to end, backpressure, no full buffering, and a thought about where the data ultimately lives.

Memory in your service grows steadily until it restarts every six hours. How do you find the cause?

Senior

Look for Heap snapshots over time, suspicion of caches, listeners or closures holding references, and a way to reproduce locally.

How would you make a queue consumer safe to run with multiple replicas?

Senior

Look for Idempotency, visibility timeouts or acks, handling duplicate delivery, and what happens on a crash mid-message.

Red flags

Cannot explain the event loop beyond "it is single-threaded"
Treats `async/await` as syntax with no idea what an unhandled rejection does
Buffers whole files or responses into memory by default
Wraps everything in try/catch that logs and continues
Has never looked at a heap snapshot or a flame graph on a service they ran

Scoring rubric

Criterion	Weight	What strong looks like
Async correctness	30%	Every promise is handled; concurrency is deliberate; timeouts exist.
Runtime understanding	25%	Can say what blocks the loop and keeps it clear.
Data handling	20%	Large payloads are streamed with backpressure respected.
Error handling and operations	15%	Failures are classified and surfaced; shutdown and health are designed.
Diagnostic method	10%	Investigates production symptoms systematically rather than guessing.

Mistakes hiring teams make

Testing Express routing and framework trivia instead of runtime behaviour
Not planting the bugs that actually cause incidents — async, blocking, memory
Accepting a working demo without asking what happens under load
Skipping error-handling questions because the happy path worked
Weighting framework familiarity over the ability to reason about the runtime

Roles that need Node.js

Backend DeveloperNode.js DeveloperFull-Stack DeveloperPlatform EngineerAPI DeveloperSoftware Engineer

Common questions

Should a Node.js assessment use a specific framework?

Only if the role does. Framework routing is easy to learn; event-loop and async understanding are not. Test the runtime, and let framework familiarity be a minor factor.

What is the single best Node.js screening question?

Hand them a short handler with an unawaited promise and a synchronous read, and ask what a user experiences under load. It covers async correctness and the event loop in ten minutes.

Do junior Node.js developers need to understand streams?

They need to know streams exist and when buffering is dangerous. Implementing backpressure correctly is a reasonable expectation at mid level.

How do I assess operational maturity without a live system?

Describe a real symptom from your own incident history and ask how they would investigate. Method and hypotheses tell you a lot, even without hands on the keyboard.

Cohesyve · Skill assessments for hiring

Test Node.js before the first interview

Generate a role-specific Node.js assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides