Come valutare le competenze degli sviluppatori Node.js

Nell'attuale clima tecnologico, Node.js è uno dei le tecnologie di backend più diffuse utilizzato dagli sviluppatori. È fondamentale verificare le competenze di sviluppatore Node.js del candidato per effettuare un'assunzione di alta qualità.

Sono molti i motivi per cui Node.js è popolare tra gli operatori del settore. A volte chiamato semplicemente 'Node', questo ambiente di runtime promuove uno sviluppo software veloce e scalabile. Inoltre, utilizza JavaScript, la lingua franca del World Wide Web, per alimentare le sue ampie funzionalità. Non c'è da stupirsi che molte aziende stiano facendo del loro meglio per cercare sviluppatori Node.js di alto livello.

I dati riportati da Indeed indicano che il numero di ricerche di lavoro per Node.js rosa da 57% rispetto all'anno precedente, a dimostrazione della sua crescente domanda. Questo speciale pezzo di tecnologia è utilizzato da una serie di giganti della tecnologia e di multinazionali, tra cui Netflix, Uber, LinkedIn, NASA, PayPal, Microsoft e Walmart.

Nell'articolo di oggi, DevSkiller illustrerà le caratteristiche di Node.js, gli aspetti più importanti che un selezionatore IT dovrebbe conoscere e le nostre migliori strategie per assumere uno sviluppatore Node.js di qualità.

Che cos'è Node.js?

Tecnicamente parlando, Node.js è un ambiente runtime JavaScript open-source e multipiattaforma che esegue codice JavaScript al di fuori di un browser web.

Scendendo un po' più nel dettaglio, Node.js consente agli sviluppatori di utilizzare JavaScript per scrivere comandi per lo scripting lato server (back-end scripting). In sostanza, questo significa che Node.js aiuta a eseguire script lato server per produrre contenuti dinamici di pagine web prima che la pagina venga inviata al browser dell'utente.

La prima versione stabile di Node.js (0.10.0, la prima utilizzata in ambito commerciale) è stata rilasciata nel 2013, anche se il progetto è iniziato qualche anno prima. L'obiettivo di Ryan Dahl, il creatore di Node.js, era quello di creare siti web in tempo reale con funzionalità push, "ispirandosi ad applicazioni come Gmail". Con Node.js ha fornito agli sviluppatori uno strumento per lavorare nel paradigma I/O non bloccante e guidato dagli eventi.

1.1. A cosa serve Node.js e quali problemi risolve?

Poiché la maggior parte delle applicazioni lato client, comprese le pagine web e le applicazioni web, utilizzano codice scritto in JavaScript, il vantaggio di scrivere anche script lato server in Javascript è enorme. È qui che entra in gioco Node.js.

Node.js è popolare soprattutto per il fatto che rappresenta una "JavaScript ovunque" unificando lo sviluppo di applicazioni web attorno a un unico linguaggio di programmazione, anziché a linguaggi diversi per gli script lato server e lato client.

Questa unificazione dello stack, che incorpora il linguaggio e il formato dei dati (JSON), consente alle aziende di riutilizzare in modo ottimale le risorse degli sviluppatori.

L'uso di Node.js consente a uno sviluppatore full-stack di passare con facilità e, di conseguenza, è in diretta concorrenza con altri linguaggi e framework di scripting popolari come Java, .NET, Python, PHP, Ruby e C#.

La piattaforma facilita le applicazioni web con connessioni bidirezionali, in modo che sia il client che il server possano iniziare la comunicazione, consentendo loro di scambiare liberamente i dati. Questo vantaggio è in netto contrasto con la tipica paradigma web richiesta/rispostain cui è sempre il cliente a iniziare la comunicazione.

Node.js è una piattaforma che soddisfa un'esigenza particolare. È molto leggera, il che significa che è possibile scrivere sistemi scalabili e ad alte prestazioni con poco codice. Node.js, tuttavia, non è ideale per le operazioni ad alta intensità di CPU a causa della sua implementazione a thread singolo.

