Hire Node.js developers you can check before you commit

Two things bring people to this. Either a Node.js service is already in production and needs someone who can take it over without a rewrite, or a service needs building and the team to build it does not exist yet. Both are placements, and both turn on the same two questions: who writes the code, and what stops a bad change getting merged.

Money is not what stops most of these decisions. Neither is doubt about whether good Node.js developers exist. It is substitution. You interview someone capable and you agree. Then the commits start arriving from a name you have never spoken to. One person put it plainly on Hacker News in July 2020. Their account is worth reading in their own words rather than ours.

That is one person's experience. We have not measured how common it is, and we are not going to guess. What we can do is make it checkable in your case.

Every firm offers a trial. A trial on its own is worth almost nothing. At the end of it the argument is about whether it went well. That argument is unwinnable when nobody wrote down what good looked like at the start.

So the part that matters here is the order. Before a developer starts, the criteria you will judge them against go into the engagement in writing. Not a description of the role. The actual conditions. What has to be shipped, what has to be understood, whose review it has to pass, and by when. The pilot period runs two to three weeks against those criteria, and at the end there is nothing to interpret. A developer who does not pass is replaced, and the pilot re-runs against the same criteria.

You are not asked to accept a profile you have not spoken to either. Run your own hiring loop, your own interview, your own technical bar. Some clients skip it and some run three rounds. Both are fine, because the pilot criteria are what settle it either way.

Ask us for the pilot criteria in writing before you commit to anything. If they are vague, that is a real answer about us.

The Node.js service you are staffing is mostly not code your team wrote. That is normal and it is how the ecosystem works. It is also why taking over a Node.js service is a reading job before it is a writing job.

Run npm ls --all against your own service and count what comes back. Whatever that number is, it is the surface a new developer has to be able to reason about. It costs five minutes to know it.

Every Node.js major has a published date after which critical bugs stop being fixed. The release working group sets them and they are the same for everyone.

The upgrade is rarely the hard part. What turns it into a quarter of work is the dependencies nobody has touched since the last upgrade. Add the tests that were never written because the service worked.

Check which Node.js major your production containers actually run. It is often not the one in your documentation. Put its published end date in your calendar.

1. Gate 1

   A senior software engineer reads it

   Every change is reviewed by a senior software engineer before it goes anywhere. Not a rubber stamp on a green build, a read.

   Hands upward

   A change someone other than its author is willing to put their name to.

2. Gate 2

   Branching discipline

   GitFlow, so a change has a place to live while it is still wrong. The main line is not where work happens.

   Hands upward

   A history you can read backwards when something breaks at 2am.

3. Gate 3

   Tests, unit and integration

   Unit tests for the logic and integration tests for the seams, both required rather than encouraged.

   Hands upward

   A failing signal that arrives before a customer produces one.

4. Gate 4

   CI/CD gating the merge

   The pipeline is the thing that decides, not a person under deadline pressure agreeing it is probably fine.

   Hands upward

   A merge that means the same thing on a Friday evening as it does on a Tuesday morning.

5. Gate 5

   Architecture decisions written down

   The reasoning behind a structural decision goes into the technical requirement specification, with the alternatives that were rejected.

   Hands upward

   A decision your own team can argue with later, instead of inheriting it as folklore.

These are the gates a change clears on our side. Your repository's branch protection is yours to configure. Nothing here describes or promises anything about it.

1. 01

   The brief

   You describe the service, the runtime, and what you need someone to take responsibility for.

   You get

   A shortlist, typically within a few days, matched to that description rather than to a keyword.

2. 02

   The pilot

   Two to three weeks against criteria agreed before the start, running in your repository and your review process.

   You get

   The written pilot criteria, agreed in advance, and a plain answer at the end against each one.

3. 03

   The technical requirement specification

   Architecture decisions get recorded as they are made, together with what was rejected and why.

   You get

   A specification you can disagree with in writing, before it is built.

4. 04

   Any change of scope

   A change request becomes a change note. Time and effort are laid out before approval. The change enters the plan only once you have signed off, in a meeting and in writing.

   You get

   A change note per change, so nothing moves on a re-scope you have not explicitly accepted.

5. 05

   Offboarding

   Whenever it ends, the knowledge leaves with the work rather than with the person.

   You get

   An operational runbook that goes with you.

These are not aspirations and they are not averages. Each one is a commitment that goes into the engagement before a developer starts. That is why the overlap is a number of hours rather than a promise to be flexible.

• 2 to 3 weeks. Pilot period, with the evaluation criteria written into the engagement before the developer starts
• 10:00 to 19:00 IST. The working day
• 2 to 3 hours. Daily overlap for North America, and a substantial afternoon overlap for Europe
• A few days. From your brief to a shortlist, typically
• Day 1. When your IP is yours

• Your IP is yours from day one, not on completion and not on final payment.
• The code lives in your repositories. There is no copy of it anywhere that you cannot see.
• Deployments run in your cloud accounts, under your billing and your access control.
• The documentation written during the engagement is yours to keep. That includes the technical requirement specification and the architecture decisions in it.
• An operational runbook goes with you at offboarding. Whoever picks the service up next is not starting from the source alone.
• An NDA is in place from day one and access runs through SSO. Repository access is granted and revoked as a normal part of the engagement.

None of that is unusual to ask for and none of it should be hard to get. This list is the one that gets vague when a firm has not thought about the ending. Put exactly these six to everyone bidding, in these words, and read what comes back. Where an answer arrives as a principle rather than a term, that is worth knowing now. Better before you sign than at offboarding.

• You already have the person, just not the time

  Choose this when

  Someone on your team knows the service and would do this work if the queue in front of them were shorter.

  It costs you

  Bringing in an outside developer costs more than clearing their queue. It also costs them the context they already hold. Buy them the time instead.

• The problem is broader than the runtime

  Choose this when

  The real work sits in queues, multi-tenant data isolation, or a service layer spanning more than one runtime, and Node.js is just where you noticed it.

  It costs you

  A placement scoped to Node.js will keep hitting the edge of its own remit. A placement scoped to the runtime keeps running into the edge of its own remit. The better fit covers queues, data isolation and the wider service layer across runtimes.

• Nobody internal will review the work

  Choose this when

  There is no one on your side who will read the changes and push back on them.

  It costs you

  A placed developer performs at the level of the review they get. With no reviewer, the same drift that got the service into this state starts again under a different name. You will pay for it twice.