Les red flags quand on recrute un développeur en startup

Presque tous les recrutements de développeur ratés que j'ai vus de près avaient été précédés d'un signal. Une phrase en entretien, une réaction à la restitution d'un test, un détail dans une référence. Le signal était là, quelqu'un l'avait même remarqué, et il a été balayé parce que le candidat était brillant par ailleurs, ou parce qu'il fallait recruter vite.

Les red flags qui doivent alerter quand on recrute un développeur en startup : la sur-ingénierie, le refus de travailler sur du code existant, l'allergie au produit et aux utilisateurs, l'absence de responsabilité dans ses échecs, et le fait de n'avoir jamais tenu une production. Chacun annonce un coût précis dans les six mois : délais, réécriture, départ ou conflit.

Ce sujet appartient à un ensemble plus large, décrit dans le guide pour construire son équipe tech et produit. Il se distingue de deux voisins : les erreurs de recrutement de CTO portent sur les erreurs du recruteur, et les tests techniques en recrutement sur la conception de l'exercice. Ici, on regarde les signaux envoyés par le candidat, et ce qu'ils annoncent.

Un red flag n'est pas un défaut, c'est une prédiction

Un red flag n'est pas une faiblesse technique. Les lacunes se comblent, surtout chez quelqu'un qui apprend vite. Un red flag est un comportement qui prédit ce que la personne fera une fois seule face à votre produit, à vos contraintes et à vos arbitrages. C'est pour ça qu'il compte davantage en startup qu'ailleurs : dans une équipe de trente développeurs, un lead et des pairs compensent un travers. Dans une équipe de deux, personne ne compense rien, et le travers devient la manière de travailler de toute l'entreprise.

Ces signaux se voient à toutes les étapes : dans la façon de raconter un CV, dans les questions posées (ou pas) en entretien, dans la restitution d'un exercice, dans ce que disent les références. Aucun ne demande de savoir lire du code. Ce qu'il faut, c'est savoir quoi écouter.

Six signaux qui doivent vous arrêter

La sur-ingénierie

Le candidat propose, pour un produit qui n'a pas encore cent utilisateurs, l'architecture d'une plateforme qui en aurait dix millions : découpage en multiples services, infrastructure complexe, outillage de grande entreprise. Il le présente comme de la rigueur, et c'est souvent sincère. Mais ce que ça annonce est très concret : des premières livraisons repoussées de plusieurs mois, un système que lui seul comprend, et une facture d'hébergement sans rapport avec l'usage. Un fondateur que j'accompagnais a vu son premier développeur passer un trimestre entier à « poser des bases solides » sans qu'aucun client ne voie la moindre nouveauté. La question qui le révèle est simple : « que construiriez-vous si vous deviez livrer quelque chose d'utilisable dans un mois ? ». Le bon profil simplifie sans souffrir. Le profil à risque explique pourquoi c'est impossible.

Le refus du legacy

Il ne veut travailler que sur du neuf, et propose de tout réécrire avant d'avoir lu l'existant. Cela annonce une refonte que vous n'avez pas décidée, et six mois sans nouvelle fonctionnalité.

L'allergie au produit

Aucune question sur vos clients, aucun intérêt pour l'usage, un agacement quand vous parlez de besoin. Il exécutera des tickets, et vous porterez seul toutes les décisions produit.

Rien n'était jamais de sa faute

Chaque échec passé est imputé à un manager, un client ou un collègue. Au premier incident chez vous, vous saurez qui sera désigné.

Jamais tenu une production

Il a toujours livré du code que d'autres mettaient en ligne et surveillaient. Chez vous, la panne du dimanche soir n'aura personne pour la prendre.

Un délai promis sans question

Vous décrivez une fonctionnalité en deux phrases, il annonce une date ferme. Ce n'est pas de l'assurance, c'est le premier retard de votre roadmap.