Node si distingue dalla massa per la costruzione di applicazioni di rete veloci e scalabili, in quanto è in grado di gestire un numero enorme di connessioni simultanee con un elevato throughput, il che equivale a un'elevata scalabilità.

1.2. È simile a qualsiasi altro linguaggio o framework?

Node.js sarà sempre molto legato al linguaggio JavaScript, essendo la sua piattaforma di runtime lato server. Poiché Node.js implementa le specifiche ECMAScript, uno standard JavaScript globale che ha lo scopo di garantire l'interoperabilità delle pagine web tra i diversi browser; possiamo informalmente dire che Node.js è effettivamente Javascript.

Per certi versi, possiamo dire che Node è simile a PHP, Python e Ruby (essendo un linguaggio di scripting a tipizzazione dinamica), anche se è molto più avanzato in termini di capacità di programmazione funzionale.

Sul mercato sono presenti diversi altri prodotti che funzionano come valide alternative a Node.js. Questi includono Elixir, Perl, ASP.NET, Ceylon e Rebol.

1.3. Quali sono i suoi principali vantaggi o caratteristiche?

• Consente agli sviluppatori di scalare le applicazioni in direzioni orizzontali e verticali.
• È facile da imparare per gli sviluppatori che hanno familiarità con JavaScript.
• A 'JavaScript full-stack' - aiuta a scrivere applicazioni lato server in JavaScript.
• Makes using code easier and faster and more effective by interpreting JavaScript via Google’s V8 JavaScript engine.
• Provides the option of non-blocking I/O systems which helps developers to process several requests concurrently.
• Is home to a vibrant, community-driven user base that continuously contributes towards its improvement.

Che cosa è importante che un selezionatore IT conosca di Node.js?

What’s important to look for when hiring developers with Node.js experience? Besides the usual architecture design, logic, collaborative, and communication skills you’d require when hiring any developer, there are some things that are unique to Node developers.

2.1. How often does the tech stack change?

As Node.js runs on Javascript you will often hear people say that, “there is a new JavaScript framework each week”, but that primarily relates to the front-end architecture. The back-end is generally a lot more stable. Of course, new tools are added all the time; however, pertaining to the most popular add-ons used in Node.JS — including Express, Meteor, Hapi, NestJS, koa etc – it’s more of an evolution than revolution.

What’s more, the JavaScript language itself has been improving steadily since 2015, when ES6 (also known as ES2015) was released. The reason is because prior to 2015, each JS version was introduced extremely periodically (such as every 3-5 years) but since 2015, a new version is released each year. Overall, the tech stack has undergone quite a smooth evolution.

2.2. Are there many resources/tools/technologies available?

What’s really great about Node.js is the thousands of modules available for any purpose, as well as the vibrant community behind the platform. Scores of blogs, tutorials, videos, conferences and books exist on the topic designed to make developers’ lives easier.

Tools like Webpack, a handy JavaScript module bundler used to simplify front-end development really help simplify Node.js. Or Mocha.js, which enables Node developers to test both in-console and in the browser.

More information on tools and resources for Node can be found on sites such as Smashing e Brainhub.

2.3. What tools and techniques should a Node.js developer be familiar with?

There are two things that should be distinguished here: the knowledge of Node.js itself and the general back-end programming-related issues. Node.js, being the server-side JavaScript comprises of:

• The scripting language, and
• Built-in Node.js modules, which manage file systems, processes, events, HTTP, etc

This breadth of knowledge is not a big barrier for front-end developers, who wish to migrate from browser work to the server.

However, there are also back-end related concepts, which are more or less the same for all backend technologies, including Java, .Net, PHP, Python, Ruby, Golang, and, of course, Node.js. Such topics include:

