Sveiki, mani dārgie lasītāji!
Šodien es vēlos dalīties ar savām domām par jau sen nopietni apspriesto tēmu un, iespējams, apspriest to komentāros.
Pietiekami bieži manī nonāk raksti par sliktām interviju praksēm programmētāja amatam, kas, manuprāt, ir diezgan dzīvespriecīgas un, cerams, lasāmam HR nodaļām gan lielu, gan mazu uzņēmumu.
Mūsu pusē, cik es varu spriest, ir pieprasījums pēc tādām interesantām struktūrām kā DevOps inženieris. Es piederu pie cilvēkiem, kuri šo vārdu salikumu neuztver ļoti nopietni (jā, jā, DevOps metodoloģija utt.), tādēļ es saskatu atšķirības attiecīgajā speciālistu grupā.
Vispirms es svēti ticu, ka katram cilvēkam ir sava intereses loka, pat darba jomā, tas ir, kādam patīk mākoņi, kādam ir dziļi jāpēta aplikāciju serveri, iestatīt Java, bet kādam rakstīt kodu Python vai, Dievs pasarg, YAML kodu. Tas nozīmē, ka šeit parādās tā sauktie infrastruktūras inženieri, būvniecības inženieri, vecākie YAML izstrādātāji 🙂
Tas viss no vienas puses ļauj atrast cilvēku, kurš visvairāk atbilst jūsu uzdevumiem, bet no otras puses rada pārpratumus intervijās.
Pamatojoties uz personisko pieredzi, esmu veicis kādu desmitu interviju un piedalījies dažādos kā atbildētājs, vēlos dalīties ar savu skatījumu uz notiekošo.
Pirmais un, iespējams, mans mīļākais antipatterns — vēlēšanās kādam darīt visu vai nezināt, kurš ir nepieciešams, apskatīsim lielu kandidātu skaitu un tad sapratīsim. Acīmredzot tas attiecas uz jebkuru jomu, bet šeit ir savas īpatnības.
Kā esmu pamanījis, cilvēki vairāk pievērš uzmanību vakancēm ar vārdiem DevOps nekā sistēmu administrators, lai gan manā skatījumā uz pieredzes līmeņa B, uzdevumu joma ļoti atšķiras šajās divās jomās.
Ikviens darba devējs, kuram patiešām nepieciešams sistēmu administrators, raksta vakances virsrakstā devops, uzskaitot pieteikuma ķermenī absolūti visu, sākot ar K8S/Java/gradle/oracleDB un tā tālāk, lai gan iekšienē cilvēkam jārūpējas par K8S klastera uzturēšanu un OracleDB steka uzturēšanu atrauti no komandas.
Nu, kāda ir šī izstrādātāju/operāciju formāta mijiedarbība?
Tālāk izrādās, ka nav paredzēts, kā šo procesu veikt kopā ar komandu, un vispār, operations kā nodaļas nav, un jums būs jāiestata izstrādātāju datori.
Šis variants patiesībā der daļai kandidātu, bet būsim godīgi, tas ir Senior System Administrator, kāpēc tad nevēlas to tā rakstīt un kas vispār ir apkaunojams? Atšķirība algā starp dažādām profesiju nosaukumiem? Bet uzņēmuma budžets ir viens, un, kā kuģis netiktu nosaukts, tas peldēs uz savu budžetu.
Es esmu dzirdējis par to, ka tagad kandidāts visu ātri automatizē un iekļaujas produktu izstrādē uz Python, kāda atšķirība, visur Python ir viens un tas pats. Atšķirība pasaules uzskatos un pieejās netiek ņemta vērā.
Tālāk es parasti diferencēju speciālistu līmeni, kas nāk, un katram redzu savas neērtības.
Junior — personīgi man Junior DevOps ir cilvēks, kurš vidējā līmenī apguvis sistēmas administratora / izstrādātāja prasmes. Šeit ir patīkami diferencēt stiprus linux lietotājus, kuri vēlas augt jaunā jomā, vai izstrādātājus, kuri vēlas darīt labu citiem izstrādātājiem. Stipri, ar kādām prasmēm debagēšanā, žurnālu meklēšanā, vai ar kādu iepriekš izstrādātu projektu pieredzi.
Es esmu sastapis gan sistēmas administratorus, kuri ir mēģinājuši kaut ko un vēlas piesaistīties mākoņiem, gan tos, kuri ir mēģinājuši frontendu, backendu un kādā iemeslā ir atraduši interesi DevOps procesos.
Šajā līmenī mani vienmēr izbrīna, kad sāk runāt par milzīgu tehnoloģiju steku, Puppet, Ansible — kāpēc neesi izmēģinājis visu? K8S, K3S — kāda atšķirība? Cik datu bāžu veidus tu zini? Kāpēc tik maz? Kā šifrēšana Java darbojas? It īpaši tiem, kas nākuši no izstrādes, lai gan viņi ir ļoti noderīgi speciālisti, šajā jomā viņiem vienmēr ir darbs.
Man vienmēr izraisa apjukumu, kad notiek šādas situācijas, pirmais, ko gribas jautāt — kāpēc??? otrais, kas ienāk prātā — vai pats intervētājs ir gatavs atbildēt uz jautājumiem par tik daudzveidīgu tehnoloģiju steku? Vai tiešām viņi vēlas pieņemt junioru un uzvelt uz viņa visu?
Diemžēl šādas situācijas bieži sastopamas dažādos bodišopos, kad jānodod cilvēks uz kādu projektu un jāizmanto vairāk foršu vārdu CV, vai uzņēmums nevēlas nevienu pieņemt, bet vienkārši skatās, kādi ir juniori.
Līmenis Middle
Manuprāt, šeit ir vairākas ekstrēmas situācijas. Pirmkārt, ir grūti precīzi noteikt, kad cilvēks ir uz mīdl līmeņa. Viņu vai nu cenšas pazemināt līdz junioram, vai arī sāk izturēties kā pret senioru, mēģinot to iekļaut seniora cenu (jā, tirgus izsniedz noteikumus, nekas personīgs).
Visvairāk pārsteidzošais, ko esmu redzējis — dziļi iekļūt kodā, strādāt ar Python, mocīt Java GC, t.i., pievērsties jau specifiskām tēmām, vai, tieši otrādi, atklāt trūkumus sen neizmantotās zināšanās, pārvietoties pa tīkliem, operētājsistēmu draiveru veidiem, sajūsminoties un ļaunprātīgi domājot, kā cilvēks to varēja aizmirst. Un tad notiek visinteresantākais!
Uz mīdl līmeni, manuprāt, speciālista interesēs un skatījumā veidojas loks par to, ar ko viņš vēlas strādāt — pamanīt kaut ko no jaunākajām tehnoloģijām, ierakstot to kubā, vai attīstīties dārgajam enterprīzam, dziļāk iegrimstot koda veiktspējā.
Manuprāt, šeit ir vērts izvaicāt par procesiem, pēc kuriem cilvēks strādājis, pajautāt, kas viņam bijis visinteresantākais, un kas nē, un uz šo zināšanu pamata veidot jautājumu klasteri, noteikti saistot jautājumus ar savu stēku. Citādi, veicot aizraujošu sarunu stundu divas par OpenShift klastera konfigurāciju, nolīgstot cilvēku un liekot viņam veidot monitoringu. Droši vien tas patiks abām pusēm.
Senior līmenis.
Ak, mans iecienītais līmenis.
Jūs redzat spēcīgu speciālistu, kurš izstrādājis sevi dažāda veida projektos, cilvēku, kurš jau zina, ko vēlas, un kas viņam nepatīk.
Un tad sākas šovs:
— dziļi jautājumi par sistēmu administrēšanu (skatiet pirmo antipattern).
— dziļi jautājumi par Linux kopumā, kas nāk no teorijas, kas ir tālu no praktiskajām zināšanām (OSI līmeņi — top jautājums).
— akadēmiski jautājumi par kodēšanu (jo pats intervētājs īsti nezina jomu, viņam vienkārši lūgts intervēt dīvaino devops).
Šeit veicu nelielu piezīmi. Kādu reizi, intervijā man lūdza uzrakstīt kādu koda fragmentu. Uz papīra. Nu, kā visi to mīl, katru dienu raksta, papīrs ir mūsu viss.
Pateicoties uzdevuma veikšanai, apskatot manu lapu un risinājumu, tika sniegts spriedums, ka algoritms būs neoptimizēts. Es ieteicu, lai intervētājs uzraksta savu algoritmu, uz ko saņēmu atbildi: «Tas neietilpst intervijas ietvaros». Es lūdzu minūti, nedaudz pārstrādāju kodu un parādīju, jautājot, vai tas tagad būs ātrāk vai lēnāk? Uz ko saņēmu atbildi, pāriesim pie nākamā jautājuma. Atšķirība bija kodēšanas darbībā ar ciklu un bez cikla, un man bija sagatavota atbilde, kāpēc labāk darīt tā, nevis šitā. Nu, pēc tam man vairs negribējās atbildēt uz jautājumiem un strādāt ar šo cilvēku.
Jāņem vērā, ka mēs visi esam atšķirīgi un kandidātu var atturēt jebkura lieta, kas jums šķiet nenozīmīga.
— parasti speciālistiem ar Senior līmeni skaidri ir aprakstīts darba steks, bet, nē, ir jāsāk uzdot jautājumus par līdzīgu, piemēram, jums ir rakstīts Ansible, lieliski, bet mums ir Puppet, mēs jūs vienkārši tāpēc aicinājām, nu, pastāstiet par Puppet. Lieliski! Vai esat strādājuši ar OpenShift? Mums ir K8s, mēs nesaprotam atšķirības, bet jūsu pieredze nav releventa. Lieliski!
Ir vēl tāds apakškategorija — es personīgi ņemu praktikantus, lai izaudzinātu viņus par junioriem.
Gribētos, lai visi saprastu, ka praktikants ir būtība, kas vēl nav pilnībā izveidojusies. Mani briesmīgi baida, kad praktikantus sāk sūtīt uz stipru Junior līmeni un pēc tam ar apmierinātu izskatu piedāvā praksi (dažreiz neapmaksātu, šausmas!).
Tā nedrīkst.
Praktikants, manuprāt, ir vai nu vecāko kursu students, vai nu kāds ļoti vēlas «aiziet uz IT».
Ar studentiem viss ir vienkārši — lieliski ir uzzināt, ko viņi māca universitātē, ko paši darījuši, paskatīties, uz kādiem jautājumiem iedegas acis — ja iedegas, pajautāt, kāpēc tieši DevOps un ko vispār par to zina. Sajust cilvēku un saprast, vai būs patīkami ar viņu turpināt darboties, vai gribēsiet iemācīt tieši šo cilvēku kaut ko.
Ar tiem, kas vēlas «aiziet uz IT», viss ir nedaudz stingrāk — jāpaskatās, cik cilvēks ir pašmācījies, ko ir izdarījis pirms nokļūšanas pie jums uz interviju, šeit labs variants būs apskatīt GitHub, ja tāds ir, komitu blīvums un kādi uzdevumi veikti. Jānoskaidro arī, kāpēc tieši DevOps, jo front-end šķiet jautrāk un izdomātāk.
Un, visbeidzot, vēlētos dot padomu - noskaidrojiet, kurš jums patiešām ir vajadzīgs, un jūs acumirklī atradīsiet nepieciešamo cilvēku. Noskaidrojiet vajadzības, aplūkojiet speciālistu kā speciālistu, atrodiet viņa stiprās puses un veiksmīgi izmantojiet tās savā darbā. Esi uzmanīgs pret sarunāto, viņš ir ieradies pie jums sarunā, nevis sacensībās, kurš kuru uzvarēs vai neuzvarēs.
Avots: habr.com
