LebSource

Recrutement

Évaluer un développeur quand on n’est pas technique

Vous pouvez évaluer plus de choses que vous ne le croyez sans lire de code, et les parties que vous ne pouvez réellement pas évaluer s’empruntent pour une heure.

21 October 20258 min de lecture

Le conseil habituel donné à un fondateur non technicien est de trouver quelqu’un de technique pour mener l’entretien, ce qui est exact et inutile, car si vous aviez cette personne vous ne liriez pas ceci. La version plus utile est plus étroite : il y a des parties de cette évaluation que vous faites mieux que la plupart des ingénieurs, des parties que vous ne pouvez pas faire du tout, et un moyen peu coûteux d’acheter les secondes pour environ une heure.

À dire d’emblée : vous ne cherchez pas à établir que quelqu’un est un bon ingénieur dans l’absolu. Vous cherchez à établir qu’il peut faire le travail précis que vous avez, et qu’il vous dira la vérité dessus pendant qu’il le fait. Ce sont là des questions largement non techniques.

Ce que vous pouvez évaluer directement

Quatre points, et ils prédisent le résultat mieux que la plupart des gens ne l’imaginent.

  • S’ils savent vous expliquer leur propre travail. Pas simplifié jusqu’à l’insignifiance, mais expliqué : quel était le problème, ce qu’ils ont choisi, ce que cela a coûté.
  • Ce qu’ils vous demandent. Les bons ingénieurs interrogent le besoin avant de l’estimer. Quelqu’un qui accepte un brief de deux phrases et annonce un chiffre vous a appris quelque chose.
  • Leur façon de gérer le fait de ne pas savoir. Interrogez-les sur un sujet hors de leur domaine et observez s’ils le disent simplement ou s’ils se mettent à produire du brouillard.
  • Ce qu’ils regrettent. Toute personne réellement expérimentée a une décision qui a mal tourné. Un candidat sans une telle histoire n’a pas beaucoup livré ou est en train de vous gérer.

Rien de tout cela n’exige de lire du code, et tout cela est difficile à simuler pendant quarante minutes.

Le test d’explication, mené correctement

Prenez un élément de leur CV et demandez-leur de vous l’expliquer comme à un nouvel arrivant côté métier. Posez ensuite une question de suivi qu’ils n’ont pas pu répéter : que feriez-vous différemment aujourd’hui, et quelle partie a pris le plus de temps pour des raisons que personne n’avait prévues.

Vous écoutez la structure. Une bonne réponse va du problème à la contrainte, puis au choix, puis à la conséquence, et comporte au moins une chose qui a mal tourné. Une réponse faible est une liste de technologies. Si vous vous découvrez incapable de résumer ensuite l’histoire en trois phrases, c’est une vraie conclusion, pas une défaillance de votre compréhension.

La discussion sur l’estimation

Décrivez un travail dont vous avez réellement besoin. Demandez comment ils l’aborderaient et ce qui le ferait durer deux fois plus longtemps. La seconde moitié est toute la question.

Les gens expérimentés nomment des risques précis : les données sont sans doute plus sales que décrit, l’API tierce ne prend peut-être pas en charge ce que la fonctionnalité suppose, le code existant dans ce périmètre n’a peut-être pas de tests. Les personnes inexpérimentées ou négligentes vous donnent une durée et une formule rassurante. Vous n’avez pas besoin d’évaluer la justesse technique des risques pour remarquer si l’un d’eux a été nommé.

Ce que vous ne pouvez pas évaluer, et devriez cesser de faire semblant d’évaluer

Vous ne pouvez pas juger si leur code est bon, si leurs intuitions d’architecture sont saines, ni si l’approche décrite est l’approche évidente ou une excentricité. Le charme personnel, un anglais fluide et l’assurance ne remplacent rien ici, et ce sont exactement les qualités qui vous égareront si vous essayez.

C’est une vraie lacune et elle doit être comblée par quelqu’un d’autre. La bonne nouvelle, c’est que cela prend une heure, une seule fois, par candidat retenu.

Qui emprunter, et comment le briefer

Classées à peu près par degré de confiance à accorder au résultat : un ingénieur que vous connaissez personnellement et qui n’a aucun intérêt dans l’issue ; un responsable technique à temps partagé ou en intérim, payé pour deux heures ; un ingénieur d’une entreprise amie, à qui vous rendrez le même service ; un consultant recruté spécifiquement pour mener des entretiens techniques.

Briefez-les par écrit, brièvement. Dites-leur le travail que la personne fera réellement, en quoi consiste votre système existant, et la question à laquelle vous voulez le plus une réponse. Demandez ensuite un retour d’une forme précise : recruteriez-vous cette personne pour ce travail, où est-elle faible, et que surveilleriez-vous le premier mois. Sans ce cadrage, vous obtenez une note sur dix, qui n’est pas exploitable.

L’ingénieur expérimenté du prestataire peut se joindre à l’appel et se révèle souvent réellement utile, en particulier sur les détails propres à la pile technique. Gardez simplement à l’esprit l’évidence : il n’est pas neutre, et son évaluation doit être traitée comme un élément d’appréciation et non comme le verdict.

Lire un exercice pratique sans lire de code

Si vous recevez un dépôt ou un exercice, certaines choses sont visibles. Y a-t-il un README expliquant comment l’exécuter et pourquoi il est construit ainsi ? Y a-t-il seulement des tests ? L’historique des commits est-il une suite d’étapes intelligibles ou un unique commit appelé « final » ? Ont-ils noté ce qu’ils feraient avec plus de temps ?

Aucun de ces éléments ne prouve que le code est bon. Tous montrent si la personne communique par écrit sur son travail, spontanément, quand personne ne la regarde. Sur une mission à distance entre fuseaux horaires, cette habitude compte à peu près autant que le code.

Le mode de défaillance à surveiller

Les évaluateurs non techniques surévaluent systématiquement l’aisance verbale. Le candidat qui parle bien, acquiesce volontiers et ne dit jamais un mot décourageant passe un excellent entretien et se révèle souvent le recrutement le plus faible, car les qualités que vous avez appréciées en entretien sont celles qui vous cacheront les problèmes ensuite.

Un correctif brutal : au moins une fois pendant l’entretien, avancez une idée légèrement erronée sur votre propre produit ou votre plan et voyez si la personne conteste. Celle qui exprime poliment son désaccord avec celui qui s’apprête à la recruter vous montre le comportement le plus précieux que vous puissiez acheter à distance.

Traitez ensuite le premier mois comme le véritable entretien

Aucun processus d’entretien ne remplace vraiment le fait de travailler ensemble, et le vôtre est plus mince que la moyenne : prévoyez donc délibérément la suite. Convenez d’un travail réel, restreint et achevable pour les deux premières semaines, avec une définition claire du « terminé », et d’un point écrit à la fin du premier mois portant sur ce qui a été livré et ce qui a gêné.

Organisez cela comme un essai rémunéré et équitable, avec des conditions de sortie symétriques, plutôt que comme une audition non payée, et les deux parties obtiennent tôt une réponse honnête. Si vous recrutez via un prestataire, la même chose vaut avec un ajout : convenez d’emblée de ce à quoi ressemble un remplacement, pour qu’une inadéquation soit un problème de planning et non une négociation.

Étape suivante

Prêt à constituer ou à agrandir votre équipe ?

Dites-nous ce dont vous avez besoin et nous vous mettrons en relation avec des professionnels libanais présélectionnés, prêts à s’intégrer à votre équipe.