Antipatterni DevOps intervjui

Pozdravljam vas sve, dragi čitatelji!

Danas želim podijeliti svoje misli o jednom dugo raspravljenom pitanju i možda ga raspraviti u komentarima.
Često nailazim na članke o lošim praksama razgovora za posao programera, koji su, po mom mišljenju, prilično relevantni i, nadam se, čitljivi za HR odjele velikih i manjih kompanija.

U našim krajevima, koliko mogu prosuditi, postoji potražnja za zanimljivim entitetima kao što su DevOps inženjeri. Pripadnik sam onih koji ne doživljavaju tu frazu najbolje (da, DevOps metodologija itd.), pa stoga vidim određene razlike u razvoju ove grupe stručnjaka.
Prije svega, duboko vjerujem da svaka osoba ima svoj krug interesa, čak i u radnoj sferi, to jest, nekome su po volji oblak, nekome duboko istraživanje Application servers-a, nekome podešavanje Java-e, a nekome, ne daj Bože, pisanje koda u Pythonu ili yaml kodu. Tako se javljaju takozvani Infrastructure engineer, Build engineer, Senior Yaml Developer 🙂
Sve to, s jedne strane, omogućuje pronalazak osobe koja najbolje odgovara vašem setu zadataka, a s druge strane stvara nesporazume tijekom razgovora.
Na temelju vlastitog iskustva, proveo sam određeni broj desetaka razgovora, a takođe sudjelovao u raznim, kao što je odgovarajući, želim podijeliti svoj pogled na sve što se događa.

Prvi i možda moj najdraži antipattern — želja da netko radi sve, ili nejasno tko je potreban, gledamo hrpu kandidata, tu ćemo shvatiti. Vjerojatno se to može primijeniti na bilo koju oblast, ali ovdje postoje neki posebni aspekti.
Primijetio sam da su ljudi više skloni oglasima sa riječima DevOps nego sa System Administrator, iako se, po mom mišljenju, na razini Senior razlike u zadacima između ta dva područja maksimalno razlikuju.
Svaki poslodavac kojemu je zapravo potreban sysadmin, u naslovu oglasa piše devops, nabrajajući u tijelu svih i svašta, K8S/Java/gradle/oracleDB itd. po popisu, iako će se unutra osobi morati baviti podrškom klastera K8S i održavanjem OracleDB stoga u odvojenosti od tima.
Dakle, kakva je ovdje interakcija između formata Developers/Operations?
Dalje se otkriva da nije predviđeno kako i na koji način uspostaviti takav proces suradnje s timom i uopće, nema odjela za operacije, a vi ćete trebati konfigurirati računala programerima.
Ova opcija zapravo odgovara dijelu kandidata, ali budimo iskreni, ovo je pozicija Senior System Administratora, pa zašto ne žele tako napisati i što je tu uopće sramotno? Razlika u plaći između različitih naziva profesija? Ali budžet je u firmi isti, kako god nazvali brod, plovi prema svom budžetu.
Čak sam čuo i to, sada kandidat sve brzo automatizira i priključuje se razvoju proizvoda na Pythona, koja je razlika, svuda je Python isti. Razlika u svjetonazoru i pristupima se ne uzima u obzir.

Obično razlikujem razinu stručnjaka koji dolaze i za svakog posebno vidim svoje probleme.
Junior — osobno za mene, Junior DevOps je osoba koja je na srednjem nivou ovladala sistemskom administracijom / razvojem. Ovdje je ugodno razlikovati iskusne Linuxovce koji žele rasti u novoj oblasti, ili programere koji imaju želju raditi dobro za druge programere. Iskusni su, s nekim vještinama debagiranja, pretraživanja logova ili s nekim brojem odrađenih projekata.
Sreo sam i sistemske administratore koji su probali nešto i žele se približiti oblaku, kao i one koji su isprobali front i back te iz raznih razloga pronašli interes u DevOps procesima.
Na ovoj razini uvijek me zbunjuje kada počnu nabrati veliki tehnološki spektar, Puppet, Ansible — zašto nisu probali sve? K8S, K3S — po čemu se razlikuju? Koliko vrsta baza podataka znaš? Zašto tako malo? Kako šifriranje u Javi radi? Osobito onih koji su došli iz razvoja, iako su to jako korisni kadrovi, za njih uvijek ima posla u ovom području.
Uvijek me zbunjuje kada se to dogodi, prvo što želim pitati — zašto??? drugo, što mi pada na pamet — je li sam intervjuator spreman odgovoriti na pitanja o tako raznolikom spektru? Zar doista žele uzeti juniora i natovariti mu sve?
Često se to događa u različitim bodishopovima, kada treba prodati čovjeka na neki projekt i potrebno je više cool riječi za CV ili firma nikoga ne želi uzeti, već samo gleda kakvi su djuni.

