🥇Comment apprivoiser un junior ?

Comment intégrer une grande entreprise en tant que junior ? Comment recruter un bon junior si vous êtes une grande entreprise ? Dans cet article, je vais vous raconter notre histoire de recrutement de jeunes talents en front-end : comment nous avons élaboré des tests, préparé nos entretiens et mis en place un programme de mentorat pour le développement et l'intégration des nouveaux arrivants, ainsi que les raisons pour lesquelles les questions d'entrevue standard ne fonctionnent pas.

J'essaie de former un junior

Bonjour ! Je m'appelle Pavel, je fais du front-end dans l'équipe de Wrike. Nous créons un système de gestion de projet et de collaboration. Je travaille dans le web depuis 2010, j'ai passé 3 ans à travailler à distance pour des entreprises à l'étranger, j'ai participé à plusieurs start-ups et j'ai enseigné un cours sur les technologies web à l'université. Dans l'entreprise, je participe au développement des cours techniques et au programme de mentorat Wrike pour les juniors, ainsi qu'à leur recrutement direct.

Pourquoi avons-nous envisagé de recruter des juniors

Jusqu'à récemment, nous engagions des développeurs front-end de niveau middle ou senior — suffisamment autonomes pour pouvoir résoudre des tâches produit après leur intégration. Au début de cette année, nous avons réalisé que nous voulions changer cette politique : en un an, le nombre de nos équipes produit a presque doublé, le nombre de développeurs front-end a atteint près de cent, et à court terme, cela devrait encore doubler. Il y a beaucoup de travail, peu de bras disponibles, et encore moins sur le marché, donc nous avons décidé de faire appel à des personnes qui commencent tout juste leur parcours dans le front-end et nous avons compris que nous étions prêts à investir dans leur développement.

Qui est un junior ?

C'est la première question que nous nous sommes posée. Il existe différents critères, mais le principe le plus simple et compréhensible est le suivant :

Un junior a besoin qu'on lui explique quelle fonctionnalité créer et comment le faire. Un middle a besoin qu'on lui explique quelle fonctionnalité est nécessaire, et il s'en occupera lui-même. Un senior, quant à lui, te dira pourquoi cette fonctionnalité ne doit pas être réalisée du tout.

Quoi qu'il en soit, un junior est ce développeur qui a besoin de conseils pour réaliser une solution donnée. Sur quoi nous avons décidé de nous baser :

Un junior est celui qui souhaite se développer et est prêt à travailler dur pour cela ;
Il ne sait pas toujours dans quelle direction il veut se développer ;
Il a besoin de conseils et cherche de l'aide extérieure — que ce soit auprès de son lead, son mentor ou dans la communauté.

Nous avions également quelques hypothèses :

Pour le poste de junior, il y aura une tempête de candidatures.Il faut filtrer les candidatures aléatoires dès l'envoi du CV ;
Le filtre initial ne suffira pas. — il faut encore des tests.
Les tests vont tous les effrayer. — ils ne sont pas nécessaires.

Et bien sûr, nous avions un objectif : 4 juniors en 3 semaines..

Avec cette prise de conscience, nous avons commencé à expérimenter. Le plan était simple : commencer avec un entonnoir aussi large que possible et essayer de le resserrer progressivement pour pouvoir traiter le flux, sans le réduire à un candidat par semaine.

Nous publions l'offre d'emploi.

Pour l'entreprise :: Il y aura des centaines de candidatures ! Pensez au filtre.
Pour le junior :: N'ayez pas peur du questionnaire avant l'envoi du CV et du test — c'est un signe que l'entreprise se soucie de vous et a bien organisé le processus.

Dès le premier jour, nous avons reçu environ 70 CV de candidats avec « connaissance de JavaScript ». Et puis encore. Et encore. Nous ne pouvions physiquement pas tous les inviter à un entretien au bureau et avons sélectionné ceux avec les projets personnels les plus intéressants, un GitHub actif ou au moins de l'expérience.