• Databases, persistence
• Session management
• Architecture: monoliths, microservices
• Scaling (RAM/CPU resources consumption)
• REST APIs
• Cloud and infrastructure
• and many, many more, often depending on the specificity of the project.

All-in-all, these are the concepts which node.js developers should be familiar with.

The specifics of Node.js developer skills is clearly non-negotiable. But without back-end knowledge, developers could write systems that aren’t resilient, unscalable, or not fault tolerant (which could result in systems that work well for ~50 users but break for ~5000 or ~50000 users).

2.4. What type of experience is important to look for in a Node.js developer?

Without a doubt, commercial experience with Node.js is the most important factor to consider here. Working on business-related projects and delivering stable software are the benchmarks for the platform. Scientific and academic experience for React is almost irrelevant.

Open source experience should also be discerned as an additional benefit since Node.js is one of the most open-source friendly platforms that exist.

Come verificare le competenze degli sviluppatori Node.js nella fase di screening?

If you’re hiring for Node.js developer skills, there’s more than one way to skin a cat, or so to speak. Adam Polak, The Software House’s Head of Node.js, contends that transitioning from a different technology can ostensibly be a viable option.

“Node.js is a relatively new technology, so there are not many experienced devs who use it. That’s why we should not limit ourselves just to current Node.js users, but also take a look at skilled devs who can transition quickly. PHP, Java, and .NET developers are often willing to learn new technologies.”

3.1. What to take into account when screening a resume?

• Developers should be familiar with back-end programming issues, patterns, problems, and solutions.
• Experience in developing and shipping Node.js-based applications.
• Database design and performance analysis.
• QA-related skills (i.e, designing testing scenarios, and implementing those tests).
• Experience with cloud infrastructure, e.g. how to enable deploys to AWS/Azure/GCP cloud infrastructure.
• Anything that doesn’t prove the knowledge about the tech stack, but provides business value, such as: application maintenance, bug fixing, performance tuning, etc.
• A balance of knowledge between syntax (how to write code) and back-end related issues (what to write).
• Developers that demonstrate an understanding of platform specificity (what problems can arise, and the right ways to solve them).
• Don’t expect that candidates will know your tech stack back to front. Assume that if a developer has proven success in one stack, they can perform to a high standard in another tech stack.

3.2. What glossary terms are important to know in Node.js (including frameworks, libraries and language versions)?

Abriviations	Node = Node.js JS = JavaScript. ES = ECMAScript (ECMAScript is the name of the standard, JavaScript is its implementation – formally. But in practice, people call it JavaScript when they should call it ECMAScript (the spec), however, the majority of developers don’t care.)
JavaScript / ECMAScript	Asynchronous programming: events, promises, async/await, rxjs Object-Oriented Programming: JS data structures, prototypal inheritance, ES6 classes Functional Programming: higher-order functions, closures Cross-cutting mechanisms: coercion (typecasting)
WebServices	HTTP protocol, WebSocket protocol HTTP: Fetch, Axios, Request, WebSockets: Socket.IO
Node.js tooling	Frameworks: Express, Koa, Nest.js, Fastify Transpilers: Babel, TypeScript, Flow Bundlers: Webpack, Parcel, Snowpack Popular packages: NVM, Chokidar
Testing	Types: unit tests, functional tests, integration tests, E2E tests Tools (frameworks & libraries): Karma, Jasmine, Selenium, Jest, Mocha, Sinon, Chai (and many others) Misc: pyramid of tests (way more unit tests than e2e), snapshot testing, regression testing, mocking
Banche dati	SQL, MySQL, MSSQL NoSQL: MongoDB, CouchDB, and many others ORMs (object-relational mappers)
Design	Monoliths, microservices, CQRS Design Patterns: facade, factory, builder, composite, mediator, state machine, state, chain of responsibility… and many, many more Concerns: scalability, monitoring, logging, deployments, continuous integration/deployment, cloud infrastructure

3.3. Which versions are completely different? Which versions are similar to each other?