Razina Middle
Mislim da postoje nekoliko ekstremnih stavova. Prvo, teško je precizno odrediti kada netko postaje mid-level, obično ga pokušavaju srušiti na junior razinu ili ga počinju tretirati kao seniora, pokušavajući ga iskeširati po cijeni mid-levela (da, tržište odlučuje, ništa osobno).
Najzanimljivije što sam vidio je da se ide duboko u kodiranje, igranje s Python-om, mučenje Java GC-om, baveći se već specifičnijim temama, ili obrnuto, otvaranje praznina u dugo neupotrebljavanom znanju, prolazeći kroz mreže, tipove drajvera operativnog sistema, smiješeći se i zloćudno razmišljajući kako je netko to mogao zaboraviti. I tada se događa ono najzanimljivije!
Prema mom mišljenju, mid-level stručnjak razvija krug interesa i osobni pogled na ono s čime želi raditi – ili želi biti u trendu s najnovijim tehnologijama, dodajući nešto novog u svoj projekt, ili se razvija za kompleksan enterprise, istražujući dubinu performansi koda.
Mislim da bi bilo dobro postaviti pitanja o procesima s kojima je osoba radila, pitati što je bilo najzanimljivije, a što ne, i na temelju tih saznanja izgraditi skup pitanja, ne zaboravljajući mapirati pitanja na svoj stack. Inače, nakon zanimljivog razgovora od jedan do dva sata o konfiguriranju OpenShift klastera, unajmiti osobu i staviti je da izgrađuje monitoring. Vjerojatno će to biti zanimljivo za obje strane.

Razina Senior
Oh, moja omiljena razina.
Pred vama je iskusni stručnjak koji se razvio kroz različite projekte, osoba koja već zna što želi, a što joj se ne sviđa.
I tada počinje predstava:
— duboka pitanja o sistemskom administriranju (vidi prvi antipaterni model)
— duboka pitanja o Linux-u uopće iz teorijske perspektive, daleko od praktičnih znanja (OSI modeli, vrhunsko pitanje)
— akademska pitanja o kodiranju (jer sam intervju koji se provodi ne zna dobro područje, jednostavno je zamoljen da razgovara s neobičnim devops-om)
Želim ovdje napraviti malu napomenu. Jednom prilikom, na razgovoru za posao, zamoljeno me je da napišem neki dio koda. Na papiru. Pa, kao što svi vole, svakodnevno pišu, papir je naš sve.
Nakon što smo riješili zadatak, nakon što sam pogledao svoj list i rješenje, donesena je presuda da algoritam neće biti optimalan. Predložio sam da intervjuator napiše svoj algoritam, na što sam dobio odgovor: "To nije u okviru intervjua". Zamolio sam za trenutak, malo prepravio kod i pokazao, pitajući je li tako brže ili sporije? Na što sam dobio odgovor, idemo na sljedeće pitanje. Razlika je bila u radu koda u petlji i bez petlje, a ja sam imao spreman odgovor zašto je bolje to učiniti na ovaj način, a ne na onaj. Nakon toga, više nisam imao želju odgovarati na pitanja i raditi s tom osobom.
Treba uzeti u obzir da smo svi različiti i da može odbiti kandidata bilo koja sitnica koja vam nije bitna.
— obično specijalisti razine Senior imaju jasno opisanu radnu stack, ali ne, moramo početi s nečim sličnim, na primjer, vi imate napisano Ansible, odlično, a kod nas je Puppet, jednostavno smo vas pozvali, pa nam recite nešto o Puppet-u. Sjajno! Jeste li radili s OpenShift-om? Kod nas je K8s, ne znamo razlike, ali vaše iskustvo nije relevantno. Divno!

Postoji još jedna podklasa — osobno uzimam praktikante na rast do juniora.
Želim da svi razumiju da praktikant još uvijek nije oblikovana entitet. Strašno me plaši kada praktikante počnu tjerati na razinu jakog Junior-a, a zatim, s zadovoljstvom, nude praksu (ponekad neplaćenu, strašno!).
Nemojte to raditi.
Praktikant, po mome mišljenju, je ili student viših godina, ili nekome stvarno želi "ući u IT".
Sa studentima je sve jednostavno — odlično je znati čime se bave na fakultetu, što su sami radili, gledati na kojim pitanjima se zapale oči — ako se zapale, pitati zašto baš devops i što uopće znaju o tome. Osjetiti osobu i shvatiti hoće li biti ugodno raditi s njom, žele li poučiti baš tu osobu nečemu.
S onima koji žele "ući u IT", nešto je strože — vidjeti koliko se osoba samoobučava, što je učinila prije nego što je došla na intervju, ovdje je dobra opcija pogledati GitHub, ako ga imaju, gustoću commit-a i koje su zadatke radili. Također pitati zašto ipak devops, jer je u frontendu veselije i zanimljivije?

Na kraju, želim ponoviti savjet: jasno definirajte tko vam je zapravo potreban i odmah ćete pronaći pravog stručnjaka. Istražite potrebe, pogledajte na stručnjaka kao na profesionalca, identificirajte njegove jake strane i uspješno ih iskoristite u svom radu. Budite pažljivi prema kandidatu, on je došao na razgovor, a ne na natjecanje tko će koga smestiti.

Izvor: habr.com