Recruter un développeur React Native senior : le guide terrain

Recruter un développeur React Native senior consiste à vérifier sa capacité à travailler sur votre produit en production, au-delà de sa connaissance de React. Chez SprintMob, chaque profil passe un entretien technique de 30 minutes avec Youcef Acheuk. Le collectif réunit 200+ freelances seniors qualifiés individuellement. Voici ce que vous pouvez reprendre de cette méthode pour votre propre recrutement.

Votre application impose un contexte : versions, dépendances, contraintes iOS et Android, calendrier de publication et organisation de l'équipe. Deux candidats qui citent les mêmes technologies peuvent être très différents face à ce contexte. L'un a livré des interfaces sous la supervision d'un lead ; l'autre a porté les builds, les incidents et les migrations. Le brief doit rendre cette différence visible.

Commencez par une phrase qui décrit le résultat attendu. « Reprendre la livraison mobile bloquée par une migration », « renforcer l'équipe sur les parcours de paiement » ou « stabiliser les releases Android » sont des besoins plus précis que « chercher un senior React Native ». Vous pourrez ensuite distinguer la compétence centrale des compétences simplement utiles.

Documentez l'état de l'application : sa stack, son mode de build, ses dépendances sensibles, les plateformes réellement utilisées et les difficultés connues. Indiquez si des modules natifs existent, qui les maintient et si une migration est déjà engagée. La documentation React Native sur les plateformes natives (nouvel onglet) décrit les possibilités d'interaction avec le code natif ; votre besoin réel détermine la profondeur à vérifier.

Ajoutez l'organisation : interlocuteur technique, taille de l'équipe, place du produit, rythme des releases et disponibilité pour les revues. Un profil qui doit décider seul de l'architecture n'a pas le même rôle qu'un contributeur intégré à une équipe expérimentée. Enfin, fixez le rythme, le lieu de travail, la date souhaitée et le budget. Ces contraintes peuvent écarter un bon candidat avant même l'entretien.

Cherchez une application effectivement publiée et une explication de la contribution personnelle. Le nom du client et le nombre d'années ne racontent pas le travail réalisé. Demandez ce que la personne a conçu, repris ou diagnostiqué, ce qu'elle a laissé à l'équipe et comment le résultat a été vérifié. Elle doit pouvoir séparer ses décisions de celles prises par le collectif.

Un cas proche du vôtre vaut davantage qu'un portfolio impressionnant mais éloigné. Pour une migration, revenez sur les incompatibilités, l'ordre des changements et la manière de garder les livraisons possibles. Pour un sujet de performance, demandez le symptôme, les mesures et le diagnostic. Pour une application lancée de zéro, examinez aussi la maintenance après la première publication.

Respectez la confidentialité. Un candidat peut expliquer un arbitrage sans montrer le code privé d'un ancien client. Vous pouvez demander un schéma anonymisé, une description du problème ou un extrait public. L'absence d'un dépôt partageable ne constitue pas un manque de preuve si le récit est précis et qu'une référence peut confirmer le rôle.

Les cas Mizen, Yomoni et Finary illustrent des besoins différents : migration, construction d'une application et renfort d'équipe. Servez-vous de cette diversité pour formuler votre mission. Il n'existe pas un unique profil « senior mobile » adapté à tous ces périmètres.

Préparez une difficulté de votre application et demandez au candidat de raisonner à voix haute. Commencez par les informations qu'il chercherait. Un bon diagnostic dépend du contexte : plateforme, reproduction du problème, version concernée, derniers changements et observations disponibles. Une réponse qui saute immédiatement à une bibliothèque manque une partie de la discussion.

Passez ensuite à un projet du candidat. Demandez pourquoi une solution a été choisie, quelle alternative a été écartée et ce qu'il ferait différemment aujourd'hui. Revenez sur un incident, une régression ou une estimation revue. Vous cherchez une capacité à apprendre et à expliquer les limites d'un choix, plutôt qu'un récit sans difficulté.

Terminez par la collaboration. Comment expliquerait-il une dette technique au PM ? Que ferait-il si le calendrier produit empêchait la solution qu'il préfère ? Comment transmettrait-il un module sensible à l'équipe ? Un développeur senior intervient dans une organisation ; sa manière de rendre les décisions compréhensibles fait partie du travail.

Notre article sur le test technique d'un senior détaille cette grille. Le format doit rester lié au besoin. Une conversation courte ne dispense pas de références ni d'une validation par votre équipe, et un exercice n'est utile que s'il apporte une information qui manque encore.

Demandez comment la personne prépare une release, suit les incidents et distingue un problème JavaScript d'un problème natif. Faites préciser son rôle dans les builds, la signature et les publications. Elle peut s'appuyer sur des outils et sur d'autres spécialistes ; ce qui compte est de comprendre ce qu'elle sait porter et quand elle demande de l'aide.

Un développeur web habitué à React possède des bases utiles. Il doit néanmoins démontrer sa capacité à travailler avec les contraintes mobiles de votre mission. La documentation d'intégration dans une application existante (nouvel onglet) montre que les étapes diffèrent selon la plateforme. Votre entretien doit donc garder une place aux réalités iOS et Android, même si l'interface partage du code.

Posez des questions sur un problème réellement rencontré : un build qui échoue après une mise à jour, une permission qui se comporte différemment ou une régression qui touche certains appareils. Demandez comment le problème a été reproduit et comment le correctif a été validé. Les noms d'outils servent à préciser le récit ; ils ne remplacent pas le diagnostic.

Choisissez des personnes qui ont travaillé directement avec le candidat. Préparez des questions sur l'autonomie, la fiabilité des livraisons, la communication et la qualité de la transmission. Demandez dans quel contexte elles le reprendraient et dans quel contexte elles choisiraient un autre profil. Cette nuance aide à comprendre l'adéquation à votre mission.

Votre décision gagne à être écrite. Pour chaque candidat, notez les preuves qui répondent au besoin, les limites identifiées et les conditions de réussite. Évitez de transformer une impression agréable en score technique global. Un profil peut être excellent pour une construction de produit et moins adapté à une reprise urgente d'application native complexe.

Faites ensuite valider le candidat par les personnes qui travailleront avec lui. Le collectif peut qualifier et présenter ; votre équipe reste la mieux placée pour juger les attentes de collaboration. Donnez au candidat l'occasion de poser ses propres questions. Un recrutement réussi exige aussi qu'il comprenne les contraintes et accepte le travail proposé.

Le guide TJM situe nos fourchettes ; la proposition précise le tarif et le rythme de votre mission. Validez ensemble les modalités de facturation, les frais, la durée envisagée et la sortie. Ne laissez pas la disponibilité ou la présence sur site dans une conversation informelle si elles conditionnent le choix.

Préparez les accès, un environnement qui démarre, les contacts produit et un premier sujet dont la validation est claire. Identifiez qui débloque une dépendance et qui relit le code. Un démarrage ralenti par les droits, les certificats ou l'absence de décisions produit ne renseigne pas sur le niveau du développeur ; il révèle surtout une préparation incomplète.

SprintMob présente un profil qualifié sous 48h lorsque le réseau correspond au besoin. Le démarrage prend 2 semaines en moyenne sur nos missions ; cette durée reste distincte de la présentation. Gardez cette distinction dans votre planning, quel que soit votre canal de recrutement. Un profil proposé rapidement doit encore être validé, disponible et correctement intégré.