Mais la principale conclusion que nous avons tirée dès le premier jour — la tempête avait commencé. Il était temps d'ajouter un questionnaire avant l'envoi du CV. Cette tâche visait à filtrer les candidats qui n'étaient pas prêts à fournir un minimum d'efforts pour envoyer un CV, et ceux qui n'avaient pas les connaissances et le contexte suffisants pour rechercher les bonnes réponses.

Il y avait des questions standard sur JS, le développement web, l'informatique — des questions que chacun sait qui sont posées lors d'un entretien en front-end. Quelle est la différence entre let/var/const ? Comment appliquer des styles uniquement pour les écrans plus petits que 600px de large ? Nous ne voulions pas poser ces questions lors de l'entretien technique — l'expérience a montré qu'on peut y répondre après 2-3 entretiens, sans vraiment comprendre le développement. Mais elles nous ont permis de déterminer si, en principe, le candidat saisissait le contexte.

Dans chaque catégorie, nous avions préparé 3 à 5 questions et, jour après jour, nous avons modifié leur ensemble dans le formulaire de réponse, jusqu'à ce que nous ayons exclu les questions les plus simples et les plus difficiles. Cela a permis de réduire le flux — en 3 semaines, nous avons reçu 122 candidats., avec lesquels nous pouvions travailler par la suite. Ce sont des étudiants en IT ; des gars qui ont voulu passer du backend au frontend ; des travailleurs ou des ingénieurs âgés de 25 à 35 ans, qui ont radicalement voulu changer de domaine et ont consacré divers efforts à l'auto-formation, aux cours et aux stages.

Faisons connaissance

Pour l'entreprise :: Le test technique n'effraie pas les candidats, mais aide à raccourcir le processus de sélection.
Pour le junior :: Ne copiez pas les tests - c'est évident. Et gardez votre GitHub en ordre !

Si nous avions invité tout le monde à un entretien technique, nous aurions dû réaliser environ 40 entretiens par semaine rien que pour les juniors et seulement en frontend. C'est pourquoi nous avons décidé de vérifier la seconde hypothèse — à propos du test technique.

Ce qui était important pour nous dans le test :

Construire une bonne architecture évolutive, mais sans sur-architecture ;
Il vaut mieux prendre plus de temps, mais bien faire, que de bâcler quelque chose en une nuit en envoyant un commentaire « je vais absolument finir » ;
L'historique de développement dans Git — culture d'ingénierie, itération du développement et le fait que la solution n'est pas copiée de manière éhontée.

Nous nous sommes mis d'accord sur le fait que nous voulions examiner un problème algorithmique et une petite application web. Les problèmes algorithmiques étaient préparés au niveau des laboratoires des cours initiaux — recherche binaire, tri, vérification des anagrammes, travail avec des listes et des arbres. En fin de compte, nous avons opté pour la recherche binaire comme première variante d'essai. L'application web devait être un morpion en utilisant n'importe quel framework (ou sans).

Près de la moitié des candidats restés ont réussi le test — nous avons reçu des solutions 54 candidats. Une révélation incroyable — combien pensez-vous qu'il y a de réalisations de morpion prêtes à être copiées sur Internet ?

Combien ?En réalité, il semble qu'il n'y en ait que 3. Et dans la majorité écrasante des solutions, il s'agissait précisément de ces 3 variantes.
Ce qui n'a pas plu :

copier-coller, ou développement d'après un même tutoriel sans architecture propre;
les deux tâches dans un même dépôt dans des dossiers différents, sans historique de commit bien sûr ;
code sale, violation du principe DRY, absence de formatage ;
mélange du modèle, de la vue et du contrôleur dans une seule classe de plusieurs centaines de lignes de code ;
absence de compréhension des tests unitaires ;
La solution « brute » — le hardcodage d'une matrice de combinaisons gagnantes 3x3, ce qui serait assez difficile à étendre à 10x10, par exemple.

