Comment nous avons embauché un développeur open source

En tant que PDG et co-fondateur de Profien, une start-up de sécurité, j’ai participé à nos efforts pour embaucher des développeurs pour travailler sur Énarx, un projet de sécurité qui traite de l’informatique confidentielle, écrit presque exclusivement en Rust (avec un peu d’assembleur). Profian a maintenant trouvé toutes les personnes qu’il recherchait dans cette recherche, avec quelques développeurs qui devraient commencer dans les prochaines semaines. Cependant, les nouveaux contributeurs sont absolument les bienvenus chez Enarx, et si les choses continuent de bien se passer, l’entreprise voudra certainement embaucher plus de personnes à l’avenir.

Embaucher des gens n’est pas facile, et Profian avait un ensemble d’exigences spécialisées qui rendaient la tâche encore plus difficile. J’ai pensé qu’il serait utile et intéressant pour la communauté de partager la façon dont nous avons abordé le problème.

Que cherchions-nous ?

Voici les exigences spécialisées dont je parle :

• Programmation système : Profian a principalement besoin de personnes qui sont heureuses de programmer au niveau des systèmes. C’est assez loin dans la pile, avec beaucoup d’interactions directement avec le matériel ou le système d’exploitation. Pour créer des pièces client-serveur, par exemple, nous devons écrire un grand nombre de protocoles, gérer la cryptographie, etc., et les outils pour cela ne sont pas tous très matures (voir “Rust” ci-dessous).

• Rouiller: Presque tout le projet est écrit en Rust, et ce qui ne l’est pas est écrit en langage assembleur (actuellement exclusivement x86, bien que cela puisse changer à mesure que nous ajoutons plus de plates-formes). Rust est nouveau, cool et excitant, mais il est encore assez jeune, et certains domaines n’ont pas tout le support que vous pourriez aimer ou ne sont pas aussi matures que vous l’espérez – tout, de la cryptographie aux bibliothèques multithreading et au compilateur/build Infrastructure.

• Equipe distribuée : Profian est en train de constituer une équipe de personnes où nous pouvons les trouver. Profian a des développeurs en Allemagne, en Finlande, aux Pays-Bas, en Caroline du Nord (États-Unis), au Massachusetts (États-Unis), en Virginie (États-Unis) et en Géorgie (États-Unis). Je suis au Royaume-Uni, notre community manager est au Brésil et nous avons des stagiaires en Inde et au Nigeria. Nous savions dès le début que nous n’aurions pas tout le monde au même endroit, et cela nécessitait des personnes capables de communiquer et de collaborer avec d’autres personnes par vidéo, chat et (au pire) e-mail.

• Sécurité: Enarx est un projet de sécurité. Bien que nous ne recherchions pas spécifiquement des experts en sécurité, nous avons besoin de personnes capables de penser et de travailler en gardant à l’esprit la sécurité et de concevoir et d’écrire du code applicable et adapté à l’environnement.

• Gite : Tout notre code est stocké dans git (principalement GitHub, avec un peu de GitLab ajouté). une grande partie de notre interaction autour du code tourne autour de git que quiconque nous rejoignant devrait être très à l’aise de l’utiliser comme outil standard dans son travail quotidien.

• Open source: L’open source n’est pas qu’une licence ; c’est un état d’esprit et, tout aussi important, une façon de collaborer. Une grande partie des logiciels open source est créée par des personnes qui ne sont pas géographiquement proches et qui ne se considèrent même pas comme une équipe. Nous avions besoin de savoir que les personnes que nous embauchions, tout en formant une équipe proche au sein de l’entreprise, seraient capables de collaborer avec des personnes extérieures à l’organisation et d’adopter la culture “ouverte par défaut” de Profian, non seulement pour le code, mais aussi pour les discussions, les communications , et documentation.

Comment les avons-nous trouvés ?

Comme je l’ai dit ailleurs, le recrutement est difficile. Profian a utilisé une variété de moyens pour trouver des candidats, avec différents niveaux de succès :

• Les annonces d’emploi sur LinkedIn
• Recherches LinkedIn
• Forums de discussion et forums de recrutement spécifiques à une langue (par exemple, Reddit)
• Un recruteur externe (merci à Gerald à Interstem)
• Bouche-à-oreille/recommandations personnelles

Il est difficile de juger entre ces sources en termes de qualité, mais sans recruteur externe, nous aurions certainement eu du mal avec la quantité (et nous avons également eu d’excellents candidats de cette voie).

Comment les avons-nous sélectionnés ?

