Comment optimiser le processus de recrutement DevOps via le paradigme CALMS?

Une grande partie du recrutement DevOps se trouve suivre les lignes de la correspondance des mots clés, ce qui conduit à mon avis à se concentrer uniquement sur la technologie.

Désormais, DevOps est bien plus qu'une simple technologie, et DevOps Engineer n'est pas seulement un meilleur administrateur système avec des compétences en codage.

Le rôle / profil DevOps senior signifie pour moi également offrir de l'ancienneté dans de nombreuses autres fondations et pratiques au-delà des compétences en infrastructure et en génie logiciel comme Lean, Measurement et être ouvert et communicatif (qui demande honnêtement à DevOps embauche ses compétences en communication?!)

Ainsi, une annonce d'emploi / un entretien peut-il être plus efficace d'une manière ou d'une autre - par exemple, en appliquant également des catégories CALMS de questionnement ? - Menant à des questions comme «maintenant, comment appliquez-vous les principes Lean? Comment les aspects culturels ont-ils été abordés dans vos récents projets DevOps?

Poursuite de l'élaboration:

• C ulture (par exemple, stratégies de gestion des conflits et attitude face aux échecs, propres et autres)
• Une utomation (ici vous posez des questions sur les compétences Puppet / Docker, etc.)
• L ean (fondements de Lean? Types de déchets?)
• M esure (demander des outils comme JMeter , mais aussi aller à des choses comme l' échantillonnage, la modélisation des données ..)
• S haring (évidemment gestion des connaissances et outils correspondants)

MISE À JOUR - alors pourquoi les employeurs / recruteurs ne structureraient-ils pas l'entretien par CALMS comme indiqué ci-dessous (en outre, la section "automatisation" pourrait être formulée le long du modèle de chaîne d'outils DevOps ( lien vers le document, en lecture seule )?

Remarque - la culture par exemple n'est plus une compétence non technique, pour DevOps, c'est l'une des compétences de base - comme toutes les autres dans ce domaine.

C'est une idée brillante, également à cause de Daniel Kahneman qui a montré que si vous divisez un seul score en 5 scores pondérés et ajoutez des critères numériques et des limites à ceux-ci, vous réduirez considérablement le biais . Vous pouvez concevoir non seulement la notation du CV, mais l'ensemble du processus d'embauche, avec des écrans de téléphone, des entretiens sur place, tout de cette façon. Cela réduirait considérablement le biais inhérent des enquêteurs. Nous avons en fait commencé à faire quelque chose de similaire pour toutes les embauches.

De toute évidence, dans chaque domaine, vous devez ajouter du poids à ce qui est important pour l'entreprise pour le poste, mais vous embauchez un ingénieur complet et vous voulez quelqu'un qui proposera des changements majeurs au fonctionnement de votre organisation, vous n'embauchez pas simplement quelqu'un pour des compétences spécifiques pour travailler dans un domaine limité. Beaucoup de gens voient simplement ce rôle comme un ingénieur Release and Build mieux payé et si tel est le cas, c'est ce que vous devriez embaucher et faire de la publicité.

Pour une location DevOps, je suggère de remplacer le Lean par Learning. Il s'agit à l'origine de CAMS et même si certains l'étendent à CALMS pour inclure le Lean, cela est quelque peu restrictif car DevOps est basé sur bien plus que le Lean. Ce sont aussi les idées de Deming sur la variation de cause spéciale et commune et la pensée systémique, l'équilibre de Nash (si chacun s'optimise pour lui-même, le résultat pourrait être sous-optimal, par rapport à quand tout le monde inclut l'intérêt du groupe), Shewhart's Statistical Process Control , Goldratt's Théorie des contraintes , anti-fragilité de Taleb et bien d'autres.

Cela vous permettrait également d'inclure la participation à des conférences sur l'apprentissage et des présentations lors de conférences ou de rencontres en tant que partage. Dans une position où vous ne faites pas toujours partie d'une équipe ou où votre entreprise n'est peut-être pas assez grande pour avoir vos pairs comme collègues, il est encore plus important d'établir et de maintenir des relations hors du lieu de travail et des opportunités d'apprentissage. Nous avons généralement regroupé ces deux sous Culture.

Je mettrais personnellement sous Culture les compétences générales nécessaires pour être efficace dans l'amélioration des processus dans votre organisation. CMMI , Kanban , limites Work in Progress , pratiques Agiles, etc.

JIRA ressemble plus à l'outil de partage et Git est plus étroitement lié à l'automatisation.

ÉDITER

Je crois que cela dépend d'une organisation à l'autre et de ce que l'on attend d'un DevOps / Senior DevOps, par conséquent, votre première phrase est exacte à 100%. Car, un DevOps devrait être capable d'utiliser un ensemble d'outils que l'entreprise utilise et également améliorer ou apporter un nouvel ensemble d'outils qui permet à l'entreprise et à ses développeurs de travailler plus rapidement et de gaspiller moins.

À mon avis, un DevOps devrait avoir de solides compétences SysAdmin et évidemment des compétences de codage comme Puppet, Chef, Python, Bash seront largement utilisées ainsi qu'une certaine connaissance du code qui va sur les serveurs au moins pour pouvoir faire un débogage mineur sur pourquoi l'application ne se comporte pas comme prévu d'un environnement à l'autre.

Désormais, en tant que Senior DevOps, CALM peut être appliqué, mais les principes Lean et Measurement peuvent / peuvent ne pas s'appliquer. Par exemple, nous développons des applications à l'aide de Chef / Puppet / Ansible pour automatiser les choses banales et garder tout synchronisé, ce qui fait évidemment gagner du temps et produit moins de déchets .

En ce qui concerne la mesure, je ne sais pas si c'est applicable dans la plupart des cas. Cependant, les autres principes CALM font partie d'une position DevOps.

Avoir de bonnes compétences en communication est également important en tant que DevOps, mais plus important en tant que DevOps senior, car vous devrez non seulement traiter avec votre équipe et partager les connaissances et avec les développeurs car vous êtes là pour les soutenir, mais vous devrez également créer des rapports et garder des présentations devant la direction.

J'aime la feuille de calcul que vous avez ajoutée et c'est bien d'avoir un système de points, cependant, certaines entreprises ajoutent également plus de compétences / technologies dans une offre d'emploi que nécessaire.

De plus, après un entretien téléphonique (s'il y en a un), je trouverais utile que lors d'un entretien, vous rencontriez des problèmes à résoudre ou au moins pour montrer votre processus de débogage et comment vous vous comporterez dans des situations données. Personnellement, je n'aime pas les tests écrits car je pense qu'il n'y a pas de moyens de résoudre un problème, et aussi, parfois, Google est votre ami, car vous ne devez pas tout savoir par cœur.

En tant que DevOps / Senior DevOps, je pense qu'il y a une frontière entre les applications utilisées et les connaissances. Vous pourriez être étonnant à utiliser ces nouveaux / anciens outils ou à écrire du code, mais quand il s'agit de déboguer ou simplement de comprendre quel est le problème avec un serveur, le travail de Jenkins peut être que vous n'êtes pas en mesure de le faire.

Enfin, la feuille de calcul présentée, je pense, est un moyen d'évaluer une connaissance DevOps également pour un poste senior.Je pourrais y ajouter quelques compétences interpersonnelles et de gestion pour la compléter.

Et en ce qui concerne le processus de sélection, vous pouvez consulter la feuille de calcul et choisir la personne avec un score qui, selon vous, est le bon pour votre organisation, tout en gardant à l'esprit son (er) comportement pendant l'entretien et la manière Il a présenté / répondu à ces questions.