Здравейте на всички вас, мои скъпи читатели!
Днес искам да споделя мислите си по една дълго обсъждана тема и евентуално да я дискутираме в коментарите.
Достатъчно често попадам на статии за лоши практики по време на интервюта за програмисти, които според мен са доста реалистични и, надявам се, четими за HR отделите на големи и не толкова големи компании.
В нашия край, доколкото мога да съдя, има търсене на интересни специалности като DevOps инженер. Аз съм един от тези хора, които не възприемат особено това словосъчетание (да-да, DevOps методология и т.н.), затова виждам известна разлика в пътищата на развитие за тази група специалисти.
На първо място, свято вярвам, че всеки човек има свой кръг интереси, дори в работната сфера, тоест някои харесват облачни технологии, други обичат да се задълбочават в Application servers, настройвайки Java, а трети писат код на Python или, не дай боже, yaml код. Тоест тук се появяват така наречените Infrastructure engineer, Build engineer, Senior Yaml Developer 🙂
Всичко това от една страна позволява да намерите човек, максимално подходящ за вашия набор от задачи, а от друга създава недоразумения по време на интервютата.
На база личен опит, провел съм няколко десетки интервюта и също така участвам в различни роли като отговорник, искам да споделя моята гледна точка за всичко, което се случва.
Първият и вероятно най-любимият ми антипатърн е желанието на някого да прави всичко, или непонятно кого искате, да видим много кандидати, там ще разберем. Вероятно това е приложимо за всяка сфера, но тук има свои особености.
Както съм забелязал, хората са по-привлечени от обяви с думите DevOps, отколкото системен администратор, въпреки че според мен в нивото Senior обхватът на задачите максимално се различава в тези две области.
Всеки работодател, на когото наистина му е нужен системен администратор, пише в заглавието на обявата DevOps, изброявайки в тялото на запитването абсолютно всичко, K8S/Java/gradle/oracleDB и т.н., докато всъщност човекът ще трябва да се занимава с поддръжката на K8S клъстера и поддръжката на OracleDB стека, отделен от екипа.
Така че какво взаимодействие има между разработчици и операции?
По-нататък се установява, че такъв процес на взаимодействие с екипа не е предвиден и изобщо, отдел Operations не съществува, а вам предстои да настройвате компютрите на разработчиците.
Тази опция всъщност е подходяща за част от кандидатите, но да бъдем честни, това е Senior System Administrator, защо не искат да го напишат така и какво е толкова срамно в това? Разликата в заплатите между различните названия на професии? Но бюджетът на компанията е един, и каквото и да му наречеш, ще плува според бюджета си.
Чувал съм и за подобно нещо, сега кандидата бързо автоматизира и се вливам в разработването на продукта на Python, каква разлика, навсякъде Python е един и същ. Разликата в светогледа и подходите не се отчита.
Обикновено на този етап аз разграничава ниво на специалисти, които идват и виждам отделни трудности за всяко от тях.
Junior — за мен лично Junior DevOps е човек, който е овладял на средно ниво системното адмириране / разработка. Тук е приятно да разграничаваш силни линуксоида, които искат да растат в нова област, или разработчици, които искат да правят добро за другите разработчици. Силни, с някакви умения за дебъгинг, търсене на лога или с някакъв запас от кодирани проекти.
Срещал съм както специалисти по системно администриране, които са се пробвали в облаците, така и такива, които са пробвали фронтенд, бекенд и по някакви причини са намерили интерес в процесите на DevOps.
На този етап винаги ме смущава, когато започват да валят с огромен стек от технологии, Puppet, Ansible — защо не си пробвал всичко? K8S, K3S — с какво се различават? Колко вида бази данни знаеш? Защо толкова малко? Как работи криптирането в Java? Особено тези, които идват от разработката, макар че те са много полезни кадри, за тях винаги има работа в тази област.
Винаги ме поставя в ступор, когато се случва такова нещо, първото, което искам да попитам, е — защо??? Второто, което ми идва на ум — дали самият интервюиращ е готов да отговаря на въпроси по такъв разнообразен стек? Наистина ли искат да наемат junior и да му повесат всичко?
Често се случва в различни боди шопове, когато трябва да продадат човек за определен проект и се нуждаят от повече готини думи за резюмето, или че компанията не иска никого и просто гледа какви джуниори има.
Ниво Middle
Тук има няколко крайности, които на мен ми се струват, че е трудно да се определи ясно за човек, който е на средно ниво, той или опитват да го свалят до junior, или започват да го натоварват като senior, опитвайки се да вземат senior на цената на среден (аха, пазарът решава, нищо лично).
Най-удивителното, което виждах — е да се потопяваш дълбоко в кодирането, да се занимаваш с Python, да мъчиш Java GC, тоест с теми, които са вече доста специфични, или обратно, да откриваш пропуски в познания, които отдавна не са били използвани, да се разхождаш по мрежи, типове драйвери на ОС, ухилявайки се и задоволявайки се как човек е могъл да забрави всичко това. И тук става най-интересното!
Според мен на ниво middle специалистът изгражда кръг от интереси и личен поглед за това, с какво иска да работи — да се възползва от най-свежия стек, натискайки в куба, или да се развива за страшния enterprise, потапяйки се в дълбочината на производителността на кода.
На мен ми се струва, че вече трябва да разпиташ за процесите, по които човек е работил, какво е било максимално интересно и какво не, и на базата на тези знания да изградите клъстер от въпроси, задължително обвързвайки въпросите с вашия стек. Иначе, провеждайки увлекателен разговор за час-два за конфигуриране на OpenShift клъстер, да наемеш човек и да го сложиш да строи мониторинг. Вероятно това ще се хареса и на двете страни.
Ниво Senior
О, моето любимо ниво.
Пред вас е силен специалист, който е израснал на различни проекти, човек, който вече знае какво иска, а какво не му харесва толкова много.
И тук започва шоуто:
— дълбоки въпроси по системно администриране (виж първия антипатърн)
— дълбоки въпроси по Linux в цялост от теория, далеч от практически знания (Нива OSI, основен въпрос)
— академични въпроси по кодирането (защото самият интервюиращ не знае по-добре областта, просто са го помолили да интервюира странен DevOps)
Ще направя тук малка забележка. Един път, на интервю, ме помолиха да напиша някакъв къс код. На лист хартия. Е, както всички обичат, всеки ден пишат, листът е всичко за нас.
След като се справих с началната задача, след преглед на бележката ми и решението, пристигна присъдата, че алгоритъмът ще бъде неоптимален. Предложих интервюиращият да напише своя алгоритъм, на което получих отговор "Това не е в рамките на интервюто". Помолих за минута, преработих малко кода и показах, питайки дали така ще е по-бързо или по-бавно? На което получих отговор, да преминем към следващия въпрос. Разликата беше в работата на кода в цикъл и без цикъл и имах подготовен отговор защо е по-добре да се направи така, а не иначе. След това вече не ми се искаше да отговарям на въпросите и да работя с този човек.
Трябва да вземете предвид, че всички ние сме различни и кандидатът може да бъде уплашен от всякаква дреболия, която за вас не е съществена.
— обикновено за специалисти на ниво Senior ясно е описан работния стек, но не, трябва да започнем да ги проверяваме по близки неща, например, вие имате написано Ansible, чудесно, а при нас е Puppet, просто така ви поканихме, разкажете за Puppet. Чудесно! Работили ли сте с OpenShift? При нас е K8s, не познаваме разликите, но вашият опит не е релевантен. Прекрасно!
Има и такъв подклас — лично си вземам стажанти, които да развивам в Junior.
Иска ми се всички да разберат, че стажантът е същина, която все още не е формирана. Ужасно ме плаши, когато стажантите започнат да бъдат тествани на нивото на стабилен Junior и след това, с удовлетворен вид, им предлагат стаж (понякога неплатен, ужас!).
Не прави така.
Според мен стажантът е или студент от горните курсове, или някой много желаещ "да навлезе в ИТ".
Със студентите всичко е просто — отлично е да узнаеш какво учат в университета, какво са правили сами, да видиш на какви въпроси ще им светнат очите — ако светнат, да попиташ защо точно DevOps и какво изобщо знаят за това. Да усетиш човека и да разбереш дали ще е приятно да работиш с него, дали искаш да научиш именно него на нещо.
С тези, които искат "да навлязат в ИТ", е малко по-строго — да видиш колко самообучават, какво са направили преди да дойдат на интервюто при вас, тук добър вариант е да се погледне GitHub, ако разбира се, имат такъв, плътността на комитите и какви задачки са имали. Също да питате защо все пак DevOps, след като във фронтенда е по-весело и интересно?
Накрая, бих искал отново да дам съвет: определете кой наистина ви е нужен и веднага ще намерите подходящия човек. Изяснете нуждите си, разгледайте специалиста като такъв, намерете силните му страни и успешно ги използвайте в работата си. Бъдете внимателни към кандидата, той е дошъл при вас за разговор, а не за състезание кой ще се провали.
Източник: habr.com
