Anti-modèles d'entretiens DevOps

Bonjour à tous, mes chers lecteurs !

Aujourd'hui, je souhaite partager mes réflexions sur un sujet qui me tient à cœur depuis longtemps et peut-être en discuter dans les commentaires.
Il m'arrive assez souvent de tomber sur des articles concernant les mauvaises pratiques d'entretien pour le poste de programmeur, qui, à mon avis, sont assez pertinentes et, je l'espère, lisibles par les départements RH des grandes entreprises comme des moyennes.

Dans notre région, autant que je puisse en juger, il existe une demande pour des entités aussi intéressantes que les ingénieurs DevOps. Je fais partie de ceux qui n'acceptent pas très bien cette terminologie (oui, oui, la méthodologie DevOps, etc.), donc je perçois certaines différences dans les parcours professionnels de ce groupe de spécialistes.
Avant tout, je crois fermement que chaque personne a son propre cercle d'intérêts, même dans le domaine professionnel, c'est-à-dire que certains préfèrent le cloud, d'autres aiment plonger en profondeur dans les serveurs d'applications, configurer en détail Java, et certains préfèrent coder en Python ou, Dieu nous préserve, en YAML. Ainsi, apparaissent ce qu'on appelle des ingénieurs d'infrastructure, des ingénieurs de build, des développeurs YAML seniors 🙂.
Tout cela permet, d'une part, de trouver une personne qui correspond au mieux à votre ensemble de tâches, mais, d'autre part, crée une incompréhension lors des entretiens.
En me basant sur mon expérience personnelle, ayant passé un certain nombre d'entretiens, et également participé à divers occasions en tant que répondant, je souhaite partager mon point de vue sur tout cela.

Le premier et probablement mon anti-pattern préféré — le désir de vouloir quelqu'un qui fasse tout, ou de ne pas savoir qui est réellement nécessaire, regardons un tas de candidats, puis nous comprendrons. Cela s'applique sûrement à tous les domaines, mais il y a des particularités ici.
Comme je l'ai remarqué, les gens sont plus attirés par les offres d'emploi contenant le mot DevOps que par celles de System Administrator, même si, à mon avis, au niveau senior, les domaines de responsabilité diffèrent considérablement entre ces deux champs.
Tout employeur qui a réellement besoin d'un administrateur système écrit dans le titre de l'offre DevOps, énumérant dans le corps de la demande absolument tout, K8S/Java/gradle/oracleDB, etc., alors qu'en réalité, la personne devra s'occuper de la maintenance du cluster K8S et du support de la pile OracleDB, séparément de l'équipe.
Alors, quel type d'interaction y a-t-il entre les développeurs et les opérations ?
Il s'avère ensuite qu'il n'existe pas de processus d'interaction avec l'équipe et qu'en général, il n'y a pas de département dedicated aux opérations, et vous devrez également configurer les ordinateurs des développeurs.
Cette option convient en réalité à une partie des candidats, mais soyons honnêtes, c'est un poste de Senior System Administrator, alors pourquoi ne pas le rédiger ainsi et qu'est-ce qui est honteux là-dedans ? La différence de salaire entre les différents intitulés ? Mais le budget de l'entreprise est le même, et peu importe comment on nomme le navire, il naviguera avec son budget.
J'ai aussi entendu dire que de nos jours, le candidat automatise tout rapidement et intègre le développement de produit en Python, peu importe, c'est toujours le même Python. La différence de mentalité et d'approches n'est pas prise en compte.

De plus, je différencie généralement le niveau des spécialistes qui viennent et pour chacun je vois mes propres difficultés.
Junior — pour moi, un Junior DevOps est une personne qui a maîtrisé le sysadmin / le développement à un niveau intermédiaire. Ici, il est agréable de différencier les bons utilisateurs de Linux qui souhaitent évoluer dans un nouveau domaine, ou les développeurs qui ont envie de bien faire pour d'autres développeurs. De solides compétences, avec certaines compétences en débogage, en recherche de logs, ou ayant quelques projets codés en réserve.
J'ai rencontré des sysadmins qui ont essayé quelque chose et veulent toucher aux nuages, ainsi que ceux qui ont essayé le front, le back et pour une raison quelconque ont trouvé de l'intérêt dans les processus DevOps.
À ce niveau, je suis toujours dérangé quand on me parle d'une vaste pile de technologies, Puppet, Ansible — pourquoi n'a-t-il pas tout essayé ? K8S, K3S — quelle est la différence ? Combien de types de bases de données connais-tu ? Pourquoi si peu ? Comment fonctionne le chiffrement en Java ? Surtout pour ceux qui viennent du développement, bien que ce soient des profils très utiles, il y a toujours du travail dans ce domaine pour eux.
Je suis toujours stupéfait quand cela arrive, la première question qui me vient à l'esprit est — pourquoi ??? La seconde — est-ce que l'intervieweur est prêt à répondre à des questions sur une telle diversité de technologies ? Ne veulent-ils vraiment recruter un junior et lui confier tout ?
Cela arrive souvent dans divers bodys shops, quand il faut vendre quelqu'un pour un projet et qu'il faut plus de mots impressionnants pour le CV ou l'entreprise ne veut tout simplement personne, mais regarde juste quels juniors existent.

