Salut tuturor, dragi cititori!
Astăzi vreau să îmi împărtășesc gândurile despre o temă veche și dureroasă, și poate să o discutăm în comentarii.
Destul de des întâlnesc articole despre practicile proaste de interviu pentru un programator, care, în opinia mea, sunt destul de relevante și, sper, citite de departamentele HR ale unor companii mari și nu numai.
În zona noastră, atât cât pot judeca, există o cerere pentru entități interesante precum inginerul DevOps. Mă număr printre cei care nu percep foarte bine această sintagmă (da, da, metoda DevOps etc.), așa că văd o anumită diferență în căile de dezvoltare ale acestei grupări de specialiști.
În primul rând, cred cu tărie că fiecare om are cercul său de interese, chiar și în domeniul profesional, adică unora le plac norii, altora le place să se apuce de administrarea serverelor aplicații, să configureze profund Java, iar altora să scrie cod în Python sau, Doamne ferește, cod YAML. Aici apar așa-numiții ingineri de infrastructură, ingineri de construcție, Senior Yaml Developer 🙂
Toate acestea permit, pe de o parte, găsirea unei persoane care se potrivește cel mai bine cu setul vostru de sarcini, iar pe de altă parte, creează neînțelegeri la interviuri.
Pe baza experienței personale, am susținut un anumit număr de zeci de interviuri și am participat în diverse calități, vreau să împărtășesc perspectiva mea asupra tuturor celor întâmplate.
Primul și probabil cel mai drag mie anti-model - dorința de a avea pe cineva care să facă totul, sau nu se știe cine este necesar, să vedem o mulțime de candidați și vom înțelege acolo. Probabil că acest lucru se aplică în orice domeniu, dar aici sunt anumite particularități.
Așa cum am observat, oamenii sunt mai atrași de anunțurile de angajare cu cuvântul DevOps decât de Administrator de sistem, deși, în opinia mea, la nivelul Senior, domeniul sarcinilor este extrem de diferit în aceste două domenii.
Orice angajator, care are cu adevărat nevoie de un administrator de sistem, scrie în titlul anunțului devops, enumerând în corpul cererii absolut tot felul, K8S/Java/gradle/oracleDB etc. pe listă, deși, din interior, persoana trebuie să se ocupe de suportul clusterului K8S și de suportul stivei OracleDB în lipsa echipei.
Deci, care este, în acest caz, interacțiunea dintre Developeri/Operațiuni?
Apoi se dovedește că nu există un proces de interacțiune cu echipa și, în general, nu există un departament de operațiuni, iar voi trebuie să configurați calculatoarele dezvoltatorilor.
Această variantă se potrivește într-adevăr unei părți din candidați, dar să fim sinceri, este vorba despre Administrator de Sistem Senior, așa că de ce nu vor să scrie așa și ce este atât de rușinos în asta? Diferența de salariu între diferitele denumiri profesionale? Dar bugetul companiei este același, și cum i-ai da nume, tot va înota pe bugetul său.
În plus, am auzit că acum candidatul automatizează rapid totul și se integrează în dezvoltarea produsului în Python, care este diferența, peste tot Python este același. Diferențele în viziuni și abordări nu sunt luate în considerare.
Apoi, de obicei, diferențiez nivelul specialiștilor care vin, iar pentru fiecare văd propriile neplăceri.
Junior - personal, pentru mine, Junior DevOps este o persoană care a stăpânit la un nivel mediu administrarea sistemelor / dezvoltarea. Aici îmi face plăcere să diferențiez Linuxoid-ii puternici care doresc să crească într-un nou domeniu, sau dezvoltatorii care au dorința de a face bine pentru alți dezvoltatori. Persoane solide, cu abilități de depanare, căutare a jurnalelor, sau cu un anumit număr de proiecte codificate.
Am întâlnit atât administratori de sistem care au încercat ceva și vor să se apropie de cloud, cât și pe cei care au încercat frontend, backend și din diverse motive și-au găsit interesul în procesele DevOps.
La acest nivel, mă deranjează întotdeauna când încep să vorbesc despre un stivă uriașă de tehnologii, Puppet, Ansible - de ce nu ai încercat tot? K8S, K3S - cu ce se deosebesc? Câte tipuri de baze de date știi? De ce atât de puține? Cum funcționează criptarea în Java? În special cei care vin din dezvoltare, deși sunt persoane foarte utile, pentru ei întotdeauna există muncă în acest domeniu.
Mă lasă întotdeauna perplex când se întâmplă asta, prima întrebare pe care vreau să o pun este - de ce??? a doua întrebare care îmi vine în minte - este intervievatorul pregătit să răspundă la întrebările despre un astfel de stivă diversificat? Nu vor să angajeze un junior și să-i pună totul în spate?
Adesea, întâlnesc asta în diferite bodyshop-uri, când trebuie să vândă o persoană pe un anumit proiect și au nevoie de mai multe cuvinte impresionante pentru CV, sau compania nu vrea să angajeze pe nimeni, ci doar se uită la ce fel de juni există.
Nivelul Middle
Aici sunt câteva extremități, din punctul meu de vedere. În primul rând, cred că este dificil să determini exact când o persoană devine nivel mid. Ori încearcă să o coboare la junior, ori o tratează ca pe un senior, încercând să obțină un senior la preț de mid (da, piața decide, nimic personal).
Cel mai surprinzător lucru pe care l-am observat este că se ajunge adânc în codare, să folosești Python, să te lupți cu Java GC, adică cu teme deja mai bine specializate, sau dimpotrivă, să deschizi goluri în cunoștințele vechi, să alergi prin rețele, tipuri de drivere de OS, râzând și bucurându-te că o persoană a putut uita asta. Și aici se întâmplă lucrul cel mai interesant!
La nivelul mid, din punctul meu de vedere, specialistul își formează un cerc de interese și o viziune personală asupra a ceea ce vrea să facă: să fie la curent cu cele mai recente tehnologii, integrându-le în portofoliul său, sau să se dezvolte pentru un antrepriză mare, aprofundând performanța codului.
Consider că already aici ar trebui să întrebăm despre procesele la care persoana a lucrat, să aflăm ce a fost cu adevărat interesant și ce nu și, pe baza acestor informații, să construim un grup de întrebări, mapând neapărat întrebările pe propriul nostru stack. Altfel, după o discuție fascinantă de o oră sau două despre configurarea unui cluster OpenShift, angajezi o persoană și o pui să construiască monitorizarea. Probabil că asta va plăcea ambele părți.
Nivelul Senior
O, nivelul meu preferat.
În fața voastră se află un specialist puternic, care s-a dezvoltat în cadrul diferitelor proiecte, o persoană care deja știe ce își dorește și ce nu îi place atât de mult.
Și aici începe spectacolul:
— întrebări dificile despre administrarea sistemelor (vezi primul antipattern)
— întrebări profunde despre Linux în general, din domeniul teoriei, departe de cunoștințe practice (Întrebarea de bază OSI)
— întrebări academice despre codare (pentru că intervievatorul însuși nu știe bine domeniul, a fost pur și simplu rugat să intervină cu un devops mai ciudat)
Aici voi face o mică observație. Odată, la un interviu, mi s-a cerut să scriu un anumit fragment de cod. Pe o foaie. Așa cum fac toți, scriind zi de zi, foaia este totul pentru noi.
După ce am finalizat sarcina, după ce am examinat foaia mea și soluția, a fost emis verdictul că algoritmul va fi neoptimal. Am propus ca intervievatorul să își scrie propriul algoritm, la care am primit răspunsul „Nu face parte din interviu”. Am cerut un minut, am modificat puțin codul și am arătat, întrebând, dacă va fi mai rapid sau mai lent? La care am primit răspunsul, hai să trecem la următoarea întrebare. Diferența era în modul de funcționare a codului în interiorul unei bucle și fără buclă și aveam o explicație pregătită de ce ar fi mai bine să facem așa, nu așa. Ei bine, după asta nu mai aveam poftă să răspund la întrebări și să lucrez cu această persoană.
Trebuie să ținem cont că suntem diferiți și orice detaliu care pentru tine este nesemnificativ poate alunga un candidat.
— de obicei, specialiștii de nivel Senior au descris clar tehnologiile pe care le folosesc, dar nu, trebuie să începem să trecem în revistă lucruri apropiate, spre exemplu, aveți scris Ansible, excelent, dar la noi este Puppet, te-am invitat doar așa, hai să ne povestești despre Puppet. Grozav! Ai lucrat cu OpenShift? La noi avem K8s, nu știm diferențele, dar experiența ta nu este relevantă. Minunat!
Există și un astfel de subtip — personal eu îmi aleg stagiaires pentru a-i pregăti pentru a deveni Junior.
Ar fi bine ca toți să înțeleagă că un stagiar este o entitate care încă nu s-a format. Mă sperie teribil când stagiairele sunt împinse la nivelul unui Junior experimentat și apoi, cu o față mulțumită, le oferă o stagiu (uneori neplătită, un coșmar!)
Nu faceți așa.
Un stagiar, din punctul meu de vedere, este fie un student în an terminal, fie cineva care foarte mult își dorește să „iasă în IT”.
Cu studenții e simplu — este excelent să afli ce face la universitate, ce a realizat singur, să observi pe ce întrebări își luminează ochii — dacă se luminează, să întreb de ce anume DevOps și ce știe despre asta. Să simți omul și să înțelegi dacă va fi plăcut să lucrezi mai departe cu el, dacă dorești să-i înveți ceva anume.
Cu cei care vor să „iasă în IT”, lucrurile sunt puțin mai riguroase — să observi cât de mult se autoînvață, ce a realizat înainte de a ajunge la tine la interviu, aici o variantă bună ar fi să te uiți pe GitHub, dacă există, densitatea commit-urilor și ce exerciții au fost realizate. De asemenea, să întrebi de ce totuși DevOps, căci în frontend e mai distractiv și mai ingenios?
În cele din urmă, aș dori să ofer, din nou, un sfat: stabiliți cine vă este cu adevărat necesar și veți găsi imediat persoana potrivită. Identificați nevoile, priviți specialistul ca pe un expert, găsiți punctele lui forte și folosiți-le eficient în munca dumneavoastră. Fiți atenți la candidatul care vine la dumneavoastră pentru discuție, nu pentru un concurs de cine va fi respins sau acceptat.
Sursa: habr.com