Nous devions mesurer tous les candidats par rapport à toutes les exigences indiquées ci-dessus, mais tous n’étaient pas égaux. Par exemple, bien que nous souhaitions embaucher des programmeurs Rust, quelqu’un ayant de solides compétences en C/C++ au niveau des systèmes serait capable de maîtriser Rust assez rapidement pour être utile. D’un autre côté, une bonne connaissance de l’utilisation de git était absolument essentielle, car nous ne pouvions pas passer du temps à travailler avec de nouveaux membres de l’équipe pour les mettre au courant de notre façon de travailler.

Une solide expérience open source n’était, peut-être étonnamment, pas une exigence, mais l’état d’esprit pour travailler dans ce type de modèle l’était, et toute personne ayant des antécédents d’implication open source est susceptible d’avoir une bonne connaissance de git. Il en va de même pour la capacité à travailler dans une équipe distribuée : une telle quantité d’open source est distribuée que l’implication dans presque toutes les communautés open source était un indicateur positif. La sécurité, avons-nous décidé, était une qualification “agréable à avoir”.

Nous voulions garder le processus simple et rapide. Profian n’a pas de fonction RH ou People dédiée, et nous sommes occupés à essayer d’écrire du code. C’est ce que nous avons obtenu (avec de légères variations), et nous avons essayé de le terminer en 1-2 semaines :

1. Examen initial du CV / curriculum vitae / GitHub / GitLab / LinkedIn pour décider s’il convient d’interviewer
2. Discussion de 30 à 40 minutes avec moi en tant que PDG, pour savoir s’ils pourraient être un bon ajustement culturel, pour leur donner une chance de se renseigner sur nous et pour avoir une idée s’ils étaient aussi compétents techniquement qu’ils apparaissaient à l’étape 1
3. Discussion technique approfondie dirigée par Nathaniel, généralement avec moi là-bas
4. Discutez avec les autres membres de l’équipe
5. Exercice de codage
6. Décision rapide (généralement dans les 24 heures)

L’exercice de codage était essentiel, mais nous avons décidé de ne pas suivre l’approche habituelle. Notre point de vue était qu’un pur exercice de “codage d’algorithmes” apprécié par de nombreuses entreprises technologiques était pratiquement inutile pour ce que nous voulions : savoir si un candidat pouvait rapidement comprendre un morceau de code, résoudre certains problèmes et travailler avec l’équipe pour faire alors. Nous avons créé un référentiel GitHub contenant du code Rust presque fonctionnel (en fait, nous avons fini par en utiliser deux, dont un pour les personnes un peu plus haut dans la pile), puis avons demandé aux candidats de le réparer, d’effectuer des processus liés à git sur et améliorez-le légèrement, en ajoutant des tests en cours de route.

Une partie essentielle du test consistait à amener les candidats à interagir avec l’équipe via notre ou nos salons de discussion. Nous avons prévu 15 minutes d’appel vidéo pour la configuration et les questions initiales, deux heures pour l’exercice (“livre ouvert” – en plus de parler à l’équipe, les candidats étaient encouragés à utiliser toutes les ressources à leur disposition sur Internet), suivies de une séance de synthèse de 30 minutes où l’équipe pouvait poser des questions et le candidat pouvait réfléchir à la tâche. Cette conversation, combinée aux interactions de clavardage pendant l’exercice, nous a permis d’avoir une idée de la façon dont le candidat était capable de communiquer avec l’équipe. Ensuite, le candidat décrochait l’appel et nous décidions le plus souvent dans les 5 à 10 minutes si nous voulions les embaucher.

Cette méthode a généralement très bien fonctionné. Certains candidats ont eu du mal avec la tâche, certains n’ont pas bien communiqué, d’autres n’ont pas bien réussi avec les interactions git – ce sont les personnes que nous n’avons pas embauchées. Cela ne signifie pas qu’ils ne sont pas de bons codeurs ou qu’ils ne conviendront peut-être pas au projet ou à l’entreprise plus tard, mais ils ne répondent pas aux critères dont nous avons besoin maintenant. Parmi les développeurs que nous avons embauchés, le niveau d’expérience Rust et le besoin d’interaction avec l’équipe variaient, mais le niveau d’expertise git et leurs réactions à nos discussions par la suite étaient toujours suffisants pour que nous décidions de les prendre.

Reflets

Dans l’ensemble, je ne pense pas que nous changerions énormément le processus de sélection, même si je suis à peu près sûr que nous pourrions faire mieux avec le processus de recherche. Le parcours jusqu’à l’exercice de codage nous a permis de filtrer un certain nombre de candidats, et l’exercice de codage a fait un excellent travail en nous aidant à choisir les bonnes personnes. Espérons que tous ceux qui ont suivi le processus conviendront parfaitement et produiront un excellent code (et des tests, de la documentation et …) pour le projet. Le temps nous le dira!

Cet article est initialement paru sur Alice, Eve et Bob – un blog sur la sécurité et est republié avec autorisation.