Tester les tâches lors de l'entretien avec le développeur - est-ce que cela a du sens?

Au cours de ma longue carrière informatique, j'ai réussi à visiter les deux côtés des entretiens et à voir toute la splendeur, la pauvreté, la folie et les bonnes pensées des missions de test émises lors des entretiens techniques des développeurs de logiciels.

Du côté du demandeur (alias développeur Petya)

Si Petya est au début de sa carrière de développeur, il sera très probablement intéressé par des tâches de test et est prêt à y consacrer son temps personnel. Pour les développeurs de niveau senior et supérieur, ces tâches s'ennuient déjà, surtout pas payées. Et comme un développeur contourne généralement plus d'une entreprise, le temps perdu sur les tâches de test peut être de plusieurs jours, voire plusieurs semaines!

Y a-t-il des tâches vraiment cool? Ils se produisent mais très rarement, peut-être un sur 100. Fondamentalement, tout est standard et pas intéressant - pour lire des données quelque part, faire quelque chose avec, écrire des données quelque part (fichier / base / socket ..). Ou implémentez un algorithme bien connu en place. Pourquoi en est-il ainsi? Oui, car, dans la plupart des cas, le locataire n'a qu'à éclaircir la pile de CV sur son bureau, je vous en parlerai plus tard.

Du côté de l'employeur (alias Timlid Vasya)

Vasya a deux douzaines de curriculum vitae parfaitement adaptés, parmi lesquels vous devez choisir un candidat digne pour votre équipe. Interviewez les deux douzaines de Vasya trop paresseux, et il n'y a aucune raison, et il décide de filtrer un peu la ligne et de choisir la plus digne. Bien sûr, Vasya sait que vous pouvez suivre le chemin, comme dans une célèbre blague:


Mais Vasya décide de suivre une autre voie très répandue - donner une tâche de test et l'envoyer à tous les candidats. Et puis le cirque avec des chevaux commence, ce qui montre l'absurdité des tâches de test.

Intervieweur

L'une des pires options pour les deux parties, si le chef d'équipe pour une raison quelconque (occupé, manquant de compétences, stupidement paresseux, est allé déjeuner) au lieu de lui-même envoie un membre de son équipe pour un entretien et prend une décision sur son rappel. Si cela se produit, le chef d'équipe ne prendra probablement pas sa place dans l'entreprise.

Délai d'exécution et portée

J'ai rempli des tâches pendant une demi-heure et une semaine, en moyenne, la plupart des employeurs comprennent qu'il ne vaut pas la peine d'exiger le candidat plus de quelques heures.

Qualité du code et du design

Ici, les employeurs tentent de mettre en œuvre ce dont ils sont privés dans le travail réel dans la définition des tâches - du code avec des commentaires, couvert de tests unitaires, toujours avec un style de code, et il y a eu des moments où vous aviez besoin d'un bref tutoriel sur le programme. Dans la plupart des cas, dans le travail réel, des exigences complètement différentes sont beaucoup plus prosaïques.

Format du travail

Vous pouvez trouver à la fois des tâches standard à la maison et des perversions telles que:

• écrire une décision au tableau (cela est généralement fait par des entreprises occidentales)
• écrire une solution dans le bloc-notes sur l'ordinateur portable de l'entreprise
• écrire une solution à distance en mode de programmation par paire

Que voit Vasya à la sortie?

Certains candidats tombent simplement parce qu'ils sont trop paresseux pour travailler gratuitement, certains n'aiment pas la tâche elle-même, certains ne répondent pas pleinement à toutes les conditions que Vasya a soigneusement prescrites et ils font un peu de mal. En conséquence, la liste des candidats s'amincit vraiment, mais pas du tout selon les principes que Vasya attendait. Au fil du temps, Vasya constate que la qualité de la tâche de test terminée et l'efficacité du nouveau développeur dans l'équipe sont faiblement corrélées et pour les candidats suivants n'insistent pas sur la tâche de test, passant au niveau suivant de l'évaluation du développeur.

Qu'aimeriez-vous voir Vasya?

Dans ses rêves roses, Vasya voit que le candidat commencera avec joie et enthousiasme à travailler sur la tâche de test et donnera son meilleur code jamais, couvert par des tests par les plus ingérables, avec une structure compétente (mais pas trop compliquée) et généreusement épicé de commentaires sensés.

Qu'est-ce qui donne des tâches de test en réalité?

L'écart entre la tâche de test et le travail réel est si large qu'il serait très naïf de projeter le résultat d'une petite tâche pendant 3 heures sur le long travail du développeur. Il reste beaucoup de choses en coulisse (débogage, dépannage, refactoring, l'architecture du projet est plus compliquée que Hello World , interaction avec des collègues), ce qui élimine quasiment tout bénéfice de telles tâches. Avec à peu près le même effet, vous pouvez simplement lancer une pièce et décider rapidement si le candidat convient ou non.

Il est bon de rattraper son retard, l'auteur, probablement dans les bureaux sympas, il y a moins de bêtises avec les tâches

Un cas bien connu est celui où l'auteur du gestionnaire de paquets Homebrew n'a pas été emmené sur Google, uniquement pour la raison qu'à la 7ème interview, il n'a pas pu écrire d'algorithme au tableau pour inverser l'arbre binaire. Combien d'entreprises difficiles perdent de telles tâches difficiles - on ne peut que deviner.

Quelles tâches de test ne sont pas nécessaires du tout?

Étant sur le site de Vasya, j'ai parfois donné des tâches de test afin d'avoir quelque chose à discuter après sa mise en œuvre. Mais seulement si le développeur lui-même n'est pas contre. Cela fonctionne bien pour les développeurs juniors et intermédiaires s'ils n'ont pas de code qu'ils peuvent démontrer. Senior'ov et au-dessus ne peuvent pas être appréciés par une petite tâche de test, ici une autre approche est nécessaire.

Les cas de test peuvent-ils vraiment bénéficier aux deux parties?

Compte tenu des inconvénients des cas de test traditionnels, certaines entreprises ont commencé à adopter une approche plus proche des conditions de travail. Le candidat reçoit une tâche réelle de la liste actuelle des tâches (carnet de commandes) de l'entreprise, qui peut être effectuée d'une journée à quelques semaines et est payée à un taux contractuel. Ainsi, le candidat a l'opportunité de travailler en mode d'essai avec une nouvelle équipe et en même temps de gagner de l'argent pour le temps passé. Cela vous permet d'évaluer le candidat plus précisément dans des conditions proches de l'armée, mais, malheureusement, peu d'entreprises peuvent se le permettre.

Un lecteur méticuleux demandera: «OK, auteur, sinon une tâche de test, alors comment pouvez-vous sélectionner la bonne personne âgée?» Et ceci est un sujet pour un article séparé, restez à l'écoute!