Üdvözlök mindenkit, kedves olvasóim!
Ma szeretném megosztani a gondolataimat egy régóta aktuális témáról, és talán megbeszélni azt a hozzászólásokban.
Elég gyakran találkozom cikkekkel a programozói állásinterjúk rossz gyakorlatairól, amelyek véleményem szerint eléggé életszerűek és remélem, hogy a nagyobb és kisebb cégek HR osztályai is olvassák őket.
A mi vidékünkön, amennyire meg tudom ítélni, kereslet van olyan érdekes entitásokra, mint a DevOps mérnök. Én azok közé tartozom, akik kissé idegenkednek ettől a kifejezéstől (igen, DevOps metodológia, stb.), ezért valamiféle eltérést látok a fejlődési pályákban e szakemberek között.
Elsősorban szentül hiszem, hogy mindenkinek megvan a saját érdeklődési köre, még a munkaterületen belül is; van, aki az felhőkkel foglalkozik, van, aki mélyen belemerül az alkalmazás szerverekbe, mélyen beállítja a Javát, míg mások Python kódot írnak vagy, isten óvjon, yaml kódot készítenek. Így jelennek meg a különféle Infrastructure mérnökök, Build mérnökök, Senior Yaml fejlesztők 🙂
Ez lehetővé teszi egyrészt, hogy megtaláljuk a feladatainkhoz legjobban illeszkedő embert, másrészt pedig félreértéseket szül az állásinterjúkon.
Személyes tapasztalataimra alapozva, lefolytattam néhány tucat interjút, és részt vettem különböző nyilvános vitákban is; szeretném megosztani a véleményemet az eseményekről.
Az első és talán a legkedveltebb antipatóm – az a vágy, hogy valakit arra kérjünk, hogy mindent csináljon, vagy hogy nem világos, kire van szükség, megnézünk egy csomó jelöltet, azután majd megértjük. Valószínűleg ez bármely területre alkalmazható, de itt van néhány sajátosság.
Ahogy észrevettem, az emberek hajlamosabbak a DevOps kifejezést tartalmazó álláshirdetésekre jelentkezni, mint a Rendszergazda pozíciókra, holott véleményem szerint a Senior szinten a feladatkörök maximálisan eltérnek e két területen.
Bármely munkaadó, akinek valóban szüksége van rendszergazdára, DevOps-t ír a hirdetés címében, és a kérés szövegében szinte mindent felsorol, K8S/Java/gradle/oracleDB stb. listája szerint, holott valójában az illetőnek a K8S klaszter és az OracleDB támogatásával kell foglalkoznia, elvágva a csapattól.
Tehát mi itt a Developers/Operations közötti interakció?
Továbbá kiderül, hogy nem létezik a csapattal való ilyen típusú interakciós folyamat, és egyáltalán nem létezik operations mint részleg, így neked kell beállítanod a fejlesztők gépeit.
Ez a verzió valójában megfelel bizonyos pályázóknak, de legyünk őszinték, ez Senior System Administrator, miért nem akarják így megnevezni és miért kínos ez? A különbség a különböző szakmák elnevezése közötti bérekben rejlik? De a vállalat költségvetése egy, és bármilyen névre is nevezzük, az a saját költségvetésén fog úszni.
Nos és azt is hallottam, hogy most a jelölt mindent gyorsan automatizál, és beépül a termékfejlesztésbe Pythonban, teljesen mindegy, mindenhol ugyanaz a Python. A világnézet és a megközelítések közötti különbséget nem veszik figyelembe.
Továbbá általában megkülönböztetem a szakemberek szintjét, akik jönnek, és minden egyes esetben saját nehézségeimet látom.
Junior — számomra a Junior DevOps az az ember, aki közép szinten elsajátította a rendszergazdálkodást / fejlesztést. Itt kellemes megkülönböztetni a szilárd linuxosokat, akik szeretnének egy új területen fejlődni, vagy a fejlesztőket, akik szeretnék jól végezni a munkájukat más fejlesztők számára. Szilárd tudás, valamilyen hibakeresési vagy naplókeresési képességgel, vagy némi kódolt projekttel rendelkeznek.
Találkoztam olyan rendszergazdákkal is, akik kipróbáltak valamit, és szeretnének kapcsolatba lépni a felhőkkel, és olyanokkal is, akik megpróbálták a frontend és backend fejlesztést, és valamilyen okból érdekelték őket a DevOps folyamatok.
Ezen a szinten mindig zavarban vagyok, amikor valaki a hatalmas technológiai választékra kezdene hivatkozni, Puppet, Ansible — miért nem próbált meg mindent? K8S, K3S — miben különböznek? Hányféle adatbázist ismersz? Miért ennyire kevés? Hogyan működik a titkosítás Java-ban? Különösen azok, akik a fejlesztésből érkeztek, bár ők nagyon hasznos munkaerő, számukra mindig van munkalehetőség ezen a területen.
Mindig zavarba ejt, amikor ilyen történik, az első dolog, amit megkérdezek — miért??? A második, ami eszembe jut — a kérdező kész-e válaszolni egy ilyen változatos technológiai állományra vonatkozó kérdésekre? Valóban azt akarják, hogy vegyenek egy junior-t, és mindent rákészítsenek?
Gyakran találkozni ilyen helyzetekkel mindenféle cégnél, amikor el kell adni egy embert egy projektre, és több menő szóra van szükség az önéletrajzhoz, vagy a cég senkit nem akar felvenni, csak nézi, milyen juniorok vannak.
Middle szint
I think there are a few extremes here. Firstly, it’s probably hard to clearly determine that someone is aiming for a mid-level position; either they try to push them down to junior or start treating them like a senior, trying to grab a senior for the price of a mid-level (yeah, the market decides, nothing personal).
The most surprising thing I’ve seen is diving deep into coding, working with Python, torturing Java GC — that is, going into very specific topics, or, on the contrary, uncovering gaps in long-unused knowledge, dealing with networks, OS driver types, smirking and gloating at how someone could forget this. And here comes the most interesting part!
In my opinion, by the time one reaches mid-level, a specialist develops a circle of interests and a personal view of what they want to work with — to ride the wave on the latest stack, squeezing it into the cube of tricks, or to push for some serious enterprise, delving into the code's performance.
In my view, it’s worth asking about the processes the person has worked with, what was most interesting and what wasn’t, and based on this knowledge, build a cluster of questions, definitely mapping the questions to their stack. Otherwise, after having an engaging conversation for an hour or two about configuring an OpenShift cluster, hiring someone and then assigning them to build monitoring may not please either side.
Senior Level
Oh, my favorite level.
Before you stands a strong specialist who has grown through various projects, a person who already knows what they want and what they don’t prefer.
And here the show begins:
— in-depth questions about system administration (see the first anti-pattern)
— in-depth questions about Linux in general from a theoretical perspective, far removed from practical knowledge (OSI levels — top question)
— academic questions about coding (because the interviewer themselves doesn’t really know the area, they were just asked to interview some strange DevOps candidate)
Let me make a small remark here. Once, during an interview, I was asked to write some piece of code. On a piece of paper. Well, as everyone likes, we write every day, paper is everything.
A feladat megoldása után, miután átnéztem a cetlimet és a megoldást, az a verdikt született, hogy az algoritmus nem lesz optimális. Javasoltam, hogy a kérdező írja meg a saját algoritmusát, amire azt a választ kaptam, hogy "ez nem tartozik a beszélgetés keretei közé". Kértem egy percet, kicsit átírtam a kódot és megmutattam, megkérdezve, hogy így gyorsabb vagy lassabb lesz? Erre azt a választ kaptam, hogy lépjünk a következő kérdésre. A különbség a kód működése között ciklusban és ciklus nélkül volt, és volt egy előkészített válaszom, hogy miért jobb így csinálni, mint úgy. Nos, ezután már nem volt kedvem válaszolni a kérdésekre és dolgozni ezzel az emberrel.
Figyelembe kell venni, hogy mindannyian különbözőek vagyunk, és bármilyen dolog, ami számotokra nem lényeges, elriaszthatja a jelöltet.
– általában a Senior szintű szakembereknél világosan meg van határozva a munka teknológiai stack-je, de nem, tessék megint elkezdeni közelítve, például nálatok Ansible van, szuper, nálunk pedig Puppet, csak úgy meghívtunk, na mondd el, mi az a Puppet. Kitűnő! Dolgoztatok OpenShift-tel? Nálunk K8s van, a különbségekről nem tudunk, de a tapasztalatod irreleváns. Remek!
Van egy ilyen alosztály is – én személy szerint magamnak felveszek gyakornokokat, hogy növekedjenek juniorokká.
Az a vágyom, hogy mindenki megértse, hogy a gyakornok egy még teljesen meg nem formálódott lény. Rettentően megijeszt, amikor a gyakornokokat kemény Junior szintre kényszerítik, majd elégedett arccal javasolják a gyakornoki szerepet (néha még fizetés nélküli is, szörnyű!).
Ezt nem kéne.
Szerintem a gyakornok vagy egy felsőbb éves hallgató, vagy valaki, aki nagyon szeretne "átnyergelni az IT-be".
A hallgatókkal minden egyszerű – remekül megismerni, mivel foglalkozik az egyetemen, mit csinált, figyelni, hogy mely kérdésekre ragyognak fel a szemeik – ha felragyognak, megkérdezni, miért éppen DevOps és mit tud erről egyáltalán. Érezni az embert és megérteni, hogy öröm lesz-e tovább foglalkozni vele, szeretne-e ezt a konkrét embert tanítani valamire.
Akkor, akik "az IT-be" akarnak átlépni, kicsit szigorúbbak – megnézni, mennyire tud önállóan tanulni az ember, mit tett, mielőtt eljutott hozzátok a beszélgetésre, itt már jó lehetőség lesz megnézni a GitHub-ot, ha van, természetesen, a commitok sűrűsége és hogy milyen feladatokat végeztek el. Kérdezd meg azt is, miért éppen DevOps, hiszen a frontend szórakoztatóbb és bonyolultabb?
Végül, szeretném újfent ajánlani, hogy határozzák meg, valójában kire van szükségük, és azonnal megtalálják a megfelelő embert. Határozzák meg az igényeket, tekintsenek a szakemberre szakemberként, találják meg az erősségeit, és sikeresen használják azokat a munkájukban. Figyeljenek a jelentkezőre, ő beszélgetni jött önökhöz, nem versenyezni, hogy ki tudja jobban elgáncsolni a másikat.
Forrás: habr.com