ES6 is ECMAScript v6 (released in 2015), it was a major breakthrough that people relate to, meaning the new JavaScript (before that people consider the old JS).

Node.js versions are shipped mainly with better support for recent ECMAScript (JavaScript) versions, they are improved incrementally, but not revolutionary.

Screening tecnico delle competenze dello sviluppatore Node.js durante un colloquio telefonico/video

4.1. Questions that you should ask about a Node.js developer’s esperienza. Perché dovreste porre ciascuna di queste domande?

• Have you been involved in automatic testing your previous applications? What do you think you’ve done well and what would you change today?
  • Testing is an essential element of software development. Developers are given the tools to innovate and it’s up to them whether they use them efficiently. In regards to testing, it’s important that:
    • Tests are small and run quickly. Developers are less eager to continuously run tests which takes a lot of time.
    • Each test should explicitly check one variable (unless it’s E2E which tests, as the name suggests, is end-to-end). If a feature is broken, it’s better to have one test failing instead of hundreds of tests failing.
    • Tests should not cover elements that are checked by other tools, etc. Data structures can be validated by JSON schema validators, type checkers (TypeScript, Flow, …) etc.
    • Proper coverage by way of testing should give developers trust in the code they create (i.e, if the tests pass, the code is working properly). A developer who hasn’t maintained tests might not feel the need to create them and not realize how appropriate testing helps in the long run.
• Have you been working with microservices and/or distributed systems?
  • If your company’s products handle a massive scale (of users, requests, etc.) and require high availability, then often this leads to distributed systems, where only a piece of the system is being scaled. All-in-all, a distributed system has its own patterns and anti-patterns which take a long time to learn. If you need to ship your app to the cloud (AWS/Azure/GCP, …) then a Node.js developer with distributed systems would be extremely valuable.
• Have you been working on real-time applications? If so, what business processes did the system implement? What was the difficulty in the system, technology-wise?
  • One of the most important concerns to deal with in big-business systems is real-time data. Implementing apps where data changes every second bring with it its own quirks, problems, common mistakes, solutions, patterns, and architecture etc. If your system handles data that changes frequently (e.g. postal service tracking, or processing financial data, which, due to the nature of finances, is also extremely dynamic) you should definitely ask this question to see whether the candidate understands the context.

4.2. Questions that you should ask about a Node.js developer’s conoscenze e opinioni. Perché dovreste porre ciascuna di queste domande?

• What are Node.js streams, what does it mean to stream data – and why is that important?
  • Streaming data is a certain way to exchange the data between the server and the client. In most systems, a complete request is sent; and a corresponding, a complete response is received, but that’s not the case with streams. In streams, the answer is returned in multiple chunks (streamed in real-time, piece by piece). It’s extremely important because it affects low-level system performance. Often, a client can start to process chunks (pieces) of the response without having the whole response. This is more difficult, but it reduces the time of unnecessary waiting. An experienced node.js developer should be experienced with using node streams.
• Why should package-lock.json be committed to the repository and what does it contain?
  • Pretty much every developer knows that a package.json file, the main file of a node project, should be committed and tracked by a versioning system (e.g. git). But not everybody knows about package-lock.json and it’s placed in npm. While package.json explicitly lists all dependencies which we directly use, package-lock.json includes the entire tree of dependencies. Versions of all packages are explicitly listed and, when the application is built on a build machine, those exact versions would be taken into account. Why? Because if we get an error on a build machine, we need to know the exact versions in order to reproduce the error on local machines. Thanks to committing package-lock.json to the repo, it’s easy.
• There’s a common saying in programming, that “there are 2 difficult things in programming: 1. Naming things, and 2. Cache invalidation”. Please explain what is cache invalidation and why it is considered difficult.
  • Caching is remembering calculations for later so that whenever the same question is asked again, we already have the right answer. Cache invalidation is when we know that the basis for the calculation has changed and so the remembered result is wrong. Since it relates to the old basis, we know that this piece of cached information should be cleared (invalidated). In big systems, where the price of an order can depend on multiple factors, some of them change and some don’t. It’s difficult not to miss a certain path (a change should be followed by a cache invalidation) or not to do it over eagerly. In most of the systems, cache invalidation has to be programmed explicitly.