Nous avons également prêté attention aux dépôts voisins — de superbes projets personnels ont réussi, tandis qu'une multitude de tests d'autres entreprises était plutôt un signal d'alarme : pourquoi le candidat n'a-t-il pas pu réussir là-bas ?

En fin de compte, nous avons trouvé d'excellents candidats sur React, Angular, Vanilla JS — au total, 29. Et nous avons décidé d'inviter un autre candidat sans test en raison de ses projets personnels très impressionnants. Notre hypothèse concernant l'utilité des tests s'est confirmée.

Entretien technique

Pour l'entreprise :: Vous n'avez pas affaire à des mid-level/seniors ! Il faut un approche plus individualisée.
Pour le junior :: Rappelez-vous que ce n'est pas un examen — n'essayez pas de rester silencieux avec une note moyenne ou de submerger le professeur avec tout votre savoir afin qu'il se perde et vous donne un « excellent ».

Que voulons-nous comprendre lors de l'entretien technique ? La chose simple — comment le candidat pense. Il a probablement certaines compétences techniques s'il a réussi les premières étapes de sélection — il reste à déterminer s'il sait les appliquer. Nous avons convenu de 3 tâches.

La première — les algorithmes et les structures de données. Avec un stylo, sur une feuille, dans un pseudo-langage et à l'aide de dessins, nous avons discuté de la manière de copier un arbre ou de supprimer un élément d'une liste simplement chaînée. La découverte désagréable a été que tout le monde ne comprend pas la récursion et comment fonctionnent les références.

La deuxième — le live coding. Nous avons accès à codewars.com, nous choisissions des choses simples comme trier un tableau de mots par la dernière lettre et, pendant 30 à 40 minutes, nous essayions, avec le candidat, de faire passer tous les tests. Il semblait qu'il ne devrait pas y avoir de surprises de la part de ceux qui avaient maîtrisé les morpions — mais dans la pratique, pas tout le monde a pu comprendre qu'une valeur doit être conservée dans une variable et qu'une fonction doit renvoyer quelque chose via return. Bien que j'espère sincèrement que c'était seulement un stress momentané, et que les candidats ont pu résoudre ces tâches dans des conditions plus relaxées.

Enfin, la troisième — un peu sur l'architecture. Nous avons discuté de la manière de créer une barre de recherche, comment fonctionne le debounce, comment rendre divers widgets dans les suggestions de recherche, comment le front-end peut interagir avec le back-end. De nombreuses solutions intéressantes ont été trouvées, y compris au sujet du rendu côté serveur et des WebSockets.

Nous avons mené 21 entretiens selon ce schéma. Le public était totalement hétéroclite — parlons de comics :

«Rocket». Il ne se repose jamais, s'immisce partout, et lors des entretiens, il vous submergera avec un flot de pensées, parfois même sans lien direct avec la question posée. Si cela se passait à l'université, ce serait un moment familier pour beaucoup : essayer de démontrer tous ses savoirs, même si on se souvient seulement la veille qu'on ne voulait pas l'étudier — de toute façon, on n'en sortira rien.
«Groot». Avec lui, il est assez difficile d'établir le contact, car il est Groot. Pendant les entretiens, il faut longuement tirer les réponses mot par mot. C'est bien si c'est juste un blocage — sinon, cela sera très difficile dans le travail quotidien.
«Drax». Auparavant, il s'occupait de transport de marchandises, et en programmation, il n'a appris que le JS sur Stackoverflow, donc il ne comprend pas toujours de quoi l'on parle lors de l'entretien. Ceci dit, c'est une bonne personne, avec de bonnes intentions et qui veut devenir un excellent développeur front-end.
Et probablement, «Star-Lord». En général, c'est un bon candidat avec qui on peut s'entendre et établir un dialogue.

À la fin de nos recherches 7 candidats ont été sélectionnés pour la finale, confirmant leurs compétences techniques avec une excellente tâche de test et de bonnes réponses lors des entretiens.

Cultural fit

