Embaucher des développeurs TypeScript

À peu près tous ceux qui écrivent du JavaScript vous diront qu’ils connaissent TypeScript. La différence se voit des mois plus tard, quand la base de code est soit un ensemble de types qui attrapent de vrais bogues à la compilation, soit une pile d’annotations any qui vous donne la cérémonie des types sans aucune de leurs garanties. Un bon développeur TypeScript produit la première, et ça change la vitesse de toute l’équipe : les réusinages deviennent routiniers, les nouvelles recrues lisent les types au lieu de poser des questions à gauche et à droite, et toute une classe d’erreurs en production ne part jamais en livraison. C’est ce que turnkey.dev évalue.

Ce qu’un développeur TypeScript fait pour vous

Une bonne recrue TypeScript va :

• Garder la base de code honnête. Mode strict activé, any traité comme un bogue, et des types qui modélisent votre domaine pour que le compilateur attrape les erreurs avant vos utilisateurs.
• Travailler sur toute la pile. Le même langage fait rouler votre front-end React et votre back-end Node, alors un seul développeur peut prendre en charge une fonctionnalité de bout en bout, en partageant les types entre client et serveur au lieu de les dupliquer.
• Rendre les API sûres côté types. Avec des outils comme tRPC et Zod, le contrat entre le front-end et le back-end est vérifié à la compilation, et la validation des données aux frontières arrête les données malformées à la porte.
• Mettre en place un outillage qui se rentabilise. Des règles ESLint qui appliquent automatiquement les normes de l’équipe, Vite pour des compilations rapides, et une CI qui échoue sur les erreurs de types au lieu de les laisser partir en production.
• Tester ce qui compte. Des tests unitaires avec Vitest, des parcours de bout en bout avec Playwright, et assez de couverture pour que l’équipe puisse déployer sans retenir son souffle.
• Garder un monorepo fonctionnel. Paquets partagés, configurations cohérentes et mise en cache des compilations, pour que plusieurs applications et bibliothèques cohabitent sans se marcher sur les pieds.

À quoi ressemble une vraie profondeur dans le système de types

Le système de types de TypeScript est exceptionnellement puissant, et la profondeur s’y mesure. Quelques marqueurs qui séparent la vraie aisance du TypeScript de CV :

Des types aux frontières. Le compilateur ne peut faire confiance qu’à ce qui entre dans le système. Les bons développeurs valident les données externes (réponses d’API, saisies de formulaires, variables d’environnement, messages de files d’attente) avec un schéma d’exécution comme Zod, puis laissent les types inférés couler à partir de là. Les faibles transtypent avec as en croisant les doigts, et c’est comme ça que des bases de code « typées » plantent encore sur de mauvaises données.

L’inférence plutôt que l’annotation. Du bon TypeScript, ce n’est pas plus d’annotations, c’est moins d’annotations, placées là où elles ancrent la conception : signatures de fonctions, API publiques, types du domaine. Si chaque variable locale porte un type écrit à la main, le développeur se bat contre le langage.

Modéliser des états qui ne peuvent pas être faux. Des unions discriminées pour rendre les états invalides non représentables, le rétrécissement plutôt que le transtypage, unknown plutôt que any aux points d’entrée, des types marqués quand deux chaînes ne doivent jamais être confondues (un UserId n’est pas un OrderId). C’est la partie du travail qui élimine des catégories entières de bogues.

Des génériques avec retenue. Les génériques, les types conditionnels et les types mappés gagnent leur place dans le code de bibliothèques et de couches d’API. Un sénior sait quand un type astucieux aide les appelants et quand il devient un casse-tête que le prochain développeur ne pourra pas modifier. L’astuce au niveau des types pour elle-même est un signal junior déguisé en costume de sénior.

La littératie du compilateur et du build. Savoir ce que font réellement les drapeaux de rigueur du tsconfig, pourquoi les builds de déclarations ralentissent dans un monorepo, et comment lire une erreur de type de cinq lignes pour trouver le seul mot qui compte.

Migrer depuis JavaScript

La migration est l’une des raisons les plus courantes d’embaucher de l’aide TypeScript, et la différence entre une bonne et une mauvaise migration, c’est le plan, pas la vitesse de frappe. L’approche qui fonctionne en pratique procède par incréments : activer allowJs et compiler le code existant sans y toucher, convertir les fichiers le long des zones où l’équipe travaille déjà, garder la rigueur basse au début puis la resserrer (noImplicitAny, puis strict complet) à mesure que la couverture grandit, et ajouter des vérifications en CI pour que les fichiers convertis ne régressent jamais. Les types des bibliothèques tierces et les recoins malpropres du vieux code absorbent plus de temps que quiconque ne le prévoit; budgétez en conséquence. Un candidat qui propose de geler et de tout réécrire propose la version de ce projet qui échoue.

Où TypeScript se rentabilise, et où il est optionnel

