Pozdravljam vas vse, dragi bralci!
Danes želim deliti svoje misli o dolgoletni, pereči temi in morda razpravljati o njej v komentarjih.
Zelo pogosto naletim na članke o slabih praksah intervjujev za delovno mesto programista, ki se mi zdijo precej življenjski in upam, da so berljivi za kadrovske službe velikih in manjših podjetij.
V naših krajih, kolikor lahko sodim, obstaja povpraševanje po tako zanimivih entitetah, kot je DevOps inženir. Spadam med tiste, ki tega izraza ne dojema najbolje (da, da, DevOps metodologija itn.), zato vidim določene razlike v razvojnih poteh te skupine strokovnjakov.
Na prvem mestu svetovno verjamem, da ima vsak posameznik svoj krog interesov, celo na delovnem področju, torej nekdo si želi oblakov, nekdo se rad poglobi v Application servers, globoko nastavlja Javo, nekdo drug piše kodo v Pythonu ali, ne daj bože, YAML kodo. Tako se pojavljajo tako imenovani Infrastructure inženirji, Build inženirji, Senior YAML razvijalci 🙂
Vse to omogoča, da na eni strani najdete nekoga, ki je najbolje primeren za vaš nabor nalog, na drugi strani pa povzroča nesporazume na razgovorih.
Na podlagi osebnih izkušenj, zavil sem določeno število intervjujev in sodeloval v različnih vlogah na teh intervjujih, želim deliti svoj pogled na celoten dogodek.
Prvi in verjetno moj najljubši antipattern — želja, da nekdo dela vse, ali nejasno, kdo dejansko potrebujemo, bomo pogledali na kup kandidatov in bomo videli. Verjetno to velja za katerokoli področje, vendar ima to svoje posebnosti.
Kot sem opazil, se ljudje bolj zanimajo za delovna mesta s besedami DevOps kot System Administrator, čeprav se mi zdi, da se na ravni Senior področje nalog v teh dveh področjih maksimalno razlikuje.
Vsak delodajalec, ki dejansko potrebuje sistemskega administratorja, v naslovu delovnega mesta napiše devopsa in v besedilu razpisa našteje vse mogoče, K8S/Java/gradle/oracleDB itd., čeprav bo oseba dejansko skrbela za podporo K8S klasterju in podporo OracleDB staku ločeno od ekipe.
No, kakšno je tu sodelovanje med razvijalci in operacijami?
Zatim se ispostavlja da nije predviđen način interakcije s timom, a uopšte, odeljenje Operations ne postoji i treba da se bavite podešavanjem računara programera.
Ova opcija zapravo odgovara delu kandidata, ali budimo iskreni, ovo je Senior System Administrator, zašto onda ne žele da to pišu i šta je u tome sramotno? Razlika u plati između različitih naziva profesije? Ali budžet kompanije je isti, a kako god nazvali brod, ploviće po svom budžetu.
Čuo sam i za to, danas kandidati sve brzo automatizuju i posvećuju se razvoju proizvoda na Pythonu, koja razlika, svuda je isti Python. Razlika u svetosavlju i pristupima se ne uzima u obzir.
Obično diferenciram nivo stručnjaka koji dolaze i za svakog pojedinačno vidim svoje neprijatnosti.
Junior — za mene je Junior DevOps osoba koja je na srednjem nivou ovladala administracijom / razvojem. Lakše je diferencirati snažne Linux administratore koji žele rasti u novom polju ili developere koji žele da rade dobro za druge programere. Snažni, sa nekim veštinama debagovanja, traganja za logovima, ili sa nekim iskustvom u programiranim projektima.
Sreo sam i administratore koji su probali nešto i žele da se dotaknu oblaka, kao i one koji su probali frontend, backend i iz nekih razloga pronašli interes u DevOps procesima.
Na ovom nivou me uvek zbunjuje kada se nabraja ogroman stek tehnologija, Puppet, Ansible — zašto nisi probao sve? K8S, K3S — koja je razlika? Koliko vrsta baza podataka znaš? Zašto tako malo? Kako funkcioniše enkripcija u Javi? Posebno onih koji dolaze iz razvoja, iako su to veoma korisni kadrovi, za njih uvek ima posla u ovom polju.
Uvek me zaprepasti kada se to dešava, prvo što želim da pitam — zašto??? Drugo, što mi pada na pamet — da li je sam intervjuirajući spreman da odgovori na pitanja o tako raznovrsnom steku? Zar zaista žele da zaposle juniora i opterete ga svim tim?
Često se to viđa u raznim body shop-ovima, kada treba prodati osobu za neki projekat i potrebne su veće kul reči za CV ili kompanija jednostavno ne želi nikoga da zaposli, već gleda koje sve juniore mogu da nađu.
Nivo Middle
Tuk je nekaj skrajnosti, po mojem mnenju. Prvič, težko je natančno določiti, kdaj nekdo dobi srednji nivo. Vsakega izmed njih poskušajo spraviti nazaj na začetnika ali pa ga obravnavajo kot starejšega specialista, skušajoč nedolgo prejeti višjo plačo za srednji nivo (ja, trg odloča, nič osebnega).
Najbolj presenetljivo, kar sem videl, je, da greš globoko v kodiranje, delaš s Python-om, mučiš Java GC — torej bolj specifične teme ali pa obratno, odkrivaš vrzeli v znanju, ki ga že dolgo ne uporabljaš, delaš po omrežju, tipih gonil za OS, smejem se in se posmehuje, kako je to lahko pozabil. In tu pride najbolj zanimivo!
Na srednji ravni, po mojem mnenju, se oblikuje krog interesov in oseben pogled strokovnjaka na to, s čim želi delati — biti v trendu z najnovejšo tehnologijo, ali pa se usmeriti v globokomorsko optimizacijo delovanja kode.
Po mojem mnenju je smiselno vprašati o procesih, s katerimi je oseba delala, vprašati, kaj je bilo najbolj zanimivo in kaj ne. Na podlagi teh znanj je treba oblikovati skupino vprašanj, obvezno povezujoč vprašanja s svojim skladom znanja. Drugače, ko preživiš uro ali dve zanimive razprave o konfiguraciji OpenShift klasterja, zaposliš nekoga in ga postaviš za ustvarjanje monitoringa, kar bo verjetno ugajalo obema stranema.
Raven Senior
Oh, moja najljubša raven.
Pred vami je močan strokovnjak, ki je zrasel na različnih projektih, oseba, ki že ve, kaj želi, in kaj ji ni tako zelo všeč.
In tako se začne predstava:
— globoka vprašanja o sistemskem upravljanju (glej prvi antipater)
— globoka vprašanja o Linuxu na splošno iz teorije, daleč od praktičnega znanja ( najpomembnejše vprašanje, OSI ravni)
— akademska vprašanja o kodiranju (ker sam intervjuvalec pravzaprav ne pozna področja, preprosto so ga prosili, da intervjuve nekega nenavadnega devopsa)
Tu bi rad podal majhno pripombo. Nekega dne so me na razgovoru prosili, naj napišem košček kode. Na list. Kot to običajno počnejo, vsak dan pišejo, listič je naša vse.
Ko je nalogo uspešno opravil, je po ogledu moji listek in rešitvi bilo izdano mnenje, da bo algoritem podoptimiziran. Predlagal sem, naj intervjuist napiše svoj algoritem, na kar sem prejel odgovor: 'To ni v okviru intervjuja.' Prosil sem za minuto, malo sem spremenil kodo in pokazal, vprašal, ali bo tako hitrejše ali počasnejše? Na kar sem prejel odgovor, preidimo na naslednje vprašanje. Razlika je bila v delovanju kode v ciklu in brez cikla in pripravil sem odgovor, zakaj je bolje narediti tako, namesto tako. No, po tem mi ni bilo več do odgovarjanja na vprašanja in dela s to osebo.
Treba je upoštevati, da smo vsi različni in lahko katerikoli detajl kandidata odvrne, kar vam ne pomeni veliko.
— običajno imajo specialisti nivoja Senior jasno opisan delovni sklop, vendar ne, treba je začeti spraševati po bližnjem, na primer, vi imate napisano Ansible, odlično, ampak mi imamo Puppet, poklicali smo vas samo zato, da nam poveste o Puppet. Odlično! Ste delali z OpenShift? Mi imamo K8s, razlik ne poznamo, ampak vaše izkušnje niso relevantne. Čudovito!
Obstaja tudi tak podrazred — osebno vzamem pripravnike za rast v juniore.
Želim si, da bi vsi razumeli, da je pripravnik entiteta, ki še ni povsem oblikovana. Zelo me straši, ko pripravnike začnejo obravnavati kot močne Juniore in potem s zadovoljstvom ponujajo pripravništvo (včasih neplačano, groza!).
Nie rób tak.
Po mojem mnenju je pripravnik ali študent višjih letnikov, ali pa nekdo, ki si zelo želi 'iti v IT'.
S študenti je preprosto — odlično je vprašati, s čim se ukvarjajo na univerzi, kaj so sami počeli, opaziti, ob katerih vprašanjih se jim zasvetijo oči — če se zasvetijo, povprašati, zakaj prav v devopsu in kaj sploh vedo o tem. Občutiti človeka in razumeti, ali bo prijetno delati z njim naprej, ali se želiš prav tega človeka naučiti česa.
S tistimi, ki želijo 'iti v IT', je malo strožje — preveriti, koliko se posameznik samoizobražuje, kaj je naredil pred tem, ko je prišel na intervju, tukaj je dober način pogledati na GitHub, če seveda obstaja, gostota commitov in katera so bila opravljena opravila. Prav tako vprašati, zakaj ravno devops, saj je v frontend bolj zabavno in zanimivo?
Na koncu želite spet dati nasvet: odločite se, kdo je tisti, ki ga dejansko potrebujete, in takoj boste našli prava oseba. Določite potrebe, poglejte na strokovnjaka kot na strokovnjaka, poiščite njegove močne plati in jih uspešno uporabite v svojem delu. Bodite pozorni na kandidat, prišel je k vam na pogovor, ne na tekmovanje, kdo bo koga presenetil.
Izvor: habr.com