Tous ces signaux ont un point commun : ils décrivent quelqu'un qui optimise pour son propre confort technique plutôt que pour le résultat de l'entreprise. Ce n'est pas un jugement moral, beaucoup d'excellents développeurs de grands groupes fonctionnent ainsi, et ils y réussissent. Simplement, une startup n'a pas les moyens d'absorber ce décalage.

Comment les faire apparaître en entretien

Les red flags ne se déclarent pas, il faut créer les situations où ils se montrent. Une question ouverte, puis une relance, suffisent presque toujours.

Signal recherché	Question ou situation qui le révèle	Réponse qui doit alerter
Sur-ingénierie	« Qu'est-ce que vous livreriez dans un mois ? »	Rien d'utilisable avant que les bases soient posées
Refus du legacy	« Vous arrivez sur un code écrit par une agence. Premier mois ? »	Tout réécrire, avant même d'avoir lu le code
Allergie au produit	Laisser la fin de l'entretien libre	Aucune question sur les clients ni sur l'usage
Responsabilité	« Un projet qui s'est mal passé : votre part ? »	La faute des autres, sans aucune part personnelle
Production	« La dernière panne que vous avez gérée ? »	« Ce n'était pas mon périmètre »
Estimation	Décrire une fonctionnalité floue et demander un délai	Une date ferme, sans hypothèse ni question

Écoutez aussi ce que les références ne disent pas. Quand un ancien manager répond « très bon techniquement » et s'arrête là, relancez : « le réembaucheriez-vous dans une équipe de trois personnes ? ». L'hésitation est souvent plus parlante que la réponse.

Il avait rendu le meilleur exercice. Mais sur une heure d'entretien, il ne m'a jamais demandé qui étaient mes clients.

un fondateur, à propos d'un candidat écarté malgré un excellent test

Les faux red flags qui écartent de bons candidats

L'excès inverse existe, et il coûte cher aussi : on élimine des profils solides sur des signaux qui n'en sont pas.

Des passages courts dans plusieurs startups. Les jeunes entreprises ferment, pivotent ou licencient. Trois expériences d'un an dans des startups disparues racontent souvent une personne à l'aise avec l'incertitude, pas une personne instable. Demandez simplement pourquoi chaque aventure s'est arrêtée.

Un profil GitHub vide. L'essentiel du code écrit en entreprise est privé. Un développeur qui travaille beaucoup n'a pas forcément le temps ou l'envie de publier des projets personnels le week-end.

Peu d'aisance à l'oral. Certains excellents développeurs sont réservés face à un inconnu, surtout en début d'entretien. Jugez la clarté du raisonnement plutôt que le débit, et laissez-leur une seconde occasion, à l'écrit ou dans un échange plus informel.

« Je ne connais pas votre stack. » Un bon développeur apprend un nouveau langage en quelques semaines. L'honnêteté sur ce point est plutôt un bon signe, à condition qu'il explique comment il s'y prendrait.

Un signal, et après ?

Un red flag isolé n'est pas une élimination automatique : c'est une piste à creuser, par une relance, un test ou une référence ciblée. Deux signaux qui convergent, en revanche, doivent vous arrêter, même si le reste du dossier est brillant et même si le poste est ouvert depuis trop longtemps. C'est précisément dans l'urgence que les signaux sont balayés.

Pour tenir cette lecture sans compétence technique, appuyez-vous sur une grille écrite, comme celle que je propose dans évaluer un développeur sans être technique, et sur un pair qui relit la partie code. Et si vous recrutez votre tout premier développeur, le processus complet est posé dans composer sa première équipe tech après le MVP pour le choix du profil, puis dans recruter son premier développeur sans être technique pour la méthode.

Un pair technique pour lire les signaux avec vous ?

J'accompagne des fondateurs dans leurs recrutements tech : grille d'entretien, relecture des exercices, participation aux entretiens finaux. Découvrez la création d'équipe tech et produit, ou réservons 30 minutes pour en parler.