Hallo allemaal, mijn beste lezers!
Vandaag wil ik mijn gedachten delen over een onderwerp dat al geruime tijd speelt, en misschien het in de reacties bespreken.
Ik kom vaak artikelen tegen over slechte interviewpraktijken voor de functie van programmeur, die naar mijn mening erg herkenbaar zijn en hopelijk gelezen worden door HR-afdelingen van bedrijven, groot en klein.
In onze streken, voor zover ik kan beoordelen, is er vraag naar interessante entiteiten zoals DevOps ingenieurs. Ik ben iemand die niet veel waarde hecht aan die term (ja, de DevOps-methodologie, enz.), en daarom zie ik een verschil in de carrièremogelijkheden van deze groep specialisten.
Allereerst geloof ik heilig dat iedereen zijn eigen interesses heeft, zelfs op professioneel gebied. De één houdt van cloudtechnologieën, de ander van diepgaand werk met applicatieservers, het instellen van Java, en weer een ander houdt van coderen in Python of, hemel beware, YAML-code. Hieruit ontstaan zogenaamde Infrastructure engineers, Build engineers, Senior YAML Developers 🙂
Dit stelt je enerzijds in staat om de juiste persoon voor je taken te vinden, maar anderzijds creëert het misverstanden tijdens interviews.
Gebaseerd op persoonlijke ervaring, heb ik een aantal tientallen interviews afgenomen en ook deelgenomen aan verschillende als respondent. Ik wil mijn kijk op het geheel delen.
Mijn eerste en waarschijnlijk favoriete antipatroon is de wens om iemand te vinden die alles doet, of niet goed te weten wie nodig is; laten we veel kandidaten bekijken en dan wel begrijpen. Dit is waarschijnlijk van toepassing op elk gebied, maar er zijn specifieke aspecten.
Zoals ik heb opgemerkt, zijn mensen meer geneigd om te reageren op vacatures met het woord DevOps dan met System Administrator, hoewel de taken op senior-niveau in deze twee gebieden in mijn ogen maximaal verschillen.
Elke werkgever die echt een systeembeheerder nodig heeft, schrijft in de vacaturekop DevOps, en somt in de vacaturetekst een heleboel dingen op, K8S/Java/gradle/oracleDB, enzovoort, terwijl die persoon in werkelijkheid verantwoordelijk zal zijn voor het onderhouden van een K8S-cluster en de OracleDB-stack, los van het team.
Dus wat is hier de interactie tussen de formaten Developers/Operations?
Daarna blijkt dat er geen proces is voor de interactie met het team en dat er simpelweg geen operations-afdeling is; dan moet jij ook nog de computers van de ontwikkelaars instellen.
Dit soort optie past eigenlijk bij een deel van de sollicitanten, maar laten we eerlijk zijn, dit is een Senior System Administrator, dus waarom willen ze dit niet zo schrijven en wat is daar eigenlijk beschamend aan? Het salarisverschil tussen verschillende functienamen? Maar het budget van het bedrijf is hetzelfde, en welk schip je ook een naam geeft, het vaart op zijn budget.
Ik heb zelfs gehoord dat kandidaten tegenwoordig alles snel automatiseren en zich in de productontwikkeling met Python kunnen inwerken; wat maakt het uit, Python is overal hetzelfde. Het wereldbeeld en de benaderingen worden niet meegenomen.
Verder maak ik meestal onderscheid tussen de niveaus van specialisten die binnenkomen, en voor elk niveau zie ik mijn eigen problemen.
Junior — voor mij is een Junior DevOps iemand die op gemiddeld niveau systeembeheer/development heeft geleerd. Hier is het prettig om sterke Linux-geeks te onderscheiden die willen groeien in een nieuw gebied, of ontwikkelaars die het goed willen doen voor andere ontwikkelaars. Sterke kandidaten, met wat vaardigheden in debugging, het zoeken naar logs, of met een aantal gecodeerde projecten.
Ik heb zowel systeembeheerders ontmoet die iets hebben geprobeerd en de clouds willen verkennen, als degenen die front-end en back-end hebben geprobeerd en om een of andere reden interesse hebben gevonden in de DevOps-processen.
Op dit niveau stoort het me altijd als mensen meteen beginnen over een enorm tech-stapel, Puppet, Ansible — waarom heb je niet alles geprobeerd? K8S, K3S — wat is het verschil? Hoeveel soorten databases ken je? Waarom zo weinig? Hoe werkt encryptie in Java? Vooral degenen die uit de ontwikkeling komen, hoewel dit zeer nuttige mensen zijn, hebben altijd werk in dit gebied.
Ik word altijd perplex wanneer dit gebeurt; het eerste wat ik wil vragen is — waarom??? Het tweede wat in me opkomt is — is de interviewer zelf klaar om vragen te beantwoorden over zo'n gevarieerd tech-stapel? Willen ze echt een junior aannemen en alles op hem of haar leggen?
Dit komt vaak voor in allerlei bodyshells, waar ze iemand moeten verkopen voor een project en meer indrukwekkende woorden voor het cv nodig hebben, of het bedrijf wil gewoon niemand aannemen en kijkt naar de beschikbare juniors.
Niveau Midden
Er zijn hier naar mijn mening een paar extremen; ten eerste is het waarschijnlijk moeilijk om precies te bepalen wanneer iemand de vaardigheden van een mid-level heeft. Of ze proberen iemand naar de junior-niveau te drukken, of beginnen ze te behandelen als een senior, in de hoop een senior-lid in te huren voor de prijs van een mid-level (ja, de markt bepaalt, niets persoonlijks).
Het meest verbazingwekkende dat ik heb gezien, is dat iemand diep in de code duikt, Python schrijft, worstelt met Java GC, dat wil zeggen dat ze zich bezighouden met meer diepgaande specifieke onderwerpen, of juist gaten opvullen in lang niet gebruikte kennis, en zich bezighouden met netwerken, soorten OS-drivers, en met een grijns en leedvermaak zich afvragen hoe iemand dat kon vergeten. En dan gebeurt het meest interessante!
Naar mijn mening ontwikkelt een specialist op het mid-level een kring van interesses en een persoonlijke kijk op wat hij of zij wil doen — wild zijn op de meest recente stack, dingen in een container en dat allemaal doen, of zich versterken voor de ongrijpbare enterprise, terwijl ze de diepte van de prestatietests van de code ingaan.
Ik denk dat het tijd is om vragen te stellen over de processen waarmee de persoon heeft gewerkt, te vragen wat het meest interessant was en wat niet, en op basis van deze kennis een cluster van vragen op te bouwen, door de vragen onvermijdelijk te mappen naar hun eigen stack. Anders, als je een boeiend gesprek van een tot twee uur over het configureren van een OpenShift-cluster hebt, om iemand in te huren en deze persoon te laten werken aan monitoring, zal het waarschijnlijk beide partijen bevallen.
Senior niveau
Oh, mijn favoriete niveau.
Voor je staat een sterke specialist die zichzelf heeft opgebouwd op verschillende projecten, iemand die al weet wat hij of zij wil en wat niet zo leuk is.
En dan begint de show:
— diepgaande vragen over systeembeheer (zie het eerste antipatroon)
— diepgaande vragen over Linux in het algemeen vanuit theoretische hoeken, ver verwijderd van praktische kennis (de OSI-niveaus zijn een topvraag)
— academische vragen over coderen (omdat de interviewer zelf niet echt kennis heeft van het gebied, hij of zij is gewoon gevraagd om een vreemde DevOps te interviewen)
Ik wil hier een kleine opmerking maken. Een keer werd me tijdens een sollicitatie gevraagd om een stuk code te schrijven. Op een papiertje. Zoals iedereen dat graag doet, elke dag schrijven ze, papiertje is ons alles.
Na het voltooien van de taak, na het bekijken van mijn blaadje en het oplossen, werd het oordeel gegeven dat het algoritme suboptimaal zou zijn. Ik stelde voor dat de interviewer zijn eigen algoritme zou schrijven, waarop ik het antwoord kreeg: 'Dat valt niet onder het sollicitatiegesprek.' Ik vroeg om een minuut, heb een beetje code aangepast en liet het zien, vragend of dit sneller of langzamer zou zijn? Waarop het antwoord kwam, laten we naar de volgende vraag gaan. Het verschil zat in de werking van de code met en zonder lus, en ik had een antwoord voorbereid waarom het beter was om het zo te doen en niet zo. Nou, daarna had ik al geen zin meer om vragen te beantwoorden en met deze persoon te werken.
Je moet in gedachten houden dat we allemaal verschillend zijn en iets wat voor jou onbeduidend is, kan een kandidaat afschrikken.
— meestal hebben specialisten op het niveau Senior een duidelijk gedefinieerde stack, maar nee, je moet beginnen met vragen over verwante zaken. Bijvoorbeeld, je hebt Ansible genoemd, geweldig, maar wij hebben Puppet, we hebben je zomaar uitgenodigd, vertel eens over Puppet. Geweldig! Heb je met OpenShift gewerkt? Wij hebben K8s, we weten niet wat de verschillen zijn, maar jouw ervaring is niet relevant. Fantastisch!
Er is ook zo'n subklasse — ik neem persoonlijk stagiairs aan om door te groeien naar junior posities.
Ik wil graag dat iedereen begrijpt dat een stagiair een entiteit is die nog helemaal niet gevormd is. Het maakt me enorm bang wanneer stagiairs op het niveau van een sterke junior worden behandeld en vervolgens met een tevreden gezicht een stage worden aangeboden (soms onbetaald, een nachtmerrie!).
Dat hoef je niet te doen.
Een stagiair is in mijn ogen of een student in de hogere jaren, of iemand die heel graag de overstap naar IT wil maken.
Met studenten is het eenvoudig — je leert uitstekend wat ze op de universiteit doen, wat ze zelf hebben gedaan, en kijkt naar de vragen waarop hun ogen gaan glinsteren — als dat gebeurt, vraag je waarom precies DevOps en wat ze daar eigenlijk van weten. Voel de persoon aan en begrijp of het prettig zal zijn om verder met hem of haar aan de slag te gaan, of je deze persoon iets wilt leren.
Met degenen die de overstap naar IT willen maken, is het iets strenger — kijk naar hoeveel de persoon zichzelf kan onderwijzen, wat ze hebben gedaan voordat ze bij jou op sollicitatiegesprek kwamen. Een goede optie is om hun GitHub te bekijken, als ze die hebben, qua aantal commits en welke oefeningen ze hebben gedaan. Vraag ook waarom ze toch voor DevOps kiezen, want front-end is leuker en creatiever!
Tot slot wil ik je nogmaals adviseren om duidelijk te worden over wie je eigenlijk nodig hebt, dan vind je vanzelf de juiste persoon. Identificeer de behoeften, kijk naar de specialist als een professional, ontdek zijn sterke punten en maak daar succesvol gebruik van in je werk. Wees attent op de persoon die je spreekt, hij is bij jou op gesprek gekomen, niet om een competitie aan te gaan wie de meeste fouten maakt.
Bron: habr.com