Pour l'entreprise :: Est-ce que vous allez pouvoir travailler avec lui ! Est-il vraiment prêt à travailler extrêmement dur pour son développement ? S'intégrera-t-il bien dans l'équipe ?
Pour le junior :: Est-ce que vous allez pouvoir travailler avec eux ! La société est-elle vraiment prête à investir dans la croissance des juniors, ou va-t-elle simplement vous laisser toute la sale besogne pour un salaire bas ?

Chaque junior, en plus de l'équipe produit, dont le leader doit accepter de l'accueillir, se voit attribué un mentor. La tâche du mentor est de le guider à travers un processus d'intégration de trois mois et de développement des compétences techniques. Donc, pour chaque évaluation de culture, nous venions en tant que mentors et nous nous posions la question : « Vais-je prendre la responsabilité de former le candidat en 3 mois selon notre plan ? »

Cette étape s'est déroulée sans particularité et au final, elle nous a rapporté 4 offres, dont 3 ont été acceptées, et les gars ont rejoint les équipes.

La vie après une offre

Pour l'entreprise :: Prenez soin de vos juniors, ou d'autres le feront !
Pour le junior :: AAAAAAAAAAAAAA!!!

Lorsque un nouvel employé arrive, il doit être intégré — être informé des processus, comprendre comment tout fonctionne dans l'entreprise et l'équipe, et comment travailler en général. Lorsqu'un junior entre, il faut déterminer comment le développer.

Lorsque nous avons réfléchi à cela, nous avons établi une liste de 26 compétences que, selon nous, un junior doit acquérir d'ici la fin de sa période d'intégration de trois mois. Cela inclut des compétences techniques (selon notre stack), des connaissances sur nos processus, le Scrum, l'infrastructure et l'architecture du projet. Nous les avons regroupées dans une feuille de route, étalée sur trois mois.

Par exemple, voici la feuille de route de mon junior

Nous assignons un mentor à chaque junior, qui travaille avec lui de manière individuelle. Selon le mentor et le niveau actuel du candidat, les rencontres peuvent avoir lieu de 1 à 5 fois par semaine pendant 1 heure. Les mentors sont des développeurs front-end bénévoles qui souhaitent faire plus que simplement écrire du code.

Une partie de la charge des mentors est allégée par des cours sur notre stack — Dart, Angular. Les cours sont proposés régulièrement pour de petits groupes de 4 à 6 personnes, où les participants travaillent sans interruption de leur travail.

Au cours des 3 mois, nous recueillons périodiquement des retours d'expérience des juniors, de leurs mentors et des leaders, et nous ajustons le processus individuellement. 1 à 2 fois durant toute la période, une vérification des compétences acquises est effectuée, et une vérification similaire est menée à la fin — des recommandations sont ensuite formulées sur ce qu'il convient d'améliorer.

Conclusion

Pour l'entreprise :: Faut-il investir dans les juniors ? Oui !
Pour le junior :: Recherchez des entreprises qui sélectionnent rigoureusement les candidats et savent comment les développer.

En 3 mois, nous avons examiné 122 questionnaires, 54 épreuves techniques et avons réalisé 21 entretiens techniques. Cela nous a permis de recruter 3 super juniors, qui ont déjà terminé la moitié de leurs feuilles de route d'intégration et d'accélération. Ils résolvent déjà de réelles tâches produit dans notre projet, où il y a plus de 2 000 000 de lignes de code uniquement sur le front-end et plus de 400 dépôts.

Nous avons découvert que le processus pour les juniors peut et doit être suffisamment complexe, mais au final, seuls les candidats vraiment prêts à travailler dur et à investir dans leur développement réussissent à le franchir.

Actuellement, notre principal objectif est de finaliser les feuilles de route de trois mois pour le développement de chaque junior en mode de travail individuel avec un mentor et des cours communs, de rassembler des métriques, des retours d'expérience des leads, des mentors et des membres eux-mêmes. À ce stade, on pourra considérer le premier essai comme terminé, tirer des conclusions, améliorer le processus et le relancer pour sélectionner de nouveaux candidats.

Source : habr.com