Un de mes amis travaille dans une entreprise qui développe et entretient un ensemble de produits critiques. Si l'un de ces produits échoue à 3 heures du matin, il est obligatoire de faire quelque chose immédiatement pour le remettre en ligne, y compris de résoudre le problème dans le code source lui-même.
L'entreprise recherche maintenant un développeur capable de résoudre les problèmes liés au développement lui-même. L'ami sera en charge de la partie technique de l'entretien, et m'a demandé des indices.
En fait, un bon candidat doit être capable de résoudre des problèmes techniques sous un stress sévère. Si l'application cesse de fonctionner sur le serveur d'un client, l'entreprise paie une énorme pénalité par heure d'indisponibilité, ce qui signifie que le développeur saura que pendant qu'il travaille actuellement sur le problème, l'entreprise perd des milliers de dollars. Il peut également y avoir une pression indirecte de la part de clients en colère¹.
Comment puis-je émuler ou tester une situation aussi stressante lors d'un entretien?
Tous les éléments habituels utilisés lors de l'entretien pour tester comment une personne interrogée gérerait le stress² semble trop faible par rapport à ce que la personne ferait une fois embauchée, c'est-à-dire obligée de se précipiter en pleine nuit sur le lieu de travail pour résoudre un bug le plus rapidement possible.
Demander une expérience similaire précédente semble également difficile. Je ne sais pas s'il est fréquent de trouver des travailleurs qui ont travaillé dans des conditions aussi effrayantes.
Alors, comment puis-je évaluer cette compétence lors d'un entretien? Comment puis-je savoir qu'une personne a cette capacité à travailler sous le stress avant d'être embauchée?
Mise à jour: plus de deux ans se sont écoulés depuis J'ai posé cette question. J'ai gardé des contacts réguliers avec mon ami et j'étais heureux d'entendre beaucoup de bonnes nouvelles. L'entreprise a eu la chance d'embaucher des personnes talentueuses qui ont pris un tas de bonnes idées et les ont poussées jusqu'à la direction qui était assez intelligente pour les accepter, en leur faisant confiance inconditionnellement.
Parmi les changements, le workflow de développement a été entièrement repensé, avec l'introduction de DevOps qui fonctionne étonnamment bien. D'autres mesures liées aux revues de code, aux tests et à la qualité du code ont permis d'améliorer progressivement le produit. Maintenant, les développeurs n'ont plus peur de pousser leurs changements vers la production, car ils sont à peu près sûrs que ces changements ne casseront rien.
Il y avait aussi des choix difficiles à faire. Plusieurs programmeurs et managers ont été licenciés, en raison de leur manque de compétences et de leur réticence à apprendre, dont un manager qui était dans cette entreprise depuis vingt ans. La décision d'externaliser quelques emplois a également été douloureuse.
Cela étant dit, l'entreprise est devenue un lieu de travail beaucoup plus mature et, surtout, beaucoup plus agréable. Personne ne crie après les développeurs à cause d'une régression qu'ils ont introduite, car il n'y en a pas (du moins pas assez grave), et personne ne devrait se réveiller à 3 heures du matin car un problème a été découvert et devrait être résolu dès que possible.
Étonnamment , la solution était très simple: l'entreprise dispose désormais de trois équipes dans trois pays à travers le monde, choisies géographiquement pour qu'une soirée dans un pays corresponde plus ou moins au matin dans un autre pays (il y a, je crois, un décalage de trois heures à un moment donné qu'ils doivent gérer en demandant aux employés de commencer à travailler plus tard que d'habitude et de terminer plus tard également). Cela permet la disponibilité permanente de personnel qualifié chaque fois qu'un problème survient.
Le seul problème est qu'un ensemble de services est toujours hébergé en interne. Cela signifie que l'entreprise doit avoir des administrateurs système à portée de main jour et nuit, sur place, au cas où un problème surviendrait au centre de données lui-même (pannes de l'onduleur, inondation, les serveurs commencent à s'arrêter de manière inattendue, etc.)
Ce problème est sur le point de devenir obsolète. La société migre ses services vers Amazon EC2, qui semble être légèrement plus cher, mais aussi beaucoup plus fiable: un bon prix à payer.
Je suis à la fois heureux et triste: heureux d'apprendre que le L'entreprise se porte bien et je suis triste de me dire que j'ai concentré mon attention uniquement sur le processus de recrutement lui-même, au lieu d'avoir un regard plus large sur le problème, comme tout développeur est censé le faire. J'avais toutes les informations nécessaires pour penser à une image plus grande, mais je n'ai pas vu que la solution pour embaucher des personnes prêtes à se réveiller à 3 heures du matin est simplement de rendre le problème d'origine non pertinent, que ce soit en sous-traitant ou en migrant vers cloud computing.
Cela pourrait être une bonne leçon - du moins je la considère comme une pour moi. Au lieu de chercher des solutions centrées sur la gestion aux problèmes techniques qui rendent souvent les employés mécontents, il faut chercher des solutions techniques aux problèmes de gestion. Ce cas est une illustration parfaite de cela.
¹ Les développeurs ont un espace de travail séparé du service d'assistance, mais la nuit, je suis presque sûr que si un problème est détecté, il y aurait être seulement deux personnes dans le bâtiment de l'entreprise: le promoteur et la personne du support. Bien que la personne de support gérera tous les appels en dehors de l'espace de travail des développeurs, les deux continueront de parler ensemble, de sorte que le développeur saurait que le client attend une réponse rapide.
² Par exemple, demander à la personne interrogée de lire ou d'écrire du code pendant un laps de temps limité, ou poser des questions techniques sans dire si les réponses sont bonnes ou mauvaises, etc.