Comment engager de meilleurs développeurs

[Note] Ceci est un article écrit du point de vue d'une entreprise de recrutement ou du point de vue d'un employé désirant avoir des collègues sympathiques et compétents.

Je vais souligner les aspects concernant les développeurs dans leur ensemble, mais je parlerai davantage de l’expérience d’un développeur JS fullstack, de sorte que certaines choses pourraient ne pas correspondre à un gant pour votre cas.

Soulignant ces points, il n’est pas seulement question de ce qui ne va pas avec la majorité des processus d’embauche, mais aussi de quelques indicateurs clés sur ce qu’il faut examiner et ce qui pourrait être amélioré (à faire et à ne pas faire, mais surtout à ne pas faire).

  1. Ne posez pas de questions stupides

Demander à quelqu'un combien d'ananas peut tenir dans la carcasse d'une baleine, juste pour voir si cela correspond au résultat de vos réponses "magiques" artificielles, ne va aider personne, en particulier le cerveau du développeur.

2. Évitez de mettre de la pression et / ou de mettre en place des tâches fastidieuses ou trop compliquées.

À moins que votre entreprise soit vraiment c ** p, il est fort probable qu'une fonctionnalité ne sera pas publiée dans 20 minutes et je suis à peu près certaine que cela n'impliquera pas de retour en arrière ni d'arbres binaires, ni d'optimisations O (n) à l'aide de hashmaps.

Obtenir une réponse à ce genre de questions ou d’autres dépend également de la préparation mentale du développeur et de son humeur à ce moment précis, et ne vous en dit pas trop.

Cela vaut toujours la peine si les tests sont vraiment simples et servent simplement à filtrer les plus mauvais, ou juste pour que vous examiniez le processus de réflexion et entamez une discussion sur les compromis.

3. Écrire un code sur papier (en particulier un code spécifique à une langue)

À moins que vous ne soyez Google, il s’agit généralement d’une AF agaçante. Le fait que les grandes entreprises fassent cela ne veut pas dire que c’est bon, cela signifie simplement qu’elles peuvent se permettre de gaspiller de l'argent parce que les gens continueront à venir de toute façon. Ils ont donc le luxe de trouver des gens avec une base théorique très solide même s'ils savoir ou pas.

Soyons honnêtes, vous oubliez la plupart des algorithmes deux ou trois ans après votre sortie de l’université, à moins que vous ne travailliez sur un produit de bas niveau.

Mais .. un bon développeur doit-il savoir comment faire 4 types de tri? J'en doute.

Ce qui compte vraiment, c'est de pouvoir le comprendre simplement en le lisant et de comprendre les différences et les particularités de chacun.

Alors peut-être que vous pouvez simplement faire ce tri vous-même et simplement demander ce que cela fait, le mettre au défi de l'expliquer plus simplement pour repérer une bonne compréhension du code. De plus, si vous pouvez repérer les capacités mentales nécessaires pour traduire cette image en quelque chose de similaire, cela semble plus logique pour une personne moins technique, ce serait formidable.

Parce que s'il fait tout cela, vous pouvez être certain de pouvoir examiner chacun de ces algorithmes de graphes de fantaisie que vous aimez tant en quelques jours et de tout réapprendre si vous en avez vraiment besoin.

4. Arrêtez de poser des questions à l’API concernant un élément de technologie / langage qui n’est pas à ce sujet. Rechercher des concepts à la place

Ce que je veux dire par là, c'est que demander à quel point le langage de requête / syntaxe d'une opération MongoDB n'a aucun intérêt… Je pense que les personnes qui se souviennent parfaitement de la syntaxe d'API par cœur sont généralement de pires développeurs que celles qui l'oublient.

Sérieusement maintenant, comment allez-vous apprendre quelque chose de nouveau et rapidement si vous mémorisez des choses comme à l'école primaire? Dans le monde réel, vous devrez apprendre une autre technologie demain pour conserver votre avantage.

Où est votre powa ’maintenant?

En recherchant des concepts, je veux dire par exemple que vous devez savoir s'il comprend des concepts tels que la transactionnalité, l'évolutivité, les types de cohérence, la facilité d'intégration et la facilité d'utilisation des API disponibles pour son moteur, différents types de bases de données (document, sql). , graphique, etc.) et à quoi doit-il servir, dans les cas d’utilisation typiques et dans l’ensemble des points faibles / forts.

La mémorisation de l’API SQL est un autre exemple, "comment fabrique-t-on ce JOIN ou telle ou telle opération". Vous n'avez pas besoin de vous souvenir que pour le reste de votre vie, si vous avez une idée de base des bases de données relationnelles, un bon développeur devrait pouvoir vous dire les différentes mutations d'état et la manière dont les opérations sont effectuées dans ces types de bases de données. les compromis qui vont avec.

Et tout cela avec une utilisation d'API mineure à nulle.

