Sveikinu jus visus, mano brangūs skaitytojai!
Šiandien noriu pasidalinti savo mintimis seniai užsitęsusia tema, o galbūt ją aptarti komentaruose.
Gana dažnai susiduriu su straipsniais apie blogą interviu praktiką programuotojo pareigoms užimti, kurie, mano nuomone, yra gana aktualūs ir, tikiuosi, yra skaitomi didelių ir ne tokių didelių įmonių personalo skyriuose.
Mūsų rajone, kiek suprantu, yra paklausa tokių įdomių subjektų kaip „DevOps“ inžinieriai. Esu iš tų žmonių, kurie šios frazės nelabai supranta (taip, DevOps metodika ir pan.), todėl matau šiokių tokių specialistų tobulėjimo kelių skirtumų.
Visų pirma, aš tvirtai tikiu, kad kiekvienas žmogus turi savo pomėgių diapazoną, net ir darbo srityje, tai yra, kai kuriems patinka debesys, kiti mėgsta gilintis į programų serverius, konfigūruoti gilią Java, o kiti rašyti kodą Python. arba neduok Dieve, yaml kodas. Tai yra, čia atsiranda vadinamasis infrastruktūros inžinierius, statybų inžinierius, vyresnysis „Yaml“ kūrėjas :)
Visa tai leidžia, viena vertus, rasti žmogų, kuris geriausiai atitinka jūsų užduočių grupę, kita vertus, sukelia nesusipratimų pokalbių metu.
Remdamasis asmenine patirtimi, esu atlikęs dešimtis interviu, taip pat dalyvavęs įvairiuose kaip kaltinamasis, noriu pasidalinti savo požiūriu į viską, kas vyksta.
Pirmas ir turbūt mano mėgstamiausias antimodelis yra noras, kad kažkas viską padarytų, arba neaišku kam reikia, pažiūrėsime į krūvą kandidatų ir suprasime. Tai tikriausiai taikoma bet kuriai sričiai, tačiau ji turi savo ypatybių.
Kaip pastebėjau, žmonės yra labiau godūs darbams su užrašu DevOps nei sistemos administratorius, nors, mano nuomone, Senior lygyje užduočių apimtys šiose dviejose srityse kuo labiau skiriasi.
Bet kuris darbdavys, kuriam iš tikrųjų reikia sistemos administratoriaus, laisvos darbo vietos pavadinime rašo devops, išvardijant absoliučiai viską, kas yra prašymo turinyje, sąraše K8S/Java/gradle/oracleDB ir pan., nors iš vidaus žmogus turės susidoroti su K8S klasterio palaikymu ir OracleDB dėklo palaikymu atskirai nuo komandos.
Na, tai yra, kokia sąveika yra tarp kūrėjų / operacijų formato?
Be to, paaiškėja, kad tokio bendravimo su komanda proceso nėra ir apskritai nėra padalinio veiklos, o jūs turite nustatyti kūrėjų kompiuterius.
Ši parinktis iš tikrųjų tinka kai kuriems kandidatams, bet būkime atviri, tai yra vyresnysis sistemos administratorius, tai kodėl jie nenori taip rašyti ir kas tame gėdinga? Atlyginimų skirtumai tarp skirtingų pareigybių pavadinimų? Tačiau įmonė turi vieną biudžetą ir kad ir kaip laivą pavadintumėte, jis plauks iš savo biudžeto.
Na, aš net girdėjau apie tai, dabar kandidatas greitai viską automatizuos ir prisijungs prie produkto kūrimo Python, koks skirtumas, Python visur tas pats. Neatsižvelgiama į pasaulėžiūros ir požiūrių skirtumus.
Toliau dažniausiai kiekvienam atskirai skiriu specialistų, kurie ateina ir mato savo bėdas, lygį
Junior - man asmeniškai Junior DevOps yra žmogus, kuris įvaldė sistemos administravimą / kūrimą vidutiniu lygiu. Čia malonu atskirti stiprius „Linux“ vartotojus, norinčius augti naujoje srityje, arba kūrėjus, kurie nori padaryti gera kitiems kūrėjams. Stiprus, turintis tam tikrų įgūdžių derinant, ieškant žurnalų arba turintis tam tikrą užkoduotų projektų atsargą.
Sutikau ir sistemų administratorių, kurie kažką bandė ir nori prisiliesti prie debesų, ir tuos, kurie bandė priekyje ir gale ir kažkodėl susidomėjo DevOps procesais.
Šiame lygyje mane visada glumina, kai pradeda mėtyti didžiulę šūsnį technologijų, „Puppet“, „Ansible“ – kodėl aš visko neišbandžiau? K8S, K3S – koks skirtumas? Kiek duomenų bazių tipų žinote? kodel tiek mazai? Kaip šifravimas veikia „Java“? Ypač tie, kurie atėjo iš plėtros, nors tai yra labai naudingi darbuotojai, jiems visada yra darbo šioje srityje.
Visada būnu apsvaigęs, kai tai atsitinka, pirmas dalykas, kurį noriu paklausti, yra kodėl??? antras dalykas, kuris ateina į galvą: ar pašnekovas yra pasirengęs atsakyti į klausimus apie tokią įvairovę? Ar jie tikrai nori paimti June ir viską susegti ant jo?
Dažnai taip nutinka visokiose kėbulų parduotuvėse, kai reikia parduoti žmogų kokiam projektui ir reikia daugiau šaunių žodžių savo gyvenimo aprašymui arba įmonė nenori nieko samdyti, o tik žiūri, kokie jaunieji. yra.
Vidurinis lygis
čia yra keli kraštutinumai, mano nuomone, pirma, turbūt sunku aiškiai tiksliai nustatyti, kas žmogų traukia būti viduriu, arba bando jį iššvaistyti iki birželio, arba pradeda varyti kaip senjorą, bando patraukti senjoras už vidurio kainą (taip, rinka taip nusprendžia, nieko asmeniško)
Nuostabiausias dalykas, kurį mačiau, yra gilinimasis į kodavimą, maišymasis su Python, „Java GC“ kankinimas, tai yra, su konkretesnėmis temomis, arba atvirkščiai, atskleidžiamas ilgą laiką nenaudotas žinių spragas. , važinėjimas per tinklus, OS tvarkyklių tipai, besišypsantis ir džiūgaujantis, Kaip žmogus gali tai pamiršti? Ir čia atsitinka įdomiausias dalykas!
Iki vidurinio lygio, mano nuomone, specialistas susiformuoja interesų ratą ir asmeninį požiūrį į tai, su kuo jis nori dirbti – kelti ažiotažą apie naujausią krūvą, įsmeigti triuką į kubą ar sūpuoti baisiai įmonei, gilinasi į kodo veikimą.
Mano nuomone, čia verta pasiteirauti apie procesus, prie kurių žmogus dirbo, paklausti, kas buvo įdomiausia, o kas ne, ir remiantis šiomis žiniomis, suformuoti klausimų klasterį, paprastai į savo krūvą įtraukiant klausimų. Priešingu atveju, valandą ar dvi pakalbėję apie „OpenShift“ klasterio konfigūravimą, pasamdykite asmenį ir paskirkite jam sukurti stebėjimą. Tikriausiai patiks abiem pusėms.
Vyresnysis lygis
O mano mėgstamiausias lygis.
Čia yra stiprus specialistas, išugdęs save įvairiuose projektuose, žmogus, kuris jau žino, ko nori, o kas jam taip nepatinka.
Taigi pasirodymas prasideda:
— gilūs klausimai apie sistemos administravimą (žr. pirmąjį antipatterną)
— gilūs klausimai apie Linux apskritai iš teorijos srities, toli nuo praktinių žinių (OSI lygio svarbiausias klausimas)
— akademiniai klausimai apie kodavimą (kadangi pats pašnekovas tos srities nelabai išmano, tiesiog buvo paprašyta pakalbinti keistą devopso vaikiną)
Čia padarysiu nedidelę pastabą. Vieną dieną interviu metu manęs paprašė parašyti kažkokį kodo fragmentą. Ant popieriaus lapo. Na, kaip visi mėgsta, rašo kasdien, lapelis mums yra viskas.
Atlikus užduotį, peržiūrėjus mano lapelį ir sprendimą, buvo priimtas verdiktas, kad algoritmas bus neoptimalus. Pasiūliau pašnekovui parašyti savo algoritmą, į kurį gavau atsakymą „Tai nepatenka į interviu“. Paprašiau minutėlę, šiek tiek pakeičiau kodą ir parodžiau, klausdamas, bus greičiau ar lėčiau? Į ką gavau atsakymą, pereikime prie kito klausimo. Skirtumas buvo tame, kaip kodas veikė kilpoje ir be kilpos, ir aš turėjau paruoštą atsakymą, kodėl geriau daryti taip, o ne kitaip. Na, o po to nebenorėjau atsakyti į klausimus ir dirbti su šiuo žmogumi.
Turime atsižvelgti į tai, kad visi esame skirtingi ir kandidatą gali atbaidyti bet koks tau nesvarbus dalykas.
— dažniausiai aukštesnio lygio specialistai turi aiškų darbo krūvos aprašymą, bet ne, reikia pradėti naudoti kažką artimo, pavyzdžiui, parašei Ansible, puiku, bet mes turime Puppet, ką tik tau paskambinome, tai pasakyk mus apie lėlę. Puikus! Ar dirbote su „OpenShift“? Turime K8, nežinome skirtumų, bet jūsų patirtis nesvarbu. Nuostabu!
Yra ir toks poklasis – aš asmeniškai priimu praktikantus, kad išaugtų į jaunesnes.
Norėčiau, kad visi suprastų, kad praktikantas yra dar visiškai nesusiformavęs darinys. Mane siaubingai gąsdina, kai jie pradeda stumti auklėtinius į stiprų jaunimo lygį, o paskui patenkintu žvilgsniu siūlo jiems stažuotę (kartais neapmokamą, košmarą!)
Nedaryk taip.
Stažuotojas, mano nuomone, yra vyresnio amžiaus studentas arba žmogus, kuris tikrai nori „įstoti į IT“.
Su studentais viskas paprasta - puiku sužinoti, ką jis veikia universitete, ką veikė pats, pamatyti, į kokius klausimus nušvinta akys - jei užsidega, paklauskite, kodėl devops ir kas apie tai apskritai žinoma. Pajuskite žmogų ir supraskite, ar bus malonu toliau su juo dirbti, ar norite kažko išmokyti būtent šį žmogų.
Su norinčiais „įeiti į IT“ viskas šiek tiek griežtesnė – pažiūrėkite, kiek žmogus pats mokosi, ką veikė prieš patekdamas į jūsų pokalbį, čia geras variantas būtų pasižiūrėti Github, jei yra, iš eiga, įsipareigojimų tankis ir kokie pratimai buvo atlikti. Taip pat paklauskite, kodėl tai devops, nes priekinėje dalyje jis yra linksmesnis ir sudėtingesnis?
Ir pabaigai noriu dar kartą duoti patarimą: apsispręskite, ko jums iš tikrųjų reikia, ir iš karto rasite tinkamą žmogų. Identifikuokite poreikius, žiūrėkite į specialistą kaip į specialistą, suraskite jo stipriąsias puses ir sėkmingai išnaudokite jas savo darbe. Būkite dėmesingi pašnekovui, jis atėjo pas jus pokalbiui, o ne varžytis, kas kam nepavyks, ar ne.
Šaltinis: www.habr.com
