Antimönster för DevOps-intervjuer

Hej alla mina kära läsare!

Idag vill jag dela med mig av mina tankar kring ett ämne som länge har varit aktuellt, och kanske diskutera det i kommentarerna.
Ganska ofta stöter jag på artiklar om dåliga intervjumetoder för programmerartjänster, som jag anser är ganska livslevande och som jag hoppas läses av HR-avdelningar på både stora och små företag.

Här i våra trakter, så mycket jag kan bedöma, finns det en efterfrågan på intressanta entiteter som DevOps-ingenjör. Jag tillhör dem som inte riktigt förstår termen (ja, ja, DevOps-metodologin, osv), så jag ser vissa skillnader i utvecklingsvägar för denna grupp av specialister.
Först och främst tror jag helhjärtat att varje människa har sitt eget intresseområde, även inom sitt arbetsfält, det vill säga vissa älskar moln, andra gillar att gräva djupt i applikationsservrar, anpassa Java på djupet, medan andra skriver kod i Python eller, Gud förbjude, yaml-kod. Så här kommer vi till de så kallade Infrastruktur ingenjörerna, Byggingenjörerna, Senior Yaml-utvecklarna 🙂
Detta gör att man å ena sidan kan hitta en person som passar perfekt för din uppsättning uppgifter, men å andra sidan skapar det missförstånd under intervjuer.
Baserat på min personliga erfarenhet av att ha genomfört ett antal Dussintals intervjuer samt deltagit i olika som svarande, vill jag dela med mig av min syn på allt som händer.

Den första och kanske min favoritantipattern - att vilja att någon ska kunna göra allt, eller att oklart vem som behövs, så vi kollar en massa kandidater och därifrån ser vi vad som passar. Kanske tillämpas detta på alla områden, men här finns det sina egna egenskaper.
Som jag lagt märke till, är folk mer benägna att söka jobb med ordet DevOps jämfört med Systemadministratör, fast jag anser att på Senior-nivå skiljer sig uppgiftsområdet maximalt mellan dessa två områden.
Alla arbetsgivare som faktiskt behöver en systemadministratör, skriver i rubriken till jobbet 'DevOps', och listar i begäran absolut allt, K8S/Java/gradle/oracleDB osv, även om det inombords innebär att personen kommer att ägna sig åt att stödja en K8S-kluster och underhålla OracleDB-stacken oberoende av teamet.
Så, vilket samspel finns det här mellan formatet Utvecklare/Drift?
Det visar sig att det inte finns något sätt för detta interaktionsprocess med teamet, och egentligen finns det ingen operationsavdelning, så du måste ställa in utvecklarnas datorer.
Den här varianten passar faktiskt vissa kandidater, men låt oss vara ärliga, det handlar om Senior System Administrator, så varför vill man inte skriva det och vad är det som är så skamligt med det? Skillnaden i lön mellan olika yrkesnamn? Men företagets budget är densamma, och hur man än kallar ett fartyg, så kommer det att segla på sin budget.
Jag har faktiskt hört talas om det, nu automatiserar kandidaten allt snabbt och går in i produktutvecklingen på Python, vilken skillnad, överallt är Python densamma. Skillnader i värderingar och angreppssätt beaktas inte.

Jag brukar vanligtvis differentiera nivån på specialister som kommer in och ser specifika problem för var och en av dem.
Junior — personligen ser jag Junior DevOps som en person som har en medelnivå av kunskap inom systemadministration / utveckling. Här är det trevligt att differentiera starka Linux-användare som vill växa inom det nya området, eller utvecklare som har ett intresse av att göra gott för andra utvecklare. Starka, med någon form av färdigheter inom debug, loggsökning, eller med ett antal genomförda projekt.
Jag har träffat både systemadministratörer som har provat något och vill beröra moln, liksom de som har provat frontend, backend och av olika anledningar funnit intresse i DevOps-processer.
På denna nivå blir jag alltid förvirrad när någon börjar prata om en enorm teknikstack, Puppet, Ansible — varför har man inte provat allt? K8S, K3S — vad är skillnaden? Hur många databastyper känner du till? Varför så få? Hur fungerar kryptering i Java? Speciellt de som har kommit från utveckling, även om det är mycket användbara personer, det finns alltid arbete för dem inom detta område.
Det gör mig alltid förvirrad när det händer, det första jag vill fråga är - varför??? Det andra som kommer att tänka på är - är verkligen intervjuaren redo att svara på frågor om en så varierad teknikstack? Vill de verkligen anställa en junior och lasta honom med allt?
Detta händer ofta i olika bodysjoppar, när man måste sälja en person till ett projekt och behöver fler fina ord för CV:t eller så vill företaget helt enkelt inte ta in några, utan bara se vilka juniorer som finns.

