Tere kõigile, mu kallid lugejad!
Täna tahan jagada oma mõtteid ammustest teemadest ja võib-olla arutada neid kommentaarides.
Sageli satun artiklite peale kehvade praktikate kohta intervjuudel, mis minu arvates on piisavalt elulised ja loodetavasti loetavad ka ettevõtete HR osakondade jaoks, olgu need suured või väikesed.
Meie kandis on nõudlus huvitavate erialade, nagu DevOps insener, üsna suur. Ma kuulun nende inimeste hulka, kes ei pruugi seda väljendit eriti tõsiselt võtta (jah, jah, DevOps metodoloogia jne), seega näen eri teed arengus nende spetsialistide seas.
Esiteks usun kindlalt, et igal inimesel on oma huvide ring, isegi töös, st kellelegi meeldib tegeleda pilvetehnoloogiatega, kellelegi süveneda rakendusserveritesse, sügavalt Java konfigureerida, kellegile aga kodeerida Pythonis või halvemal juhul YAML-koodi kirjutada. Nii et siia tekivad nn infrastruktuuri insenerid, ehituse insenerid, vanem YAML arendaja 🙂
See võimaldab ühelt poolt leida inimesi, kes sobivad teie ülesannete hulka, ja teiselt poolt tekitab arusaamatusi vestlustes.
Põhinedes isiklikul kogemusel, olen teinud mitmeid kümneidvestlusi ning osalenud erinevates rollides vastajana, ja soovin jagada oma vaadet kogu toimuvale.
Esimene ja võib-olla minu lemmik antipattern on soov leida keegi, kes teeks kõike, või et mitte teada, kes tegelikult on vajalik, vaatame palju kandidaate ja siis mõistame. See kehtib tõenäoliselt igas valdkonnas, kuid siin on omad eripärad.
Kuidas olen tähele pannud, on inimesed rohkem huvitatud töökohtadest, kus on sõna DevOps, kui süsteemiadministraator, kuigi minu arvates eristatavad ülesanded nendes kahes valdkonnas on vanuse järgi oluliselt erinevad.
Iga tööandja, kellele tegelikult on vajalik süsteemiadministraator, kirjutab töökuulutuse pealkirjas DevOps, loetledes taotluse sisus absoluutselt kõik, K8S/Java/gradle/oracleDB jms, kuigi seestpoolt tuleb inimesel tegeleda K8S klastrite ja OracleDB toe hooldamisega eraldiseisvalt meeskonnast.
Noh, kuidas on sellise koostöö vormiga arendajate/operatsioonide vahel?
Selgub see, et sellise meeskonnaga suhtlemise protsess ei ole ette nähtud ja tegelikult ei eksisteeri ka operatsioonide osakonda, seega on teil ette võtta arendajate arvutite seadistamine.
See variant sobib tõesti osale kandidaatidele, aga olgem ausad, see on ju Senior System Administrator, miks siis ei kirjutata nii ja mis selles häbiväärset on? Erinevused palkades erinevate ametinimetuste vahel? Kuid ettevõtte eelarve on sama, ja kuidas laeva ka ei nimetaks, ujub see ikka oma eelarve piires.
Kuule, olen isegi kuulnud, et praegu automatiseerivad kandidaadid kõik kiiresti ära ja saavad Pythonis toote arendusesse sisse, mis vahet seal on, Python on igal pool sama. Maailmavaade ja lähenemisviisid ei ole arvesse võetud.
Tavaliselt eristan ma spetsialistide taset, kes tulevad, ning näen igasuguseid raskusi igale eraldi.
Junior — minule on Junior DevOps inimene, kes on saavutanud kesktaseme süsteemiadministreerimises / arendamises. Siin on meeldiv eristada tugevaid Linuxi entusiaste, kes soovivad kasvada uuel alal, või arendajaid, kellel on soov teha head teistele arendajatele. Tugevaid, kellel on mingid häälestamisoskused, logide otsimine või koodiga seotud projektidest mingi varu.
Olen kohanud nii süsteemiadministreerijaid, kes on proovinud mingit uut ja soovivad kogeda pilvetehnoloogiaid, kui ka neid, kes on proovinud frontend'i, backend'i ja mingitel põhjustel avastanud huvi DevOpsi protsesside vastu.
Sellel tasemel häirib mind alati, kui hakkavad rääkima tohutust tehnoloogiate kuhjast, nagu Puppet, Ansible — miks ei ole kõike proovitud? K8S, K3S — millega nad erinevad? Kui palju andmebaaside tüüpe sa tead? Miks nii vähe? Kuidas Java-s krüpteerimine töötab? Eriti neid, kes on tulnud arendusest, kuigi nad on väga kasulikud töötajad, neile on alati tööd selles valdkonnas.
Mind always gets perplexed when such things happen; the first question that comes to mind is — why??? The second thought that arises is — is the interviewer even ready to answer questions about such a diverse stack? Do they really want to hire a junior and throw everything on them?
Such situations often occur in various body shops when it's necessary to sell someone for a project, and more impressive words are needed for the resume, or the company simply doesn't want to hire anyone and just observes what juniors are available.
Middle level
There are a few extremes in my opinion; firstly, it’s probably difficult to clearly determine that a person is fit for middle level, either they are being pushed down to junior level or treated like seniors, trying to get a senior for the price of a middle (you know, the market decides, it's nothing personal).
The most astonishing thing I've seen — getting deep into coding, using Python, struggling with Java GC, diving into more specific topics, or alternatively, uncovering gaps in long-unused knowledge, running through networks, OS driver types, smirking and gleefully thinking about how a person could forget this. And then, the most interesting thing happens!
Minu arvates kujuneb keskastme spetsialistil välja huvikreis ja isiklik vaatenurk selle osas, millega ta soovib tegeleda — kas tõusta esile kõige uuemal tehnoloogial või keskenduda keerulistele ettevõtte projektidele, süvenedes koodi jõudlusse.
Mina arvaks, et siin tasub juba uurida protsesse, millega inimene on töötanud, küsida, mis oli kõige huvitavam ja mis mitte, ning selle põhjal koostada küsimuste klaster, kindlasti seostades küsimusi oma tehnoloogiaga. Vastasel juhul, veetes põneva tunni kaks OpenShifti klastrite konfigureerimise üle, palkate inimese, et ta tegeleks monitooringuga. See meeldib tõenäoliselt mõlemale poolele.
Seniori tase
Ah, minu lemmiktase.
Teie ees on tugev spetsialist, kes on end üles kasvatanud erinevatel projektidel, inimene, kes juba teab, mida ta tahab, ja mis ei meeldi nii väga.
Ja nii algab show:
— sügavad küsimused süsteemiadministreerimise kohta (vt esimene antipattern)
— sügavad küsimused Linuxi kohta üldiselt teooria valdkonnast, mis on kaugel praktilisest teadmisest (OSI tasemed, peamine küsimus)
— akadeemilised küsimused koodi kohta (sest intervjuu läbiviija ei tea valdkonnast eriti midagi, teda paluti lihtsalt intervjuud läbi viia veidi kummalise devopsiga)
Teen siia väikese märkuse. Ühel korral paluti mul intervjuul kirjutada mingi koodilõik. Paberile. Noh, nagu kõik armastavad, kirjutavad iga päev, paber on meie kõik.
Kuna ülesanne oli lahendatud, vaadates minu paberit ja lahendust, anti verditkt, et algoritm ei ole optimaalne. Ma pakkusin, et intervjueerija kirjutaks oma algoritmi, millele sain vastuseks «See ei kuulu intervjuu raamidesse». Palusin minut aega, tegin koodi natuke ümber ja näitasin, küsides, kas see on nüüd kiiremini või aeglasemalt? Vastuseks sain, et liigume järgmise küsimuse juurde. Erinevus oli koodi töötamises tsüklis ja tsüklita ning mul oli valmis vastus, miks on parem teha nii, mitte naa. Noh, pärast seda ei olnud mul enam soovi küsimustele vastata ja selle inimesega töötada.
Peab arvestama, et kõik me oleme erinevad ja kandidaati võib ära hirmutada mis tahes asi, mis teie jaoks ei ole oluline.
— tavaliselt on vanema taseme spetsialistide tööriistakomplekt selgelt määratletud, kuid tuleb alustada midagi lähedast, näiteks, kui teil on kirjas Ansible, siis meil on Puppet, ja me lihtsalt kutsusime teid siia, rääkige meile Puppetist. Suurepärane! Kas olete töötanud OpenShiftiga? Meil on K8s, me ei tunne erinevusi, kuid teie kogemus pole asjakohane. Väga hea!
On veel selline alamklass — mina isiklikult võtan endale praktikante, et kasvatada neist algajaid.
Tahaks, et kõik mõistaks, et praktikant on veel täielikult kujunemata olend. Mind hirmutab hirmsasti, kui praktikante hakkavad tõukama tasemele tugev Junior ja seejärel pakuvad rahuldava ilmega praktikakohta (mõnikord tasustamata, õudne!)
Ära tee nii.
Minu arvates on praktikant kas vanema kursuse üliõpilane või keegi, kes tõeliselt soovib "IT-sse minna".
Üliõpilastega on kõik lihtne — on suurepärane teada, millega nad ülikoolis tegelevad, mida nad ise on teinud, vaadata, milliste küsimustega nende silmad hakkavad särama — kui säravad, siis küsida, miks just devops ja mida nad sellest üldse teavad. Tunda inimest ja aru saada, kas temaga on mõnus edasi töötada ja kas tahaks just sellele inimesele midagi õpetada.
Nendega, kes soovivad IT-sse minna, on natuke rangemad nõuded — vaadake, kui hästi inimene iseennast harib, mida ta on teinud enne, kui teie juurde intervjuule tuli. Hea variant oleks vaadata tema GitHub'i, kui see olemas on, kommiti tihedus ja milliseid harjutusi ta on teinud. Küsige ka, miks DevOps, kui front-endis on lõbusam ja keerukam?
Lõpetuseks sooviksin anda veel ühe nõuande: otsustage, kes te tegelikult vajate, ja leiate kohe vajaliku inimese. Selgitage välja vajadused, vaadake spetsialisti kui spetsialisti, leidke tema tugevused ja kasutage neid oma töös edukalt. Olge kandidaadi suhtes tähelepanelik, ta tuli teiega vestlusele, mitte kellelgi on võistlus, kes kedagi alt veab või ei veada.
Allikas: habr.com
