Tere kõigile, mu kallid lugejad!
Täna tahan jagada oma mõtteid ammu päevakorrale tõusnud teemal ja võib-olla arutada seda kommentaarides.
Sagedasti satun artiklitele halbadest intervjuupraktikatest programmeerijana, mis minu arvates on üsna elulised ja loodan, et HR osakonnad neid loevad, olenemata firma suurusest.
Meie kandis on nõudlus selliste huvitavate ametikohtade, nagu DevOps insener, olemas. Ma olen üks neist, kes ei suuda seda väljendit väga hästi tajuda (jah, DevOps metodoloogia jne), seetõttu näen mõningaid arenguteid, mis erinevad selle spetsialistide grupi seas.
Esiteks usun ma pühendunult, et igal inimesel on oma huvide ring isegi töövaldkonnas, st kellele meeldivad pilved, kellele süvitsi minek rakendusserveritesse, sügava Java seadistamine, ja kellelegi meeldib Pythonis koodi kirjutamine või hoia taevas yaml koodist eemal. Seega ilmuvad siia niiöelda Infrastructure insenerid, Build insenerid, Senior Yaml Developers 🙂
Kõik see võimaldab ühelt poolt leida inimese, kes sobib maksimaalselt teie ülesannete gruppi, ja teiselt poolt tekitab arusaamatust intervjuudes.
Oma isikliku kogemuse põhjal olen läbi viinud mitmeid kümneid intervjuusid ja osalenud erinevates rollides vastajana, tahan jagada oma vaadet toimuvast.
Esimene ja võib-olla mu lemmik antipattern on soov leida keegi, kes teeks kõike, või ebamugavustunne, et keegi pole selge, kes vajalik on; vaatame palju kandidaate ja seal siis mõistame. See kehtib tõenäoliselt igas valdkonnas, kuid siin on oma eripärad.
Olen märganud, et inimesed eelistavad töökuulutusi, kus on sõna DevOps, kui System Administrator, kuigi minu arvates on Senior tasemel ülesannete valdkond nende kahe ala vahel maksimaalselt erinev.
Iga tööandja, kellele on tõeliselt vajalik süsteemiadministraator, kirjutab töökuulutuse pealkirjas devops, loetledes ülesande sisus absoluutselt kõik, K8S/Java/gradle/oracleDB jne, kuigi tegelikult peab inimene tegelema K8S klastrite ja OracleDB toe pakkumisega meeskonnast eraldi.
Kuidas toimub siis siinkohal arendajate/operatsioonide koostöö?
Edasi selgub, et sellise meeskonnaga suhtlemise protsessi jaoks ei ole ette nähtud midagi, ning tegelikult ei ole ka operations osakonda, seega tuleb teil seadistada ka arendajate arvutid.
Selline variant sobib tõesti osale kandidaatidest, kuid olgem ausad, see on Senior System Administrator, nii et miks ei soovita nii kirjutada ja mis selles häbiväärset on? Erinevus palgas erinevate ametinimetuste vahel? Kuid ettevõtte eelarve on üks, ja kuidas laeva ikka ei nimeta, sõidab ta oma eelarve piires.
Kuulsin ka seda, et kandidaat automatiseerib kõik kiiresti ja liitub tootearendusega Pythonis, mis vahet seal on, kõikjal on Python sama. Maailmavaated ja lähenemisviisid ei ole arvesse võetud.
Edasi eristan ma tavaliselt spetsialistide taset, kes tulevad, ja näen igaühe jaoks eraldi oma ebamugavusi.
Junior — isiklikult on minu jaoks Junior DevOps inimene, kes on kesktasemel omandanud süsteemihaldust / arendust. Siin on meeldiv diferentseerida tugevaid Linuxi kasutajaid, kes soovivad kasvada uuel alal, või arendajaid, kellel on soov teha head teistele arendajatele. Tugevad, kel mõningaid vigade leidmise, logide otsimise oskusi, või kel on mingi hulk kooditud projekte.
Olen kohtunud nii süsteemihalduritega, kes on midagi proovinud ja soovivad pilvedega tutvuda, kui ka nendega, kes on proovinud fronti, backi ja mingitel põhjustel leidnud huvi DevOpsi protsessides.
Sellel tasemel häirib mind alati, kui hakata rääkima tohutu tehnoloogia teadmisest, Puppet, Ansible — miks pole kõike proovinud? K8S, K3S — mis vahe on? Kui palju andmebaasi tüüpe sa tead? miks nii vähe? kuidas krüpteerimine Java-s töötab? Eriti need, kes on tulnud arendamisest, kuigi need on väga kasulikud inimesed, neile on alati selles valdkonnas tööd.
Mind ajab alati segadusse, kui selline asi juhtub, esimene küsimus, mis tuleb küsida — miks??? Teine, mis mõtteisse tuleb — kas intervjöör on valmis vastama küsimustele sellise mitmekesise tehnoloogia kohta? Kas nad tõesti soovivad võtta juuniore ja panna neile kõik?
Sellist asja juhtub tihti erinevates bodishoppides, kui tuleb inimene müüa mõnele projektile ja ette on vaja rohkem lahedaid sõnu CV-sse või lihtsalt vaatavad ettevõtted, kes ei soovi kedagi võtta.
Tase Middle
Siin on minu arvates mitmeid äärmusi, esiteks on ilmselt keeruline täpselt kindlaks teha, mida inimene tõeliselt keskastme oskuste tasemele soovib, kas teda püütakse langetada algaja tasemele või hakatakse teda koormama nagu kogenud töötajat, üritades saada kogenud töötaja hinda keskastme tasemega (jah, turg otsustab, mitte midagi isiklikku).
Kõige üllatavam, mida olen näinud — sukelduda sügavale kodeerimisse, kasutada Pythonit, vaeva näha Java GC-ga, st minna juba sügavamatesse spetsiifiliste teemade juurde või vastupidi, avada tühimikke ammu unustatud teadmistest, tegeleda võrkude, opsüsteemide draiverite tüüpidega, naeratades ja rahulolevalt mõeldes, kuidas inimene sai selle unustada. Ja siin toimub kõige huvitavam!
Keskastme taseme juures, minu arvates, kujuneb spetsialistil huviring ja isiklik nägemus selle osas, millega soovitakse töötada — kas tuua välja uusim tehnoloogia, tuues sisse selliseid uusi lahendusi, või harjutada end hirmuäratavas ettevõttes, vastandudes koodi jõudluse sügavustesse.
Minu arvates tasuks juba sel teemal uurida, millistes protsessides inimene töötas, küsida, mis oli kuni maksimumini huvitav ja mis mitte ning nende teadmiste põhjal luua küsimuste klaster, sidudes küsimused oma tehnoloogiaga. Vastasel juhul, läbides ühinemise avameelse vestluse tunni või kahe jooksul OpenShift klastrite konfigureerimise kohta, palgata inimene ja lasta tal luua jälgimist. Tõenäoliselt meeldib see mõlemale poolele.
Vanem taseme
Oh, minu lemmiktase.
Teie ees on tugev spetsialist, kes on end kasvatanud erinevatel projektidel, inimene, kes juba teab, mida ta tahab, ja mis talle ei meeldi.
Ja nüüd algab show:
— sügavad küsimused süsteemi haldamise kohta (vt esimene antipattern)
— sügavad küsimused Linuxist üldiselt teooria valdkonnast, mis on kaugel praktilistest teadmistest (OSI tasemed, peamine küsimus)
— akadeemilised küsimused kodeerimise kohta (sest intervjueerijad ei tea tõeliselt valdkonda, teda lihtsalt paluti intervjuud teha kummalise DevOps'i kandidaatiga)
Teen siin väikese märkuse. Kord küsiti minult intervjuus kirjutada mingi koodijupp. Paberile. Noh, nagu kõik armastavad, iga päev kirjutavad, paber on meie kõik.
Kuna ülesanne oli lahendatud, vaatasin oma lehte ja lahendust, siis anti otsus, et algoritm ei ole optimeeritud. Soovitasingi, et intervjueerija kirjutaks oma algoritmi, mille peale sain vastuseks: "See ei kuulu vestluse raamesse". Palusin minut aega, tegin koodi natuke ümber ja näitasin, küsides, kas nüüd on kiiremini või aeglasemalt? Vastus oli, et liigume järgmise küsimuse juurde. Erinevus oli koodi töö käimises tsüklis ja ilma tsüklist, ja mul oli ette valmistatud vastus, miks on parem nii teha, mitte naa. Pärast seda ei olnud mul enam tahtmist sellele inimesele küsimustele vastata ja temaga töötada.
Peab arvestama, et me kõik oleme erinevad ja kandidaat võib ehmuda igast asjast, mis teie jaoks tundub ebaoluline.
— tavaliselt on senioritase spetsialistidel selgelt välja kirjutatud töösteek, kuid ei, alustame kontseptsioonist, näiteks teil on kirjutatud Ansible, suurepärane, aga meil on Puppet, kutsusime teid lihtsalt niisama, rääkige meile Puppetist. Suurepärane! Kas olete töötanud OpenShiftiga? Meil on K8s, me ei tea erinevust, kuid teie kogemus ei ole relevantne. Suurepärane!
On veel üks alamklass — mina isiklikult võtan endale praktikaajad arenevaid noori arendajaid.
Tahaks, et kõik mõistaksid, et praktikant on isik, kes pole veel üldse välja kujunenud. Mind äärmiselt hirmutab, kui praktikante hakata sundima tugevate Juniorite tasemele ja seejärel esitada rahuloleva näoga praktikat (mõnikord tasustamata, õudne!).
Ära nii tee.
Minu arvates on praktikant kas vanema kursuse üliõpilane või keegi, kes väga tahab "IT-sse minna".
Üliõpilastega on kõik lihtne — saab suurepäraselt välja uurida, millega ülikoolis tegeleb, mida on ise teinud, vaadata, millistel küsimustel süttivad silmad — kui süttivad, küsida, miks just DevOps ja mis üldse selle kohta tuntakse. Tunda inimest ja mõista, kas on meeldiv temaga edasi toimetada, kas tahaks just seda inimest millegi õppima õpetada.
Neil, kes tahavad "IT-sse minna", on asi veidi rangem — vaadata, kui palju inimene õppib iseseisvalt, mida on ta teinud enne, kui ta teieni kohtumiseks tuli, hea variant oleks vaadata GitHub'i, kui see eksisteerib, commitide tihedust ja milliseid harjutusi on sooritatud. Küsida ka, miks siiski DevOps, sest frontendis on lõbusam ja huvitavam?
Ja lõpuks tahaksin anda veel kord nõu: määrake ära, kes on teile tegelikult vajalik, ja te leiate kohe sobiva inimese. Selgitage vajadused, vaadake spetsialistile kui spetsialistile, leidke tema tugevad küljed ja kasutage neid edukalt oma töös. Olge tähelepanelik kandidaadi suhtes, ta tuli teie juurde vestlusele, mitte konkurentsi, et näha, kes keda alt vedab või mitte.
Allikas: habr.com
