Antipatterns in DevOps Interviews

Ich heiße euch alle willkommen, meine lieben Leser!

Heute möchte ich meine Gedanken zu einem seit langem brennenden Thema teilen und möglicherweise darüber in den Kommentaren diskutieren.
Immer wieder stoße ich auf Artikel über schlechte Praktiken bei der Programmierer-Interviewführung, die meiner Meinung nach ziemlich relevant sind und, hoffentlich, von den HR-Abteilungen großer und kleiner Unternehmen gelesen werden.

In unserer Gegend, soweit ich beurteilen kann, gibt es eine Nachfrage nach solchen interessanten Entitäten wie DevOps-Ingenieuren. Ich gehöre zu denjenigen, die mit dieser Wortkombination nicht viel anfangen können (ja, ja, die DevOps-Methodologie usw.), deshalb sehe ich einige Unterschiede im Entwicklungspfad dieser Gruppe von Spezialisten.
Zunächst einmal glaube ich fest daran, dass jeder Mensch seinen eigenen Interessenkreis hat, auch im Arbeitsbereich. Das bedeutet, dass einige Menschen in der Cloud arbeiten wollen, andere sich mit dem tiefen eintauchen in Application Server beschäftigen, tief in Java eingreifen oder, Gott bewahre, YAML-Code schreiben möchten. Es entstehen also so genannte Infrastructure Engineers, Build Engineers, Senior YAML Developer 🙂
Das alles ermöglicht es, auf der einen Seite jemanden zu finden, der am besten zu eurem Aufgabenpool passt, und auf der anderen Seite führt es zu Missverständnissen in Interviews.
Aufgrund meiner persönlichen Erfahrung habe ich eine gewisse Anzahl von Dutzenden von Interviews durchgeführt und auch an verschiedenen als Antwortgeber teilgenommen, und möchte mein Fazit zu dem, was passiert ist, mitteilen.

Das erste und wahrscheinlich mein Lieblingsantipattern ist das Verlangen, dass jemand alles macht, oder nicht klar zu wissen, wen man braucht, und sich eine Menge Kandidaten anzusehen, um herauszufinden, was man braucht. Das lässt sich wahrscheinlich auf jeden Bereich übertragen, hat aber hier seine eigenen Besonderheiten.
Wie ich bemerkt habe, sind die Leute eher an Stellenanzeigen mit dem Wort DevOps interessiert als an Systemadministratoren, obwohl ich der Meinung bin, dass sich die Aufgabenebene im Wesentlichen in diesen beiden Bereichen auf Senior-Ebene stark unterscheidet.
Jeder Arbeitgeber, der tatsächlich einen Systemadministrator braucht, schreibt im Titel der Stellenanzeige DevOps und listet im Anfrageinhalt alles auf, K8S/Java/Gradle/OracleDB usw. in der Reihenfolge, während der Mensch intern mit der Unterstützung des K8S-Clusters und der Wartung des OracleDB-Stacks abseits des Teams beschäftigt sein wird.
Nun, wie sieht die Interaktion zwischen Entwicklern und Betriebsteams hier aus?
Es stellt sich heraus, dass es für einen solchen Interaktionsprozess mit dem Team nicht vorgesehen ist und es überhaupt keine Operations-Abteilung gibt, und Sie müssen auch die Computer der Entwickler konfigurieren.
Diese Option passt tatsächlich zu einem Teil der Bewerber, aber seien wir ehrlich, das ist ein Senior System Administrator, warum möchten sie das nicht so schreiben und was daran ist beschämend? Der Unterschied im Gehalt zwischen verschiedenen Berufsbezeichnungen? Aber das Budget des Unternehmens ist dasselbe, und egal wie man das Schiff nennt, es segelt mit demselben Budget.
Ich habe auch von so etwas gehört, heutzutage automatisiert ein Kandidat alles schnell und wird in die Produktentwicklung mit Python integriert, was spielt es für eine Rolle, überall ist Python dasselbe. Der Unterschied in Weltanschauungen und Ansätzen wird nicht berücksichtigt.