4.3. Domande comportamentali that you should ask a Node.js developer. Why should you ask each of those questions?

• Imagine you join a developer team which maintains a stable product, but is rather poorly written. Delivering new functions and improving business value takes more time than expected. How would you try to help the team when you join them?
  • What’s important here is how the candidate tries to help. Whether the candidate would strive to explain how something should be done properly (e.g. like a teacher, and what has already been done was wrong) or rather try to listen to the teammates as to why did they perform in such a manner and meet them where they are. Basically, a technical expert who forces decisions by claiming their own knowledge is not a good team player.
• Have you ever found yourself in a situation where you were aware you had introduced a bug that later made the production system crash (either the whole platform or a single functionality)? If so, what did you learn from it?
  • To some extent, this question checks honesty. Junior developers might not have had a chance to release a severe bug, but senior developers definitely have. The perfect programmer does not exist, i.e, someone who has made zero mistakes. So the question beckons if the consequences of a mistake were painful for the candidate. Also, learning from mistakes is extremely important in the long run as developers need to build habits that will eliminate possibilities to introduce bugs. Especially when it comes to back-end applications. After all, we can’t be better next time if we don’t analyze why we found ourselves in a critical situation now.
• What do you consider your greatest achievement?
  • This question is deliberately left open because it allows the developer to choose from distinct areas such as providing business value, exemplifying teamwork, and cooperation, as well as technical expertise. So it’s interesting to observe what the candidate considers important for them. In fact, a balance between all 3 would be most appreciated. You might be rightly skeptical about a candidate if they value technical expertise only since this is what you should expect later on when working for your company.

Screening tecnico delle competenze degli sviluppatori Node.js tramite un test di codifica online

Hiring a great Node.js developer can pose a significant challenge, especially if you’re doing all the dirty work yourself. For projects that require a long-term commitment and budget, you need a software development company with a solid recruitment process.

5.1. Which online test for Node.js developer skills should you choose?

Quando si cerca il giusto Node.js developer skills test è necessario assicurarsi che corrisponda ai seguenti criteri:

• Il test riflette la qualità del lavoro professionale che viene svolto
• La durata non è eccessiva, da una a due ore al massimo.
• Il test può essere inviato automaticamente ed è di natura semplice.
• Il livello di difficoltà è adeguato alle capacità del candidato.
• Il test va oltre la verifica del funzionamento della soluzione: controlla la qualità del codice e il suo funzionamento nei casi limite.
• È il più vicino possibile all'ambiente di programmazione naturale e consente al candidato di accedere alle risorse pertinenti.
• Fornisce al candidato l'opportunità di utilizzare tutte le librerie, i framework e gli altri strumenti che incontra regolarmente.

5.2. DevSkiller ready-to-use online Node.js developer skills tests

I test di codifica DevSkiller utilizzano la nostra metodologia RealLifeTesting™ per rispecchiare l'ambiente di codifica reale in cui lavora il vostro candidato. Invece di utilizzare oscuri algoritmi, i test DevSkiller richiedono ai candidati di costruire applicazioni o funzionalità. Sono valutati in modo completamente automatico e possono essere sostenuti in qualsiasi parte del mondo. Allo stesso tempo, il candidato ha accesso a tutte le risorse che utilizzerebbe normalmente, tra cui librerie, framework, StackOverflow e persino Google.

Le aziende utilizzano DevSkiller per testare i candidati utilizzando la propria base di codice da qualsiasi parte del mondo. Per semplificare le cose, DevSkiller offre anche una serie di test di competenze di data science già pronti, come quelli qui riportati: