Comment apprivoiser un junior ?

Comment entrer dans une grande entreprise si on est junior ? Comment embaucher un junior décent si vous êtes une grande entreprise ? Sous la coupe, je vais vous raconter notre histoire d'embauche de débutants dès le début : comment nous avons travaillé sur les tâches de test, préparé les entretiens et construit un programme de mentorat pour le développement et l'intégration des nouveaux arrivants, et aussi pourquoi les questions d'entretien standard ne sont pas disponibles. ça ne marche pas.

J'essaye d'apprivoiser Junior

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

Pourquoi avons-nous même pensé à embaucher des juniors ?

Jusqu'à récemment, nous recrutions des développeurs de niveau intermédiaire ou senior pour le frontend - suffisamment indépendants pour effectuer des tâches liées au produit après l'intégration. Au début de cette année, nous avons réalisé que nous souhaitions changer cette politique : au cours de l'année, le nombre de nos équipes produit a presque doublé, le nombre de développeurs front-end a approché la centaine, et dans un futur proche tout cela va je dois encore doubler. Il y a beaucoup de travail, peu de mains libres, et il y en a encore moins sur le marché, nous avons donc décidé de nous tourner vers les gars qui commencent tout juste leur voyage dans le front-end et avons réalisé que nous étions prêts à investir dans leur développement.

Qui est un junior ?

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

Il faut expliquer à Junior quelle fonctionnalité et comment le faire. Il faut expliquer au milieu quelle fonctionnalité est nécessaire et il déterminera lui-même la mise en œuvre. Le signataire vous expliquera lui-même pourquoi cette fonctionnalité n'est pas du tout nécessaire.

D'une manière ou d'une autre, un junior est un développeur qui a besoin de conseils pour mettre en œuvre telle ou telle solution. Ce sur quoi nous avons décidé de bâtir :

1. Junior est quelqu'un qui veut se développer et est prêt à travailler dur pour cela ;
2. Il ne sait pas toujours dans quelle direction il veut évoluer ;
3. A besoin de conseils et recherche de l’aide de l’extérieur – de son responsable, de son mentor ou de la communauté.

Nous avions également plusieurs hypothèses :

1. Il y aura une tempête de réponses à la position de June. Vous devez filtrer les réponses aléatoires au stade de l'envoi de votre CV ;
2. Un filtre principal n'aidera pas. — davantage de tâches de test sont nécessaires ;
3. Les tâches de test feront fuir tout le monde - 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 l'entonnoir le plus large possible et essayer de le rétrécir progressivement afin de pouvoir traiter le flux, mais sans le réduire à 1 candidat par semaine.

Nous publions une offre d'emploi

Pour la compagnie: Il y aura des centaines de réponses ! Pensez à un filtre.

Pour les juniors: N'ayez pas peur du questionnaire avant d'envoyer votre CV et votre devoir de test - c'est le signe que l'entreprise a pris soin de vous et a bien mis en place le processus.

Le premier jour, nous avons reçu environ 70 CV de candidats « connaissant JavaScript ». Et puis encore. Et plus loin. Nous ne pouvions physiquement pas inviter tout le monde au bureau pour un entretien et choisir parmi eux les gars avec les projets les plus cool, Github en direct ou au moins l'expérience.

Mais la principale conclusion que nous avons tirée dès le premier jour était que la tempête avait commencé. Il est maintenant temps d'ajouter un formulaire de questionnaire avant de soumettre votre CV. Son objectif était d’éliminer les candidats qui n’étaient pas disposés à faire le minimum d’efforts pour soumettre un curriculum vitae, et ceux qui n’avaient pas les connaissances et le contexte nécessaires pour au moins rechercher les bonnes réponses sur Google.

Il contenait des questions standard sur JS, la mise en page, le Web, l'informatique - tous ceux qui imaginent ce qu'ils demandent lors d'un entretien frontal les connaissent. Quelle est la différence entre let/var/const ? Comment puis-je appliquer des styles uniquement aux écrans d’une largeur inférieure à 600 px ? Nous ne voulions pas poser ces questions lors d'un entretien technique - la pratique a montré qu'on peut y répondre après 2-3 entretiens sans aucune compréhension du développement. Mais ils ont pu dans un premier temps nous montrer si le candidat, en principe, comprend le contexte.

Dans chaque catégorie, nous avons préparé 3 à 5 questions et jour après jour nous avons modifié leur ensemble dans le formulaire de réponse jusqu'à éliminer les plus passables et les plus difficiles. Cela nous a permis de réduire le débit - en 3 semaines nous avons reçu 122 candidats, avec lequel nous pourrions travailler davantage. C'étaient des étudiants en informatique ; les gars qui voulaient passer du backend au front ; des ouvriers ou des ingénieurs, âgés de 25 à 35 ans, qui souhaitaient changer radicalement de métier et s'investissaient plus ou moins dans l'autoformation, les cours et les stages.

Mieux se connaître

Pour la compagnie: La tâche de test ne dissuade pas les candidats, mais contribue à raccourcir l'entonnoir.

Pour les juniors: Ne copiez pas ceux de test - cela se remarque. Et gardez votre github en ordre !

Si nous convoquions tout le monde pour un entretien technique, nous devrions mener environ 40 entretiens par semaine uniquement pour les juniors et uniquement sur le front-end. Par conséquent, nous avons décidé de tester la deuxième hypothèse – concernant la tâche de test.

Ce qui était important pour nous lors du test :

1. Construire une bonne architecture évolutive, mais sans ingénierie excessive ;
2. Il est préférable de prendre plus de temps, mais de le faire bien, que de monter un bricolage du jour au lendemain et de l'envoyer avec le commentaire « Je vais certainement le terminer » ;
3. L’histoire du développement dans Git repose sur la culture de l’ingénierie, le développement itératif et le fait que la solution n’a pas été copiée de manière flagrante.

Nous avons convenu que nous voulions examiner un problème algorithmique et une petite application Web. Les algorithmes ont été préparés au niveau des laboratoires de niveau élémentaire - 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 option d’essai. L'application Web devait être un tic-tac-toe utilisant n'importe quel framework (ou sans).

Près de la moitié des gars restants ont terminé la tâche de test - ils nous ont envoyé les solutions 54 candidats. Un aperçu incroyable : combien d'implémentations de tic-tac-toe, prêtes à copier-coller, pensez-vous qu'il existe sur Internet ?

Combien?En fait, il semble qu’il n’y en ait que 3. Et dans la grande majorité des décisions, il y avait précisément ces 3 options.
Ce qui n'a pas aimé:

• copier-coller, ou développement basé sur le même tutoriel sans votre propre architecture ;
• les deux tâches se trouvent dans le même référentiel dans des dossiers différents, bien sûr, il n'y a pas d'historique de validation ;
• code sale, violation DRY, manque de formatage ;
• un mélange de modèle, de vue et de contrôleur en une seule classe de plusieurs centaines de lignes de code ;
• manque de compréhension des tests unitaires ;
• une solution « frontale » est un code en dur d'une matrice 3x3 de combinaisons gagnantes, qui sera assez difficile à étendre à 10x10, par exemple.

Nous avons également prêté attention aux référentiels voisins - des projets sympas pour animaux de compagnie étaient un plus, et un tas de tâches de test d'autres entreprises étaient plutôt un signal d'alarme : pourquoi le candidat n'a-t-il pas pu y arriver ?

En conséquence, nous avons trouvé des options intéressantes dans React, Angular, Vanilla JS - il y en avait 29. Et nous avons décidé d'inviter un candidat supplémentaire sans tester pour ses projets favoris très sympas. Notre hypothèse sur les bénéfices des tâches de test a été confirmée.

Entretien technique

Pour la compagnie: Ce ne sont pas des intermédiaires/seniors qui sont venus vers vous ! Nous avons besoin d’une approche plus individuelle.

Pour les juniors: N'oubliez pas qu'il ne s'agit pas d'un examen - n'essayez pas de garder le silence pour un C ou de bombarder le professeur d'un flot de toutes vos connaissances possibles afin qu'il se confonde et donne un « excellent ».

Que veut-on comprendre lors d’un entretien technique ? Une chose simple : comment pense le candidat. Il possède sans doute quelques hard skills s'il a passé les premières étapes de sélection, reste à savoir s'il saura les utiliser. Nous nous sommes mis d'accord sur 3 tâches.

Le premier concerne les algorithmes et les structures de données. Avec un stylo, sur une feuille de papier, en pseudo-langage et à l'aide de dessins, nous avons compris comment copier un arbre ou comment supprimer un élément d'une liste à chaînage unique. La découverte désagréable a été que tout le monde ne comprend pas la récursion et le fonctionnement des références.

La seconde est le codage en direct. Nous sommes allés à codewars.com, a choisi des choses simples comme trier un tableau de mots selon la dernière lettre et pendant 30 à 40 minutes avec le candidat, il a essayé de faire réussir tous les tests. Il semblait qu'il ne devrait y avoir aucune surprise de la part des gars qui maîtrisaient le tic-tac-toe - mais dans la pratique, tout le monde n'a pas pu se rendre compte que la valeur devait être stockée dans une variable et que la fonction devait renvoyer quelque chose via return. Même si j'espère sincèrement que c'était une nervosité, et que les gars ont pu faire face à ces tâches dans des conditions plus légères.

Enfin, le troisième concerne un peu l'architecture. Nous avons expliqué comment créer une barre de recherche, comment fonctionne l'anti-rebond, comment afficher divers widgets dans les astuces de recherche, comment le front-end peut interagir avec le back-end. Il existait de nombreuses solutions intéressantes, notamment le rendu côté serveur et les sockets Web.

Nous avons mené 21 entretiens en utilisant ce modèle. Le public était complètement diversifié - regardons les bandes dessinées :

1. "Fusée". Il ne se calme jamais, se mêle de tout et lors d'un entretien il vous submergera d'un flot de pensées qui ne sont même pas directement liées à la question posée. Si c'était dans une université, ce serait une tentative familière de démontrer, eh bien, toutes vos connaissances, alors que tout ce dont vous vous souvenez du billet que vous avez trouvé, c'est qu'hier soir vous avez décidé de ne pas l'étudier - vous ne pouvez toujours pas obtenir IT out.
2. "Groot". C'est assez difficile d'entrer en contact avec lui car c'est Groot. Lors d’un entretien, il faut passer beaucoup de temps à essayer d’obtenir des réponses mot à mot. C'est bien si ce n'est qu'une stupeur - sinon ce sera très difficile pour vous dans votre travail quotidien.
3. "Drax". J'ai travaillé dans le transport de marchandises, et en termes de programmation, je n'ai appris JS que sur Stackoverflow, donc je ne comprends pas toujours de quoi on parle lors d'un entretien. En même temps, c’est une bonne personne, il a les meilleures intentions et veut devenir un excellent développeur front-end.
4. Nous allons probablement "Seigneur des étoiles". Dans l’ensemble, c’est un bon candidat avec qui vous pourrez négocier et construire un dialogue.

Au terme de nos recherches 7 candidats ont atteint la finale, confirmant leurs compétences avec un excellent test et de bonnes réponses à l'entretien.

Ajustement culturel

Pour la compagnie: Vous travaillez avec lui ! Le candidat est-il prêt à travailler extrêmement dur pour son développement ? Va-t-il vraiment s'intégrer dans l'équipe ?

Pour les juniors: Vous travaillez avec eux ! L'entreprise est-elle vraiment prête à investir dans la croissance des juniors, ou va-t-elle simplement vous décharger de tout le sale boulot pour un bas salaire ?

Chaque junior, en plus de l'équipe produit, dont le leader doit accepter de l'embaucher, bénéficie d'un mentor. La tâche du mentor est de le guider tout au long d’un processus d’intégration et de mise à niveau de compétences techniques d’une durée de trois mois. Par conséquent, nous sommes venus à chaque adéquation culturelle en tant que mentors et avons répondu à la question : « Vais-je prendre la responsabilité de développer un candidat en 3 mois selon notre plan ?

Cette étape s'est déroulée sans particularité et nous a finalement amené 4 offres, dont 3 ont été acceptés, et les gars sont entrés dans les équipes.

La vie après l'offre

Pour la compagnie: Prenez soin de vos juniors ou d'autres le feront !

Pour les juniors: AAAAAAAAAAAA !!!

Lorsqu'un nouvel employé arrive, il doit être intégré - mis au courant des processus, expliqué comment tout fonctionne dans l'entreprise et dans l'équipe, et comment il devrait travailler en général. Quand un junior sort, il faut comprendre comment le développer.

En y réfléchissant, nous avons dressé une liste de 26 compétences qu'un junior devrait, selon nous, posséder à la fin de la période d'intégration de trois mois. Cela comprenait des compétences techniques (selon notre stack), la connaissance de nos processus, Scrum, de l'infrastructure et de l'architecture du projet. Nous les avons regroupés dans une feuille de route, répartie sur 3 mois.

Par exemple, voici la feuille de route de mon junior

Nous attribuons un mentor à chaque junior qui travaille avec lui individuellement. 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 quelque chose de plus que simplement écrire du code.

Une partie du fardeau des mentors est allégée par les cours de notre pile - Dart, Angular. Les cours ont lieu régulièrement pour de petits groupes de 4 à 6 personnes, où les étudiants étudient sans interruption du travail.

Au cours d'une période de 3 mois, nous recueillons périodiquement les commentaires des juniors, de leurs mentors et responsables et ajustons le processus individuellement. Les compétences gonflées sont vérifiées 1 à 2 fois pendant toute la période, le même contrôle est effectué à la fin - sur la base d'elles, des recommandations sont formées sur ce qui doit exactement être amélioré.

Conclusion

Pour la compagnie: Vaut-il la peine d'investir dans les juniors ? Oui!

Pour les juniors: Recherchez des entreprises qui sélectionnent soigneusement les candidats et savent les développer

Pendant 3 mois, nous avons examiné 122 questionnaires, 54 tâches de test et mené 21 entretiens techniques. Cela nous a amené 3 grands juniors qui ont désormais réalisé la moitié de leur feuille de route d'intégration et d'accélération. Ils accomplissent déjà de véritables tâches de produit dans notre projet, où il y a plus de 2 000 000 de lignes de code et plus de 400 référentiels rien que sur le front-end.

Nous avons découvert que l'entonnoir pour les juniors peut et doit être assez complexe, mais en fin de compte, seuls les gars qui sont vraiment prêts à travailler très dur et à investir dans leur développement y passent.

Désormais, notre tâche principale est de réaliser des feuilles de route de développement de trois mois pour chaque junior sous forme de travail individuel avec un mentor et de cours généraux, de collecter des métriques, des commentaires des leads, des mentors et des gars eux-mêmes. À ce stade, la première expérience peut être considérée comme terminée, des conclusions peuvent être tirées, le processus peut être amélioré et il peut être relancé pour sélectionner de nouveaux candidats.

Source: habr.com