Niveau Middle
Il y a plusieurs extrêmes à mon avis. D'une part, il est difficile de définir clairement ce qui pousse une personne vers un niveau intermédiaire. On essaie soit de la rétrograder au niveau junior, soit de la traiter comme un senior, essayant de tirer profit d'un senior au prix d'un intermédiaire (eh oui, le marché décide, rien de personnel).
Ce qui m'étonne le plus, c'est de plonger profondément dans le code, de jongler avec Python, de malmener le GC de Java, c'est-à-dire des sujets déjà plus spécialisés, ou au contraire, de combler les lacunes dans des connaissances longtemps délaissées, de passer en revue les réseaux, les types de pilotes OS, en souriant et en se moquant de comment une personne a pu oublier cela. Et là, la partie la plus intéressante commence !
En ce qui concerne le niveau intermédiaire, à mon avis, un spécialiste développe un cercle d'intérêts et une vision personnelle de ce avec quoi il veut travailler : surfer sur la dernière tendance technologique en intégrant un petit coup de pouce, ou s'élever pour un terrible projet d'entreprise, plongeant dans la performance du code.
Il serait déjà judicieux de l'interroger sur les processus auxquels la personne a participé, de connaître ce qui a suscité le plus d'intérêt et ce qui ne l'a pas été, puis de construire un cluster de questions basé sur ces informations, en mappant systématiquement les questions à notre pile. Autrement, après une conversation captivante d'une à deux heures sur la configuration d'un cluster OpenShift, recruter une personne et la faire construire un monitoring pourrait plaire aux deux parties.

Niveau Senior
Oh, mon niveau préféré.
Voici un spécialiste aguerri, qui a cultivé ses compétences sur divers projets, une personne qui sait déjà ce qu'elle veut et ce qui ne l'intéresse pas vraiment.
Et voici que commence le spectacle :
— questions approfondies sur l'administration système (voir le premier anti-modèle)
— questions détaillées sur Linux, tirées de théories éloignées des connaissances pratiques (la question phare des niveaux OSI)
— questions académiques sur le codage (parce que l'intervieweur lui-même ne connaît pas bien le domaine, on lui a simplement demandé d'interviewer un DevOps un peu étrange)
Je ferai ici une petite remarque. Une fois, lors d'un entretien, on m'a demandé d'écrire un morceau de code. Sur un morceau de papier. Comme tout le monde aime, on écrit chaque jour, un morceau de papier, c'est notre tout.
Après avoir terminé la tâche, après avoir consulté ma feuille et trouvé une solution, le verdict a été rendu que l'algorithme serait sous-optimal. J'ai proposé que l'intervieweur écrive son propre algorithme, à quoi j'ai reçu la réponse : « Ce n'est pas dans le cadre de l'entretien ». J'ai demandé une minute, j'ai modifié un peu le code et j'ai montré, demandant si c'était plus rapide ou plus lent ? À quoi j'ai reçu la réponse de passer à la question suivante. La différence était dans le fonctionnement du code en boucle et sans boucle et j'avais préparé une réponse expliquant pourquoi il vaut mieux faire ainsi plutôt que cela. Eh bien, après cela, je n'avais plus du tout envie de répondre aux questions et de travailler avec cette personne.
Il faut garder à l'esprit que nous sommes tous différents et que n'importe quel détail, qui vous semble insignifiant, peut effrayer le candidat.
— généralement, les spécialistes de niveau Senior ont un stack de travail clairement défini, mais non, il faut commencer à les interroger sur des choses proches, par exemple, vous avez écrit Ansible, excellent, mais chez nous c'est Puppet, nous vous avons juste invité pour ça, alors parlez-nous de Puppet. Magnifique ! Avez-vous travaillé avec OpenShift ? Nous avons K8s, nous ne savons pas faire de différence, mais votre expérience n'est pas pertinente. Très bien !

Il y a aussi cette sous-catégorie — personnellement, je prends des stagiaires pour les faire grandir en juniors.
Il est vital que tout le monde comprenne qu'un stagiaire est une entité encore non formée. Cela me fait peur quand les stagiaires commencent à être poussés au niveau de Junior aguerri et ensuite, on leur propose des stages (parfois non rémunérés, l'horreur !)
Ne faites pas cela.
À mon avis, un stagiaire est soit un étudiant de dernière année, soit quelqu'un qui a vraiment envie de « se lancer dans l'IT ».
Avec les étudiants, tout est simple — il faut comprendre ce qu'ils font à l'université, ce qu'ils ont fait par eux-mêmes, observer sur quelles questions leurs yeux s'illuminent — si ça s'illumine, demander pourquoi ils s'intéressent au DevOps et ce qu'ils en savent. Sentir la personne et évaluer s'il sera agréable de travailler avec elle, si l'on a envie d'enseigner quelque chose à cette personne en particulier.
Avec ceux qui souhaitent « se lancer dans l'IT », c'est un peu plus strict — il faut évaluer dans quelle mesure la personne s'autoforme, ce qu'elle a fait avant de venir à l'entretien et un bon indicateur sera de regarder son GitHub, s'il en a un, la fréquence des commits et quels exercices elle a réalisés. Demander aussi pourquoi le DevOps, puisque le front-end est plus amusant et plus élaboré ?

Et enfin, je tiens à donner un conseil une fois de plus : définissez qui vous avez vraiment besoin et vous trouverez immédiatement la personne nécessaire. Identifiez les besoins, considérez le spécialiste comme un professionnel, trouvez ses points forts et utilisez-les efficacement dans votre travail. Soyez attentif à l’interviewé, il est venu chez vous pour une discussion, et non pour une compétition sur qui va échouer ou réussir.

Source : habr.com