Le rendement grandit avec la taille de la base de code, la taille de l’équipe et la durée de vie du projet. TypeScript gagne son coût quand plusieurs personnes touchent au même code, quand le projet vivra des années, quand le front-end et le back-end ont besoin d’un contrat partagé, ou quand la peur du réusinage a visiblement ralenti l’équipe. Il est franchement optionnel pour les petits scripts, les prototypes jetables et les outils à développeur unique, et un sénior le dira au lieu de l’appliquer partout par principe. Si votre besoin relève vraiment de la profondeur d’un cadre plutôt que du langage, les pages React, Angular ou Vue plus bas sont peut-être un meilleur point de départ, et les bassins de talents se recoupent largement.

Les signaux de séniorité à chercher

• Il demande à voir votre tsconfig tôt. Les drapeaux de rigueur lui en disent plus sur l’état réel de la base de code que n’importe quelle démonstration.
• Il peut décrire une migration ou un grand réusinage qu’il a mené, y compris ce qu’il a séquencé en premier et ce qu’il a délibérément laissé sans types.
• Il parle de validation à l’exécution, pas seulement de types à la compilation, et peut dire où se trouvait la frontière entre les deux dans son dernier projet.
• Son instinct pour les génériques est « aussi simple que les appelants le permettent », et il peut donner un exemple d’un type qu’il a simplifié.
• Il traite les échappatoires any comme une dette avec un plan, pas comme un choix de style.

L’erreur d’embauche la plus courante est de tester TypeScript avec des questions de syntaxe. N’importe qui peut apprendre ce que fait keyof en un après-midi. Placez les candidats dans une base de code réaliste en mode strict avec un réusinage à faire et un trou de typage subtil à trouver; l’aisance se voit en moins d’une heure.

Comment fonctionne la présélection turnkey.dev

Chaque développeur passe une évaluation des fondamentaux (le système de types, les génériques, le rétrécissement de types, comment TypeScript compile réellement), un exercice pratique bâti autour d’une base de code réaliste en mode strict avec un réusinage à faire et un bogue à trouver, et une revue du TypeScript en production qu’ils ont pris en charge, y compris les migrations menées, les décisions d’outillage prises et la façon dont leurs types ont tenu à mesure que le code grossissait. La familiarité avec les cadres est notée, mais nous évaluons le langage et le jugement d’ingénierie en dessous. Nous refusons beaucoup plus de candidats que nous en acceptons.

La séniorité, et à quoi sert chaque niveau

La plupart des entreprises qui viennent nous voir ont besoin d’un développeur sénior capable de prendre en charge une surface du produit de bout en bout, avec un lead appelé brièvement pour des décisions comme la structure du monorepo ou un grand plan de migration.

Les modèles d’engagement

• Temps plein pour le travail produit en continu où le développeur prend en charge une surface de la base de code.
• Temps partiel pour les migrations, les nettoyages de sûreté des types et la maintenance d’applications stables. Une migration en particulier fonctionne bien comme mandat sénior à temps partiel qui roule en parallèle du travail normal de fonctionnalités de votre équipe.
• Projet à portée fixe pour des résultats délimités : une migration vers le mode strict avec un point d’arrivée défini, la mise en place d’une couche d’API typée, ou la restructuration d’un monorepo.

Combien ça coûte, honnêtement

Les développeurs TypeScript présélectionnés facturent généralement entre 60 $ et 120 $ de l’heure, les ingénieurs full-stack séniors dans le haut de la fourchette. Les tarifs suivent la séniorité et la région partout sur le marché, alors traitez cette fourchette comme typique plutôt que fixe. Comme TypeScript couvre le front-end et le back-end, une seule bonne recrue couvre souvent le terrain qui en prendrait autrement deux. Le tarif est indiqué avant tout engagement, et demander une liste restreinte est gratuit. Comptez une liste restreinte en 2 à 5 jours.

Pour comparer : les réseaux de présélection du genre Toptal roulent à des tarifs effectifs généralement plus élevés pour une promesse semblable, les places de marché comme Upwork coûtent moins cher de l’heure mais sans présélection, et le problème des mots-clés de CV est pire pour TypeScript que pour la plupart des compétences, parce que tout développeur JavaScript peut le revendiquer. L’embauche à l’interne reste le bon choix pour une équipe centrale de longue durée; elle prend simplement des semaines ou des mois que vous n’avez peut-être pas quand une migration bloque tout ce qui vient derrière.

Commencez par une demande, pas par un contrat

Décrivez-nous votre pile, l’objectif (une nouvelle construction, une poussée de fonctionnalités, une migration vers le mode strict ou de la maintenance continue) et votre échéancier. Nous revenons avec une courte liste de développeurs présélectionnés qui correspondent, incluant tarif et disponibilité. Vous passez les entrevues, faites un essai rémunéré si vous le souhaitez, et décidez seulement ensuite. Si le jumelage ne convient pas dans les deux premières semaines, nous refaisons le jumelage sans frais.