Hej allesammen, mine kære læsere!
I dag vil jeg gerne dele mine tanker om et længe omdiskuteret emne, og måske diskutere det i kommentarerne.
Jeg støder ofte på artikler om dårlige interviewpraksisser for programmører, som jeg mener er ret relevante og, håber jeg, læsbare for HR-afdelinger i både store og små virksomheder.
Her i vores områder, så vidt jeg kan bedømme, er der efterspørgsel efter interessante roller som DevOps-ingeniør. Jeg tilhører de mennesker, der ikke helt forstår denne term (ja, ja, DevOps-metodologi osv.), så jeg ser en vis forskel i udviklingsvejene for denne gruppe fagfolk.
For det første tror jeg helhjertet på, at enhver person har sin egen interessecirkel, selv inden for arbejdslivet; nogle elsker cloud-løsninger, andre er into dybdegående arbejde med applikationsservere, opsætning af Java i dybden, og nogle skriver kode i Python eller, Gud forbyde det, YAML-kode. Det vil sige, der opstår såkaldte Infrastructure Engineers, Build Engineers, Senior YAML Developers 🙂
Alt dette giver på den ene side mulighed for at finde en person, der passer bedst til dit opgavesæt, men på den anden side skaber det misforståelser under interviews.
Baseret på min personlige erfaring, hvor jeg har gennemført et antal dødsspiraler af interviews og også deltaget i forskellige som respondent, vil jeg gerne dele mit syn på det hele.
Den første og helt sikkert min yndlings antipattern — ønsket om at finde en, der kan gøre alt, eller hvem de nu har brug for, vi ser på en masse kandidater og finder ud af det derfra. Det gælder sikkert for alle områder, men der er sine egne særheder her.
Som jeg har bemærket, er folk mere tilbøjelige til at være interesseret i stillinger med ordet DevOps end System Administrator, selvom jeg mener, at ansvarsområderne på Senior-niveau er maksimalt forskellige i disse to områder.
Enhver arbejdsgiver, der reelt har brug for en sysadmin, skriver i stillingsannonceoverskriften DeVops, mens de i beskrivelsen angiver alt muligt, K8S/Java/Gradle/OracleDB osv. i rækkefølge, selvom personen indvendigt vil skulle arbejde med at støtte K8S-klyngen og vedligeholde OracleDB-stakken adskilt fra teamet.
Så hvad er der egentlig for interaktion mellem formaterne Developers/Operations?
Det viser sig, at der ikke er noget fastlagt for, hvordan man interagerer med teamet, og generelt er der ikke noget operations-afdeling, så du skal også konfigurere udviklernes computere.
Denne mulighed passer faktisk til nogle ansøgere, men lad os være ærlige, det er en Senior System Administrator, så hvorfor vil de ikke skrive det sådan, og hvad er der overhovedet pinligt ved det? Forskellen i løn mellem forskellige jobtitler? Men budgettet for virksomheden er det samme, og uanset hvad man kalder skibet, vil det sejle under dets budget.
Jeg har også hørt, at nu kan kandidaten hurtigt automatisere alt og komme ind i produktudviklingen med Python, hvilken forskel gør det, Python er det samme overalt. Forskellen i verdenssyn og tilgange tages ikke i betragtning.
Normalt differentierer jeg niveauet for specialisterne, der kommer ind, og jeg ser individuelle udfordringer for hver af dem.
Junior — for mig er en Junior DevOps en person, der har opnået et mellemste niveau inden for systemadministration / udvikling. Her er det rart at differentiere stærke Linux-folk, der ønsker at vokse i et nyt område, eller udviklere, der ønsker at gøre godt for andre udviklere. Stærke, med nogen færdigheder i debugging, søgning af logs eller med noget erfaring fra kodede projekter.
Jeg har mødt både systemadministratorer, der har prøvet noget og ønsker at røre ved cloud-teknologier, og dem, der har prøvet front-end, back-end og af en eller anden grund fundet interesse i DevOps-processerne.
På dette niveau undrer det mig altid, når man bliver overvældet af et stort teknologistak, Puppet, Ansible — hvorfor har du ikke prøvet alt? K8S, K3S — hvad adskiller dem? Hvor mange typer databaser kender du? hvorfor så lidt? hvordan fungerer kryptering i Java? Især dem, der kom fra udviklingen, selvom de er meget nyttige, har de altid mulighed for arbejde i dette område.
Det sætter mig altid i undren, når noget sådant sker; det første, jeg vil spørge, er — hvorfor??? det andet, der kommer til at tænke på — er intervieweren selv klar til at svare på spørgsmål om et så varieret teknologistak? Vil de virkelig tage en junior og læsse det hele på vedkommende?
Det sker ofte i diverse bodysales, hvor man skal sælge en person til et bestemt projekt og har brug for flere imponerende ord til CV'et, eller virksomheden ønsker slet ikke at ansætte nogen og ser bare, hvad juniorer der findes.
Middel niveau
Der er et par yderligheder, efter min mening. For det første er det nok svært at bestemme, hvad der præcist gør en person til en mid-level, da personen enten forsøges presset ned til junior-niveau eller behandles som en senior, idet man prøver at få en senior til mid-level pris (ja, markedet bestemmer, intet personligt).
Det mest overraskende, jeg har set, er at dykke dybt ned i kodning, arbejde med Python, kæmpe med Java GC, med andre ord, mere specifikke emner, eller omvendt, udforske hullerne i viden, der længe ikke er blevet brugt, arbejde med netværk, typer af operativsystemdrivere, grine og skadefro over, hvordan en person kunne glemme dette. Og her sker der det mest interessante!
I forhold til mid-level, synes jeg, at specialisten udvikler en interessekreds og en personlig opfattelse af, hvad han ønsker at arbejde med — om man vil hype med den nyeste teknologi eller arbejde sig op til det store enterprise og dykke ned i kodeens performance.
Efter min mening bør man allerede her spørge ind til de processer, som personen har arbejdet med, undersøge, hvad der var mest interessant, og hvad der ikke var, og basere en kluster af spørgsmål på denne viden, altid kortlægge spørgsmål til ens eget stack. Ellers, efter en spændende samtale på en til to timer om konfiguration af et OpenShift-kluster, ansætte personen og lade ham bygge overvågning. Det ville sikkert glæde begge parter.
Senior niveau
Åh, mit yndlingsniveau.
Foran dig står en stærk specialist, der har opbygget sig selv på forskellige projekter, en person, der allerede ved, hvad han vil, og hvad han ikke så meget kan lide.
Og så begynder showet:
— dybe spørgsmål om systemadministration (se første antipatron)
— dybe spørgsmål om Linux generelt fra teoretiske områder, langt fra praktisk viden (OSI-lag, et top spørgsmål)
— akademiske spørgsmål om kodning (fordi intervieweren selv knap nok kender området, han blev bare bedt om at interviewe en mærkelig devops)
Jeg vil her lave en lille bemærkning. En gang, til et interview, blev jeg bedt om at skrive en lille smule kode. På et stykke papir. Som alle elsker, man skriver hver dag, papiret er alt.
Efter at have løst opgaven, efter at have set mit papir og løsningen, blev der fremlagt en dom, at algoritmen ville være suboptimal. Jeg foreslog, at intervieweren skulle skrive sin egen algoritme, hvilket jeg fik svaret "Det ligger ikke inden for rammerne af interviewet". Jeg bad om et minut, omformulerede lidt koden og viste det, og spurgte, om det ville være hurtigere eller langsommere? Til gengæld fik jeg svaret, lad os gå videre til næste spørgsmål. Forskellen var i, hvordan koden fungerede i løkken og uden løkke, og jeg havde et forberedt svar på, hvorfor det var bedre at gøre det sådan i stedet for sådan. Nå, efter det havde jeg ikke længere lyst til at svare på spørgsmål og arbejde med denne person.
Man skal huske, at vi alle er forskellige, og enhver lille ting kan skræmme kandidaten, som for dig måske virker ubetydelig.
— normalt har specialister på Senior-niveau en klart defineret arbejdsstack, men næh, man skal begynde at køre på nært beslægtede, eksempelvis, at du har skrevet Ansible, fremragende, men vi har Puppet, vi har bare inviteret dig ind sådan, lad os høre om Puppet. Fantastisk! Har du arbejdet med OpenShift? Vi har K8s, vi kender ikke forskellen, men din erfaring er irrelevant. Vidunderligt!
Der er også en underklasse — jeg tager personligt praktikanter ind for at udvikle dem til juniors.
Jeg ønsker, at alle skal forstå, at en praktikant er en enhed, der slet ikke er dannet endnu. Jeg bliver frygteligt skræmt, når praktikanter begynder at blive dyttet op på niveauet af en solid Junior, og derefter, med et tilfreds ansigt, tilbyder en praktikplads (nogle gange ulønnet, skræmmende!).
Lad vær med det.
En praktikant er efter min mening enten en studerende på de øverste kurser, eller en, der virkelig gerne vil "gå ind i IT-branchen".
Med studerende er det enkelt — finde ud af, hvad de laver på universitetet, hvad de har gjort selv, se på hvilke spørgsmål der får øjnene til at lyse — hvis de lyser op, spørg hvorfor netop DevOps og hvad de har kendskab til. Føle personen og forstå, om det vil være behageligt at arbejde videre med ham, om man ønsker at lære netop denne person noget.
Med dem, der vil "gå ind i IT-branchen", skal man være lidt hårdere — se på, hvor selvstændig personen er, hvad han har gjort før han kom til intervjuet hos dig, her er det en god idé at tjekke GitHub, hvis det er tilgængeligt, tætheden af commits og hvilke øvelser der er lavet. Sørg også for at spørge, hvorfor det blev DevOps, for front-end er sjovere og mere intrigant?
Og til sidst vil jeg endnu engang anbefale, at I finder ud af, hvem I virkelig har brug for, og I vil straks finde den rette person. Identificer behovene, se på specialisten som en specialist, find hans styrker og brug dem effektivt i dit arbejde. Vær opmærksom på den, du interviewer; han er kommet til dig for en samtale, ikke for at konkurrere om, hvem der falder eller ikke falder.
Kilde: habr.com