Un bon développeur n'est pas un développeur qui sait comment résoudre votre problème sur un papier, mais qui sait quelles sont les opérations autorisées et les abstractions permises qui peuvent être effectuées pour le résoudre en donnant un environnement spécifique, et ne dispose pas nécessairement d'un écran matriciel. dans sa tête avec des instructions ou des morceaux de documentation de l'API.

Par exemple, demandez-lui quel type de base de données vous devez utiliser pour l'un de vos systèmes effectuant une tâche / un problème spécifique à un domaine que vous avez rencontré dans vos projets, et laissez-le vous expliquer le raisonnement qui la sous-tend.

5. Oui, mais connaissez-vous vraiment ce cadre? Combien d'expérience avez-vous avec?

Parfois cela compte, parfois non. Demander quelle sorte d’expérience vous avez avec React (parler du noyau ne réagit pas au jeu complet de la collection de morceaux de bibliothèque de trônes) ne demande fondamentalement rien si vous avez passé 2 ans ou plus à coder en JS jusqu’à maintenant.

React lui-même est une lecture de 2 à 3 jours au maximum pour en faire un usage pratique. Ce temps "perdu" est-il critique pour votre entreprise? Eh bien, si c’est le cas, c’est peut-être une entreprise de merde de toute façon, alors n’aies pas la peine de changer ça… continuez et allez-vous en avant (:

Si ce n’est pas le cas, vous voudrez peut-être demander au développeur des choses telles que le temps qu’il a passé à apprendre le cadre (insérer votre nom), à mieux comprendre le processus de réflexion, les opinions et leur changement progressif (étapes et courbes d’apprentissage). , barrages routiers, etc.), et ensuite comparez ces données à celles d’autres membres de l’équipe.

Waay plus utile. Demandez-lui ce qu’il aime et ce qu’il n’aime pas, cela devrait vous donner une idée rapide et précise de la profondeur qu’il a en profondeur si vous êtes vraiment dedans (pour une raison quelconque)

6. Un bon développeur doit savoir chercher

Je pense que c'est la partie qui fait la différence entre un nouveau diplômé / junior et un développeur de niveau intermédiaire ou senior.

La possibilité de trouver des réponses pour vous-même, de rechercher plus d'informations, de lire la documentation et de rechercher d'autres points de vue.

Les mauvais développeurs essaient généralement de réinventer la roue quand ce n’est pas le cas. Essayez de rechercher ce trait, et s’il manque, c’est définitivement un non-non.

7. Où vous voyez-vous dans X ans

S'il répond à cette quête… je plaisante… ne le faites pas, cette question mérite une section, car elle donne bonne mine aux autres questions stupides.

8. Mieux comprendre ses compétences techniques en le rendant amusant pour tout le monde

C’est en fait assez simple: donnez-lui un devoir de complexité moyenne / faible et laissez-le construire cette solution. Faites-lui suivre son temps approximatif écoulé dans chaque bloc majeur de la fonctionnalité qui vous intéresse, et posez peut-être une question ici et là une fois celui-ci terminé.

Les gens aiment être mis au défi, et il y a une tonne d'informations que vous pouvez obtenir sur quelqu'un en le faisant, plutôt que de le forcer à faire des choses comme le test du tableau blanc.

En outre, vous pouvez maintenant voir à quelle vitesse il peut saisir ‘insérez votre nom de structure’.

9. Ne prenez pas en compte ses opinions sur lui-même

Hein?

Demander à un développeur rockstar (qui a peut-être une faible estime de soi) ses compétences et le comparer aux réponses d’un développeur de niveau intermédiaire ne vous dira rien des compétences que vous recherchez, cela vous informera tout au plus de vos traits personnels.

Plus vous en apprenez, plus vous réalisez que vous ne savez pas grand-chose, c’est pourquoi le syndrome de l’imposteur est une réalité, qui se déroule actuellement, en particulier dans le monde des JS.

Si vous souhaitez obtenir des informations techniques utiles sur ce type de questions, vous devriez déjà les supprimer.

10. Donner assez de temps pour se prouver

Le monde de la technologie est complexe et les courbes d’apprentissage sont raides, même pour les plus brillants. La seule façon de savoir avec certitude si une personne s’y adapte est de passer plusieurs mois à travailler avec cette personne, c’est-à-dire si vous pouvez vous le permettre.

Tous les autres indicateurs ne disent pas grand chose par rapport à celui-ci, pas même l'expérience. Gardez cela à l'esprit, car quel que soit votre projet de trouver un développeur sous tous les angles, il risque fort d'échouer pour de nombreux candidats potentiels et de réussir pour certains mauvais.

___________________________________________________________________

Merci d'avoir lu :).

Tentez intentionnellement d’éviter d’écrire les pronoms spécifiques au genre (il / elle) car c’est 2016 et je veux éviter d’offenser les asexuels et certaines espèces d’hippocampes. J'aime les hippocampes.