Nivån Middle
Här finns flera extremiteter, tycker jag. För det första är det nog svårt att klargöra när någon drar mot mid-nivå; antingen försöker man fördröja dem till junior eller så behandlar man dem som senior, vilket försöker få en senior för mellannivåns pris (ja, marknaden bestämmer, inget personligt).
Det mest fantastiska jag har sett är att gå djupt in i kodning, arbeta med Python, plåga Java GC, det vill säga mer specifika ämnen, eller å andra sidan, avslöja luckor i länge bortglömda kunskaper, navigera i nätverk, operativsystemets drivrutins typer, och jag ler och hånar hur någon kunde glömma detta. Och här händer det mest intressanta!
Till mid-nivå, enligt min åsikt, formar specialisten ett intresseområde och en personlig syn på vad de vill arbeta med - att ha en trend på den senaste teknologin, stoppa in en kub av trick, eller träna sig för det skrämmande företagslivet, djupdyka i kodens prestanda.
Enligt min åsikt är det värt att fråga om de processer som personen har arbetat med, fråga vad som var mest intressant och vad som inte var det, och basera en kluster av frågor på dessa kunskaper, och noggrant kartlägga frågorna på sin stack. Annars, efter en fascinerande konversation på en eller två timmar om konfiguration av OpenShift-kluster, anställa någon och låta dem bygga övervakning. Det skulle nog tillfredsställa båda sidor.

Seniornivå
Åh, min favoritnivå.
Framför er står en stark specialist som har vuxit upp på olika typer av projekt, en person som redan vet vad de vill ha och vad de inte är så förtjusta i.
Och här börjar showen:
— djupa frågor inom systemadministration (se första antipatternen)
— djupa frågor om Linux i allmänhet, från teorin, långt ifrån praktiska kunskaper (OSI-modellens nivåer, en topp-fråga)
— akademiska frågor om kodning (för att intervjuaren själv inte riktigt känner till området, de bad bara att intervjua en konstig devops)
Jag vill göra en liten anmärkning här. En gång, under en intervju, bad de mig skriva en bit kod. På ett papper. Precis som alla älskar, man skriver ju varje dag, pappret är allt.
Efter att ha fullföljt uppgiften och efter att ha granskat min anteckning och lösningen, blev det klart att algoritmen skulle vara suboptimal. Jag föreslog att intervjuaren skulle skriva sin egen algoritm, på vilket jag fick svaret "Det ingår inte i intervjun". Jag bad om en minut, gjorde lite ändringar i koden och visade den, och frågade om det skulle vara snabbare eller långsammare? Jag fick svaret att vi går vidare till nästa fråga. Skillnaden var i kodens arbete i en loop och utan loop, och jag hade förberett ett svar om varför det är bättre att göra så istället för så. Efter det kände jag att jag inte ville svara på fler frågor och arbeta med den personen.
Det är viktigt att komma ihåg att vi alla är olika, och även små detaljer som du kanske anser vara obetydliga kan skrämma en kandidat.
— Vanligtvis har specialister på seniornivå en tydlig arbetsstack, men så är inte fallet. Istället börjar man ställa frågor om närstående ämnen; till exempel, ni har Ansible, utmärkt, men vi använder Puppet, vi kallade er bara för att ni ska berätta om Puppet. Utmärkt! Har ni arbetat med OpenShift? Vi har K8s, vi känner inte till skillnaderna, men er erfarenhet är irrelevant. Fantastiskt!

Det finns också en underklass — jag tar personligen praktikant för att växa in i juniorkarriären.
Jag vill att alla ska förstå att en praktikant är en entitet som ännu inte är helt formad. Jag blir fruktansvärt skrämd när praktikanter pressas upp till en stark junior-nivå och sedan erbjuds praktik (ibland obetald, vilket är en mardröm!).
Det behövs inte.
En praktikant, i min mening, är antingen en student på högre årskurser, eller någon som verkligen vill "gå in i IT-branschen".
Med studenter är det enkelt — det handlar om att ta reda på vad de sysslar med på universitetet, vad de själva har gjort, och se på vilka frågor deras ögon gnistrar — om de gör det, fråga varför just DevOps och vad de överhuvudtaget vet om det. Känn av personen och förstå om det skulle vara trevligt att fortsätta arbeta med dem, om man vill undervisa just den personen.
Med dem som vill "gå in i IT-branschen" är det lite tuffare — undersök hur självdrivna personen är, vad de har gjort innan de kom till er intervju, ett bra alternativ är att titta på deras GitHub, om de har en, hur ofta de begår och vilka övningar de har genomfört. Fråga också varför just DevOps, eftersom frontend oftast är roligare och mer intressant?

Och avslutningsvis vill jag återigen ge rådet: bestäm er för vem ni verkligen behöver, så hittar ni genast rätt person. Identifiera behov, se på specialisten som en expert, upptäck hans styrkor och utnyttja dem framgångsrikt i ert arbete. Var uppmärksam på den intervjuade; han kom för att ha en diskussion, inte för att tävla om vem som ska misslyckas eller lyckas.

Källa: habr.com