Dobrý den všem, moji milí čtenáři!
Dnes bych chtěl sdílet své myšlenky na dlouho trápící téma a možná to probrat v komentářích.
Poměrně často se setkávám s články o špatných praktikách pohovorů na pozici programátora, které se mi zdají dost životné a doufám, že jsou čtivé pro HR oddělení velkých i menších společností.
V našich končinách, pokud se nemýlím, je poptávka po takových zajímavých pozicích, jako je DevOps inženýr. Patřím mezi ty lidi, kteří toto sousloví příliš nevnímají (ano, ano, DevOps metodologie, atd.), a proto vidím určité rozdíly ve vývojových cestách této skupiny specialistů.
Především svatě věřím, že každý člověk má svůj okruh zájmů, i v pracovní oblasti, to znamená, že někomu vyhovují cloudové technologie, někdo se rád ponoří do správy aplikačních serverů, nastavuje do hloubky Javu, a někdo jiný rád píše kód v Pythonu nebo, nedej Bože, v YAML. To znamená, že se zde objevují tak zvaní Infrastructure inženýři, Build inženýři, Senior YAML vývojáři 🙂
To vše umožňuje na jedné straně najít člověka, který co nejlépe odpovídá vašemu souboru úkolů, a na druhé straně vytváří nedorozumění během pohovorů.
Na základě osobních zkušeností jsem uskutečnil nějaký počet desítek pohovorů a také se zúčastnil různých situací jako odpovídající, chci se podělit o svůj pohled na vše, co se děje.
První a pravděpodobně můj nejoblíbenější antipattern — touha po někom, kdo všechno udělá, nebo nejasně, kdo je potřeba, podívejme se na spoustu kandidátů, tam to pochopíme. Pravděpodobně to platí pro jakoukoli oblast, ale zde jsou své zvláštnosti.
Jak jsem si všiml, lidé jsou více nakloněni nabídkám obsahujícím slova DevOps než System Administrator, ačkoliv se mi zdá, že na úrovni Senior se oblast úkolů maximálně liší v těchto dvou oborech.
Jakýkoli zaměstnavatel, který skutečně potřebuje sysadmina, píše do názvu nabídky devops, a v těle inzerátu uvádí úplně všechno, K8S/Java/gradle/oracleDB atd. v pořadí, ačkoliv se mu ve skutečnosti dostane na podporu clustera K8S a podpory OracleDB stacku od týmu.
Takže jaké je zde vůbec to propojení formátu Developers/Operations?
Dále se ukazuje, že pro takový proces interakce s týmem není nic předpokládáno, dokonce ani oddělení operations neexistuje, a vy se postaráte o nastavení počítačů vývojářů.
Taková varianta ve skutečnosti vyhovuje části uchazečů, ale buďme upřímní, to je Senior System Administrator, proč to tedy nechtějí takto napsat a co je na tom vlastně trapného? Rozdíl v platu mezi různými názvy profesí? Ale rozpočet společnosti je jeden, a jak si loď nazveš, tak na svůj rozpočet i pluje.
No a ještě jsem slyšel o tom, že nyní kandidát všechno rychle automatizuje a už se integruje do vývoje produktu na Pythonu, jaký je v tom rozdíl, všude je Python stejný. Rozdíl ve světovém názoru a přístupech se nezohledňuje.
Dále obvykle diferencuji úroveň specialistů, kteří přicházejí, a pro každého jednotlivě vidím svá nepříjemnosti.
Junior — osobně pro mě Junior DevOps je člověk, který na střední úrovni ovládl administraci / vývoj. Zde je příjemné diferenciovat silné linuxáky, kteří chtějí růst v nové oblasti, nebo vývojáře, kteří mají chuť udělat dobrou práci pro ostatní vývojáře. Silné, s nějakými dovednostmi v debugování, hledání logů, nebo s nějakým portfoliem napsaných projektů.
Potkal jsem jak administrátory, kteří něco zkusili a chtějí se dotknout cloudů, tak i ty, kteří zkusili frontend, backend a z nějakých důvodů našli zájem v procesech DevOps.
Na této úrovni mě vždy znepokojuje, když začnou bombardovat obrovským tech stackem, Puppet, Ansible — proč nezkoušel všechno? K8S, K3S — v čem se liší? Kolik typů databází znáš? proč jich je tak málo? jak funguje šifrování v Javě? Zejména těch, kteří přišli z vývoje, i když to jsou velmi užitečné kadry, pro ně je vždy práce v této oblasti.
Vždy mě zaskočí, když se stane něco takového, první, co chci zeptat — proč??? Druhé, co mi přichází na mysl — je samotný tazatel připraven odpovědět na otázky ohledně takového rozmanitého stacku? Nechtějí snad vzít juniora a pověsit na něj všechno?
Často se to setkává ve všech možných bodyshopech, když je třeba někoho prodat na nějaký projekt a je třeba více cool slov do životopisu, nebo společnost nikdo nechce vzít, a jen se dívá, jaké jsou možnosti juniorů.
Úroveň Middle
Tady je několik krajností, které považuji za relevantní. Za prvé, je pravděpodobně obtížné přesně určit, co člověk může dotáhnout na úroveň mid, buď se ho snaží shodit na juniorskou pozici, nebo s ním začnou zacházet jako se seniorem ve snaze zaplatit mu jako za mid (ano, trh rozhoduje, nic osobního).
Nejvíc fascinující, co jsem viděl — proniknout hluboko do kódování, trápit Python, přemýšlet o Java GC, tedy už se hodně specializovanými tématy, nebo naopak odkrytí mezer v dlouho nevyužívaných znalostech, probíhat sítí, typy operačních systémů a já se usmívám a škodolibě přemýšlím, jak to člověk mohl zapomenout. A tady přichází to nejzajímavější!
Podle mého názoru se k úrovni mid specialistovi formuje okruh zájmů a osobní pohled na to, s čím chce pracovat — buď se nadchnout pro nejnovější technologie, nebo se připravit pro velké podniky, ponořit se do výkonu kódu.
Myslím, že je už na místě se ptát na procesy, kterými člověk pracoval, zjistit, co ho nejvíce zajímalo a co ne, a na základě těchto znalostí budovat klastry otázek, vždy pečlivě mapovat otázky na svůj stack. Jinak, po fascinující hodinové diskusi o konfiguraci OpenShift clusteru, najmout člověka a posadit ho, aby stavěl monitoring. To by se asi oběma stranám líbilo.
Úroveň Senior
Ó, má oblíbená úroveň.
Před vámi je silný specialista, který se vypracoval na různých projektech, člověk, který už ví, co chce, a co ho zase tolik nezajímá.
A tady začíná show:
— hluboké otázky týkající se systémového administrátorství (viz první antipattern)
— hluboké otázky týkající se Linuxu obecně v oblasti teorie, daleko od praktických znalostí (nejvyšší otázka úrovní OSI)
— akademické otázky týkající se kódování (protože samotný tazatel vlastně nezná obor, jednoduše ho požádali, aby pohovořil s podivným dev opsem)
Udělám tady malou poznámku. Jednou mě na pohovoru požádali, abych napsal nějaký kousek kódu. Na papír. No, jak to všichni mají rádi, každý den píšíme, papír je všechno.
Po vyřešení úkolu, po zhlédnutí mého listu a odpovědi, byl vysloven verdikt, že algoritmus bude neoptimální. Navrhl jsem, aby si tazatel napsal vlastní algoritmus, na což jsem dostal odpověď: „To není v rámci pohovoru“. Požádal jsem o chvilku, trochu předělal kód a ukázal to, přičemž jsem se ptal, jestli to bude rychlejší nebo pomalejší? Odpověděl mi, že přejdeme na další otázku. Rozdíl byl v práci kódu v cyklu a bez cyklu a měl jsem připravenou odpověď, proč je lepší udělat to tak a ne jinak. Po tom už jsem neměl chuť odpovídat na otázky a pracovat s tímto člověkem.
Je třeba mít na paměti, že jsme všichni různí a kandidát může být odrazen jakoukoli věcí, která se vám může zdát nepodstatná.
— Obvykle mají specialisté úrovně Senior jasně definovaný pracovní stack, ale ne, musíme začít procházet blízké technologie, například máte napsáno Ansible, skvělé, a u nás Puppet, pozvali jsme vás jen tak, tak nám povězte něco o Puppetu. Výborně! Pracovali jste s OpenShift? U nás máme K8s, neznáme rozdíly, ale vaše zkušenosti nejsou relevantní. Skvělé!
Je tu ještě taková podkategorie — já si osobně beru stážisty na rozvoj v juniory.
Chtěl bych, aby všichni chápali, že stážista je entita, která ještě není plně formovaná. Hrozně mě děsí, když jsou stážisté tlačeni na úroveň silného Juniora a pak, s spokojeným výrazem, nabízejí stáž (někdy neplacenou, hrůza!).
Nedělejte to.
Stážista, podle mého názoru, je buď student vyšších ročníků, nebo někdo, kdo neuvěřitelně touží ‚odjet do IT‘.
Se studenty je to jednoduché — skvěle se zeptat, co dělají na univerzitě, co dělali sami, podívat se na otázky, které rozjasní jejich oči — pokud se rozjasní, zeptat se, proč právě DevOps a co o tom vlastně vědí. Cítit člověka a pochopit, jestli bude příjemné se s ním dál zabývat, jestli ho chcete něco naučit právě toho daného člověka.
S těmi, kdo chtějí ‚odejít do IT‘, je to trochu přísnější — podívat se, jak moc se člověk samoškolí, co udělal před tím, než k vám na pohovor přišel, tady je dobré se podívat na GitHub, pokud samozřejmě existuje, hustota commitů a jaké úkoly byly udělány. Také se zeptat, proč tedy DevOps, když ve frontendu je to zábavnější a zajímavější?
A nakonec bych chtěl znovu vyjádřit radu: určete, kdo skutečně potřebujete, a okamžitě najdete správného člověka. Zjistěte potřeby, dívejte se na odborníka jako na odborníka, najděte jeho silné stránky a úspěšně je využijte ve vaší práci. Buďte pozorní k uchazeči, přišel k vám na rozhovor, ne na soutěž, kdo koho shodí nebo ne shodí.
Zdroj: habr.com