Ich differenziere normalerweise den Niveau der Fachkräfte, die kommen, und sehe jeweils meine eigenen Probleme.
Junior — für mich persönlich ist ein Junior DevOps jemand, der das Systemadministrations- / Entwicklungsniveau gut beherrscht. Hier fällt es mir leicht, starke Linux-Anwender zu differenzieren, die in einem neuen Bereich wachsen wollen, oder Entwickler, die das Bedürfnis haben, für andere Entwickler gut zu arbeiten. Starke, mit gewissen Debugging-Fähigkeiten, log-Suche, oder mit einer Sammlung von programmierten Projekten.
Ich habe sowohl Systemadministratoren getroffen, die etwas ausprobiert haben und in die Cloud eintauchen möchten, als auch solche, die Frontend und Backend ausprobiert haben und aus irgendwelchen Gründen Interesse an den DevOps-Prozessen gefunden haben.
Auf diesem Niveau macht es mich immer stutzig, wenn man mit einem riesigen Technologiestapel überfordert wird, Puppet, Ansible – warum hast du nicht alles ausprobiert? K8S, K3S – was ist der Unterschied? Wie viele Arten von Datenbanken kennst du? Warum so wenige? Wie funktioniert die Verschlüsselung in Java? Besonders bei denen, die aus der Entwicklung gekommen sind, obwohl das sehr nützliche Fachkräfte sind, gibt es für sie immer Arbeit in diesem Bereich.
Es macht mich immer sprachlos, wenn so etwas passiert, das erste, was ich fragen möchte — warum??? Das zweite, was mir in den Sinn kommt — ist der Interviewer bereit, Fragen zu einem so vielfältigen Technologiestapel zu beantworten? Wollen sie wirklich einen Junior einstellen und ihm alles aufbürden?
So etwas passiert oft in verschiedenen Bodyshops, wenn jemand für ein Projekt verkauft werden muss und mehr coole Worte für den Lebenslauf benötigt werden oder das Unternehmen einfach niemanden einstellen möchte und nur sieht, welche Juniors es gibt.

Middle Niveau
Hier gibt es meiner Meinung nach einige Extreme. Erstens ist es wahrscheinlich schwierig, genau zu bestimmen, ob jemand auf Midlevel-Level zieht; entweder wird er auf Junior-Niveau gedrückt, oder man lässt ihn als Senior arbeiten, versucht, einen Senior-Preis für einen Midlevel zu bekommen (ja, der Markt entscheidet, nichts Persönliches).
Das Erstaunlichste, was ich gesehen habe, ist, tief in das Programmieren einzutauchen, mit Python zu arbeiten, Java GC zu quälen, also sich mit spezifischeren Themen zu befassen, oder umgekehrt, alte Wissenslücken zu schließen, Netzwerke und Betriebssystemtreiber zu erkunden, während ich schmunzle und mich freue, wie jemand das vergessen konnte. Und hier passiert das Interessanteste!
Meiner Meinung nach entwickelt ein Spezialist auf Midlevel-Niveau einen Interessenbereich und eine persönliche Perspektive darauf, woran er arbeiten möchte – auf dem neuesten Stack zu glänzen, indem er Tricks in den Code einfügt, oder sich für ein herausforderndes Unternehmen weiterzuentwickeln, indem er in die Tiefen der Code-Performance eintaucht.
Ich denke, es ist bereits an der Zeit, nach den Prozessen zu fragen, an denen die Person gearbeitet hat, zu erkundigen, was am interessantesten war und was nicht, und auf Grundlage dieser Kenntnisse einen Fragencluster zu erstellen, wobei die Fragen unbedingt auf den eigenen Stack abgebildet werden. Andernfalls könnte eine spannende einstündige Unterhaltung über die Konfiguration eines OpenShift-Clusters dazu führen, dass man jemanden einstellt und ihn dann mit dem Aufbau von Monitoring beauftragt. Wahrscheinlich wird dies beiden Seiten gefallen.

Senior-Niveau
Oh, mein Lieblingsthema.
Vor Ihnen steht ein solider Spezialist, der sich in verschiedenen Projekten entwickelt hat, jemand, der bereits weiß, was er will und was ihm nicht so gefällt.
Und nun beginnt die Show:
– tiefgehende Fragen zur Systemadministration (siehe erstes Anti-Muster)
– tiefgehende Fragen zu Linux im Allgemeinen aus dem Bereich Theorie, die weit entfernt von praktischen Kenntnissen sind (die OSI-Ebenen, die beste Frage)
– akademische Fragen zum Programmieren (weil der Interviewer selbst die Materie nicht gut kennt; er wurde einfach gebeten, einen seltsamen DevOps zu interviewen)
Ich möchte hier eine kleine Anmerkung machen. Einmal wurde ich während eines Interviews gebeten, ein Stück Code zu schreiben. Auf einem Blatt Papier. So wie es alle mögen, jeden Tag schreiben, Papier ist unser Alles.
Nachdem ich die Aufgabe gelöst hatte, wurde nach dem Blick auf mein Blatt und die Lösung das Urteil gefällt, dass der Algorithmus suboptimal sein würde. Ich schlug vor, dass der Interviewer seinen eigenen Algorithmus schreiben solle, darauf erhielt ich die Antwort: "Das fällt nicht in den Rahmen des Interviews". Ich bat um eine Minute, änderte den Code ein wenig und zeigte ihn, fragte, ob es so schneller oder langsamer sei? Darauf kam die Antwort, dass wir zur nächsten Frage übergehen würden. Der Unterschied war in der Arbeitsweise des Codes mit und ohne Schleife, und ich hatte eine Antwort vorbereitet, warum es besser sei, so statt so zu machen. Nun, danach hatte ich keine Lust mehr, Fragen zu beantworten und mit dieser Person zu arbeiten.
Es ist zu beachten, dass wir alle unterschiedlich sind und jede Kleinigkeit, die für Sie unbedeutend ist, einen Kandidaten abschrecken kann.
— normalerweise haben Spezialisten auf Senior-Ebene einen klaren Technologie-Stack, aber nein, man muss noch einmal umherirren, zum Beispiel, Sie haben Ansible geschrieben, ausgezeichnet, und wir haben Puppet, wir haben Sie einfach so eingeladen, also erzählen Sie uns von Puppet. Hervorragend! Haben Sie mit OpenShift gearbeitet? Wir haben K8s, wir wissen nicht, wo die Unterschiede liegen, aber Ihre Erfahrung ist irrelevant. Wunderbar!

Es gibt noch so eine Unterklasse — ich persönlich nehme Praktikanten auf, um sie zu Junioren auszubilden.
Ich wünsche mir, dass alle verstehen, dass ein Praktikant eine noch nicht vollständig entwickelte Entität ist. Es macht mich schrecklich nervös, wenn Praktikanten auf die Stufe eines soliden Juniors gedrängt werden und dann mit zufriedenen Gesichtern ein Praktikum (manchmal unbezahlt, schrecklich!) vorgeschlagen wird.
Mach das nicht.
Ein Praktikant ist meiner Meinung nach entweder ein Student im fortgeschrittenen Semester oder jemand, der unbedingt "in die IT gehen" möchte.
Mit Studenten ist es einfach — hervorragend herauszufinden, was sie an der Universität machen, was sie selbst gemacht haben, zu beobachten, bei welchen Fragen ihre Augen aufleuchten — wenn sie aufleuchten, zu fragen, warum gerade DevOps und was sie darüber wissen. Den Menschen spüren und verstehen, ob es angenehm sein wird, mit ihm weiterzuarbeiten und ob man diesen Menschen etwas lehren möchte.
Bei denen, die "in die IT gehen" möchten, ist es etwas strenger — zu beobachten, wie sehr sich die Person selbstständig weiterbildet, was sie gemacht hat, bevor sie zu Ihnen ins Interview kam; eine gute Möglichkeit wäre es, GitHub zu betrachten, sofern vorhanden, die Dichte der Commits und welche Übungen gemacht wurden. Auch fragen, warum letztendlich DevOps, schließlich ist es im Frontend lustiger und abwechslungsreicher?

Und zum Schluss möchte ich erneut einen Rat geben: Bestimmen Sie, wer Ihnen wirklich wichtig ist, und Sie werden sofort die richtige Person finden. Ermitteln Sie die Bedürfnisse, betrachten Sie den Spezialisten als Fachmann, finden Sie seine Stärken und nutzen Sie diese erfolgreich in Ihrer Arbeit. Seien Sie aufmerksam gegenüber dem Bewerber; er ist zu einem Gespräch gekommen, nicht zu einem Wettkampf, wer den anderen übertrumpft.

Quelle: habr.com