Hei alle sammen, kjĂŠre lesere!
I dag Þnsker jeg Ä dele mine tanker om et tema som har vÊrt pÄ hjertet lenge, og kanskje diskutere det i kommentarfeltet.
Jeg kommer ofte over artikler om dÄrlige intervjuprosesser for programmerere, som jeg mener er ganske relevante og forhÄpentligvis lesbare for HR-avdelinger i bÄde store og smÄ selskaper.
I vÄre trakter, sÄ langt jeg kan bedÞmme, er det etterspÞrsel etter interessante roller som DevOps-ingeniÞrer. Jeg er en av dem som er skeptisk til denne terminologien (ja, ja, DevOps-metodologi osv.), sÄ jeg ser noen forskjeller i utviklingsveier for denne gruppen fagfolk.
FĂžrst og fremst tror jeg helhjertet at alle har sine egne interesser, selv i arbeidslivet; noen liker skyer, noen liker Ă„ grave dypt i applikasjonsservere, konfigurere Java grundig, mens andre foretrekker Ă„ skrive kode i Python eller, Gud forby, YAML-kode. Dette gir opphav til sĂ„kalte Infrastruktur-ingeniĂžrer, Bygge-ingeniĂžrer, Senior YAML-utviklere đ
Alt dette gjÞr det mulig Ä finne den mest passende personen for oppgavene deres, men skaper samtidig misforstÄelser under intervjuene.
Basert pÄ min personlige erfaring, som har medfÞrt et visst antall tiotalls intervjuer, samt deltakelse i ulike roller som respondent, Þnsker jeg Ä dele mitt syn pÄ alt som skjer.
Det fÞrste og kanskje mitt favoritt-antipattern er Þnsket om at noen skal gjÞre alt, eller at man ikke helt vet hvem man trenger; man ser pÄ mange kandidater og finner ut av det. Dette gjelder sannsynligvis enhver bransje, men det er spesielle aspekter her.
Som jeg har lagt merke til, er folk mer interessert i stillinger med ordet DevOps enn System Administrator, selv om jeg mener at arbeidsoppgavene pÄ Senior-nivÄ i disse to omrÄdene er maksimalt forskjellige.
Enhver arbeidsgiver som faktisk trenger en systemadministrator, kaller stillingen DevOps i overskriften og lister opp absolutt alt i annonsen, K8S/Java/Gradle/OracleDB osv., men innad vil personen mÄtte jobbe med Ä vedlikeholde et K8S-klynge og stÞtte OracleDB-stakken uavhengig av teamet.
SĂ„ hva slags samarbeid er det mellom utviklere og drift?
Det viser seg at det ikke finnes noen prosesser for samarbeid med teamet, og i det hele tatt er det ingen avdeling for operasjoner, sÄ det blir opp til deg Ä konfigurere utviklernes datamaskiner.
Denne varianten passer faktisk en del sÞkere, men la oss vÊre Êrlige, dette er en Senior System Administrator, sÄ hvorfor vil de ikke skrive det slik, og hva er egentlig pinlig med det? Forskjellen i lÞnn mellom de ulike yrkestitlene? Men budsjettet til selskapet er det samme, og uansett hva du kaller skipet, vil det seile pÄ sitt budsjett.
Jeg har til og med hÞrt om dette, nÄ automatiserer kandidaten alt raskt og blir involvert i produktutvikling med Python, hva er forskjellen, Python er det samme overalt. Forskjellen i verdenssyn og tilnÊrminger blir ikke tatt med i betraktningen.
Jeg pleier vanligvis Ä differensiere nivÄet pÄ spesialister som kommer inn, og for hver enkelt ser jeg mine egne utfordringer.
Junior â personlig for meg er Junior DevOps en person som har mestret systemadministrasjon / utvikling pĂ„ et middels nivĂ„. Her er det fint Ă„ differensiere mellom sterke Linux-venner som Ăžnsker Ă„ vokse i et nytt felt, eller utviklere som Ăžnsker Ă„ gjĂžre det bra for andre utviklere. Stabile personer med noen debug-evner, loggsĂžk, eller med en pĂ„fylling av prosjekter de har kodded.
Jeg har mÞtt bÄde systemadministratorer som har prÞvd noe og Þnsker Ä berÞre skyene, samt de som har prÞvd frontend, backend og av forskjellige grunner har funnet interesse i DevOps-prosesser.
PĂ„ dette nivĂ„et blir jeg alltid forvirret nĂ„r de begynner Ă„ hive inn enorme stakker med teknologi, Puppet, Ansible â hvorfor har de ikke prĂžvd alt? K8S, K3S â hva er forskjellen? Hvor mange typer databaser kan du? hvorfor sĂ„ fĂ„? hvordan fungerer kryptering i Java? Spesielt de som kommer fra utvikling, selv om det er svĂŠrt nyttige ressurser, det finnes alltid arbeid for dem i dette omrĂ„det.
Jeg blir alltid stĂ„ende helt stille nĂ„r noe sĂ„nt skjer, det fĂžrste jeg vil spĂžrre er â hvorfor??? det andre som kommer til tankene er â er intervjueren selv klar til Ă„ svare pĂ„ spĂžrsmĂ„l om en sĂ„ variert teknologi-stabel? Vil de virkelig ansette en junior og legge alt ansvar pĂ„ ham?
Dette skjer ofte i diverse bemanningsbyrÄer, nÄr de mÄ selge en person til et prosjekt og trenger flere kule ord for CV-en, eller sÄ vil selskapet ikke ta noen, men bare se hva slags juniorer det finnes.
NivÄ Middle
Her er det flere ytterpunkter, etter min mening. For det fÞrste er det nok vanskelig Ä klart definere hva som gjÞr at en person blir vurdert som mid-level. Enten prÞver de Ä presse ned til junior, eller begynner Ä behandle dem som seniorer, i et forsÞk pÄ Ä fÄ en seniorpris i mid-level (ja, markedet bestemmer, ingenting personlig).
Det mest overraskende jeg har sett, er at man gÄr dypt inn i koding, bruker Python, sliter med Java GC, det vil si mer spesifikke temaer, eller motsatt, avdekker hull i lenge glemte kunnskaper, jobber med nettverk, prosessorer av OS-drivere, og smiler ondskapsfullt ved Ä tenke pÄ hvordan vedkommende kunne glemme det. Og her skjer det mest interessante!
NĂ„r det kommer til mid-level, mener jeg at spesialisten utvikler et sett med interesser og en personlig mening om hva de Ăžnsker Ă„ jobbe med â Ă„ fĂžlge med pĂ„ den nyeste teknologien, eller Ă„ forbedre seg for det krevende enterprise-miljĂžet, ved Ă„ dykke ned i ytelsen til koden.
Etter min mening bÞr man allerede her spÞrre om prosessene personen har jobbet med, spÞrre hva som var mest interessant, og hva som ikke var det, og basere spÞrsmÄlene pÄ det. Ellers kan man ende opp med Ä ha en fascinerende samtale pÄ en og annen time om konfigurasjonen av et OpenShift-kluster, ansette personen, og fÄ dem til Ä lage overvÄkning. Dette ville sannsynligvis glede begge parter.
Senior-nivÄ
Ă
h, mitt favorittnivÄ.
Fremfor deg stÄr en solid spesialist, som har utviklet seg gjennom ulike prosjekter, en person som allerede vet hva de vil, og hva de ikke liker sÄ mye.
Og sÄ begynner showet:
â dype spĂžrsmĂ„l om systemadministrasjon (se fĂžrste antipattern)
â dype spĂžrsmĂ„l om Linux generelt fra teorier, langt fra praktisk kunnskap (OSI-modellen er et topp spĂžrsmĂ„l)
â akademiske spĂžrsmĂ„l om koding (fordi intervjueren selv ikke er kjent med omrĂ„det, han ble bare bedt om Ă„ intervjue en merkelig DevOps-er)
Jeg vil gjÞre en liten bemerkning her. En gang, pÄ et intervju, ble jeg bedt om Ä skrive en bit kode. PÄ papir. Som alle elsker, hver dag skriver, papir er alt for oss.
Etter Ä ha lÞst oppgaven, etter Ä ha sett pÄ lappen min og lÞsningen, ble det lagt fram en dom om at algoritmen ville vÊre suboptimal. Jeg foreslo at intervjueren skulle skrive sin egen algoritme, noe jeg fikk svaret «Det faller utenfor intervjuets rammer» pÄ. Jeg ba om et minutt, gjorde noen endringer i koden og viste det frem, og spurte om det ville vÊre raskere eller langsommere? Til svar fikk jeg, vi gÄr videre til neste spÞrsmÄl. Forskjellen var i hvordan koden jobbet i en lÞkke og uten lÞkke, og jeg hadde et klart svar pÄ hvorfor det var bedre Ä gjÞre det pÄ denne mÄten, i stedet for den andre. Vel, etter dette hadde jeg ikke lyst til Ä svare pÄ spÞrsmÄl og jobbe med denne personen.
Det er viktig Ă„ huske at vi alle er forskjellige, og noe som ikke er betydningsfullt for deg, kan skremme kandidaten bort.
â vanligvis har spesialister pĂ„ seniornivĂ„ en klart definert arbeidsstabel, men nei, vi mĂ„ begynne Ă„ presse dem pĂ„ noe nĂŠrt, for eksempel, du har skrevet Ansible, flott, men vi bruker Puppet, vi inviterte deg bare for moro skyld, sĂ„ fortell om Puppet. Fantastisk! Har du jobbet med OpenShift? Vi har K8s, vi kjenner ikke forskjellene, men din erfaring er irrelevant. Utmerket!
Det finnes ogsĂ„ en underklasse â jeg personlig tar inn praktikanter som kan vokse til juniornivĂ„.
Jeg Þnsker at alle skal forstÄ at en praktikant er en enhet som ennÄ ikke er helt formet. Jeg blir skremt nÄr praktikanter begynner Ä bli pushet opp til et sterkt juniornivÄ og deretter, med et tilfreds smil, tilbys praksisplass (noen ganger ubetalt, skrekk!).
Ikke gjÞr det sÄnn.
En praktikant, etter mitt syn, er enten en student pÄ siste Är eller noen som er veldig ivrig etter Ä «gÄ inn i IT».
Med studenter er det enkelt â finn ut hva de driver med pĂ„ universitetet, hva de har gjort selv, se pĂ„ hvilke spĂžrsmĂ„l som fĂ„r Ăžynene deres til Ă„ lyse â hvis de lyser opp, spĂžr hvorfor de valgte DevOps og hva de faktisk vet om det. FĂžle mennesket og forstĂ„ om det vil vĂŠre hyggelig Ă„ jobbe videre med dem, om man virkelig Ăžnsker Ă„ lĂŠre akkurat dette mennesket noe.
Med dem som Ăžnsker Ă„ «gĂ„ inn i IT», er det litt strammere â se hvor mye personen har vĂŠrt selvstudert, hva de har gjort fĂžr de kom til intervjuet, her vil et godt alternativ vĂŠre Ă„ se pĂ„ GitHub, hvis de har det, tettheten pĂ„ commits og hvilke Ăžvelser de har gjort. OgsĂ„ spĂžrre hvorfor de velger DevOps, for det er jo morsommere og mer utfordrende i frontend?
Avslutningsvis vil jeg igjen gi et rÄd: vÊr tydelig pÄ hvem du virkelig trenger, sÄ vil du umiddelbart finne den rette personen. Identifiser behovene, vurder spesialisten som en spesialist, finn hans sterke sider og bruk dem effektivt i arbeidet ditt. VÊr oppmerksom pÄ den som blir intervjuet; han kom til deg for en samtale, ikke for en konkurranse om hvem som vil imponere eller ikke.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish