Everyone writes JavaScript. Far fewer understand the event loop.
Node is easy to write and easy to get subtly wrong, and the wrong version works perfectly in development. The difference shows up under concurrency, on a second instance, and at three in the morning.
The failure modes are invisible until they are expensive.
A Node service written by someone who has not internalised the execution model usually works. It passes review, it passes tests, and it behaves correctly with one user on a laptop. What it does under concurrency is a different question, and one nobody asks until production asks it for them.
The specific hazards are consistent: synchronous work blocking the loop for every other request, an unhandled promise rejection taking the whole process rather than one request, and in-memory state that is silently per-process the moment you run more than one instance.
None of these appear in a code review unless the reviewer is looking for them, which is why we screen for the execution model explicitly, not for framework familiarity.
The second thing we insist on is TypeScript. Node's greatest strength is that the same people can work across the interface and the API; that only holds if there are shared types describing the boundary between them. Without it you have two codebases with an undocumented contract and a whole category of avoidable bugs.
What we ask a Node engineer.
Six questions where the answers separate people who have run Node in production from people who have built with it.
What blocks the event loop in this code?
Asked against a real sample. Large JSON parsing, synchronous crypto, a tight loop over a big array. The answer is immediate or it is absent.
What happens on an unhandled rejection?
The process exits. Engineers who know that have configured a handler and thought about what the orchestrator does next.
What breaks when you run two instances?
In-memory caches, sessions, rate limiters, scheduled jobs firing twice. The most useful single question we ask.
How do you handle a slow dependency?
Timeouts by default, backoff, circuit breaking. Node's defaults will wait indefinitely, which is how one slow service takes down four.
How strict is your TypeScript?
We are listening for an opinion about any and about where the types come from. A codebase where the API types are hand-copied into the client is a codebase with a whole class of avoidable bugs.
How do you keep dependencies under control?
Node projects accumulate hundreds of transitive packages. An engineer with no view on this has not been responsible for one long enough.
Where we would recommend Node, and where we would not.
We deliver .NET, Java and Python as well, so this costs us nothing to write accurately.
Heavy server-side processing
Document generation, large file processing, long reports. Node makes this harder before it makes it better; use a worker or another runtime.
Heavy work behind an API
Node can front it, but the work belongs on a queue. That is real scope and it should be in the estimate.
Services and integrations
I/O-bound work, API composition, webhooks and glue. Node is genuinely excellent at this and it is most back-end work.
One team, front and back
Shared types, one toolchain, one hiring pool. This is where Node's advantage is structural rather than incidental.
What people often need alongside a Node engineer.
Node briefs are rarely Node alone. These are the adjacent hires we most often end up recommending, and it is cheaper to know now.
- A React engineer, sharing the types. The main structural benefit of Node is one language across the stack, which only pays off if both sides are staffed — see React developers.
- A cloud engineer for anything beyond a container. Queues, autoscaling and observability are a different discipline — see cloud engineers.
- A full-stack engineer, if the team is small. Under about four people, splitting the roles costs more than it returns, see full-stack developers.
- A React Native engineer, if mobile is coming. The shared-language argument extends to mobile, with real caveats — see React Native developers.
Rates, notice and how we interview, on one page.
The commercial mechanics are the same whichever role you are hiring, so they live in one place, not being restated on every page.
Hiring Node engineers.
Including the enterprise objection, answered properly.
Is Node suitable for enterprise systems?
The blanket claim that it is not does not survive contact with the evidence, Node runs very large systems at organisations with far higher volumes than most enterprise applications ever see. What is true, and worth taking seriously, is that Node gives you less by default: no opinion about structure, no built-in transaction management, no standard approach to configuration or dependency injection. On a disciplined team with established conventions that freedom is an advantage. On a team distributed across several suppliers, or one without strong conventions, codebases diverge quickly and the result is hard to maintain. If that is an honest description of your situation, NestJS imposes enough structure to help, and .NET or Spring would help more.
Should we use TypeScript?
Yes, and we would decline to deliver a Node project of any size without it. The argument is not about catching type errors, which is the smallest benefit; it is that types are the only documentation of an API that cannot go stale, and on a codebase several people touch that is worth more than any amount of written documentation. The cost is a build step and a fortnight of friction for engineers who have not used it. On an existing JavaScript codebase, migration can be incremental (file by file, with the strict settings turned on gradually) and that is how we would do it, not as a single conversion.
Express, Fastify or NestJS?
It depends on the team more than the workload. Express is ubiquitous, which means every candidate knows it and every problem has been solved publicly; it also means the structure of your application is entirely up to you. Fastify is faster and has better schema validation built in, and the difference matters at high request volume. NestJS brings Angular-style structure and dependency injection, which is valuable for a larger team or one coming from .NET or Java, and is unnecessary ceremony for three people building a service. We would ask how many engineers will touch this in two years and answer from that.