Антипатерни при DevOps интервюта

Здравейте, скъпи читатели!

Днес искам да споделя мислите си за една стара актуална тема и вероятно да я обсъдим в коментарите.
Достатъчно често попадам на статии относно лоши практики при интервютата за позиция программист, които според мен са доста значими и се надявам да бъдат прочетени от HR отделите на големи и малки компании.

В нашия регион, доколкото мога да съдя, има търсене на интересни професии като DevOps инженер. Отнасям се към онези хора, които не възприемат много добре това словосъчетание (да-да, DevOps методология и т.н.), затова виждам определени разлики в пътищата за развитие на тази група специалисти.
На първо място, свято вярвам, че всеки човек има свой сфера на интереси, дори в работната си област, т.е. на някой му допадат облаците, друг се занимава с дълбочинно разглеждане на Application servers, дълбочинна настройка на Java, а на трети му е приятно да пише код на Python или, упаси боже, yaml код. Тоест тук се появяват така наречените Infrastructure engineer, Build engineer, Senior Yaml Developer 🙂
Всичко това позволява от една страна да се намери човек, който най-добре отговаря на вашите нужди, а от друга създава недоразумения по време на интервютата.
На базата на личния ми опит, проведох доста десетки интервюта и също така участвах в различни роли като отговарящ, искам да споделя погледа си върху всичко, което се случва.

Първият и вероятно любимият ми антипатерн – желанието да имаш някого, който да прави всичко, или неопределеност относно това кой е нужният, виждаме куп кандидати, там ще разберем. Вероятно, това е приложимо за всяка област, но тук има свои особености.
Както забелязах, хората по-често са привлечени от обяви с думата DevOps отколкото с System Administrator, въпреки че от моя гледна точка на ниво Senior областта на задачите е максимално различна между тези две сфери.
Всеки работодател, наистина нуждаещ се от системен администратор, в заглавието на обявата пише DevOps, изброявайки в текста абсолютно всичко, K8S/Java/gradle/oracleDB и т.н., въпреки че от вътре човекът ще трябва да се занимава с поддръжката на K8S клъстери и поддръжката на OracleDB стек настрани от екипа.
Т.е. какво е взаимодействието между разработчици и операции?
По-нататък се оказва, че такъв процес на взаимодействие с екипа не е предвиден и изобщо отдел operations не съществува, а вие ще трябва и компютрите на разработчиците да настройвате.
Тази опция наистина подхожда на част от кандидатите, но да бъдем честни, това е Senior System Administrator, така че защо не искат да го напишат така и какво е срамното в това? Разликата в заплатата между различните названия на професиите? Но бюджетът на компанията е един, и каквото и име да му сложиш, накрая ще отговори на своя бюджет.
Чувал съм, че кандидатите бързо автоматизират и се интегрират в разработката на продукта на Python, каква разлика, навсякъде Python е един и същ. Разликата в светогледа и подходите не се отчита.

Обикновено разграничавам нивото на специалистите, които идват, и за всеки един поотделно виждам своите затруднения.
Junior — лично за мен Junior DevOps, това е човек, който е усвоил администриране / разработка на средно ниво. Тук е приятно да разграничим силните Linux потребители, които искат да напредват в нова сфера, или разработчиците, които имат желание да работят за други разработчици. Силните, с някакви умения в дебъгването, търсене на логове, или с определен запас от проекти.
Срещал съм както администратори, които са опитали нещо и искат да се запознаят с облачните технологии, така и такива, които са пробвали с фронтенд, бэкенд и по определени причини са намерили интерес в процесите DevOps.
На това ниво винаги ме смущава, когато започват да се перят с огромен стек технологии, Puppet, Ansible — защо не са опитвали всичко? K8S, K3S — с какво се различават? Колко вида бази данни знаеш? защо толкова малко? как работи криптирането в Java? Особено от тези, които идват от разработката, въпреки че те са много полезни кадри, за тях винаги има работа в тази област.
Винаги ме оставя безизходица, когато се случва нещо такова, първото, което искам да питам — защо??? второто, което ми идва наум — готов ли е самият интервюиращ да отговори на въпросите за такъв разнообразен стек? Не е ли истински, че искат да вземат Junior и да натоварят всичко върху него?
Често такова се среща в различни бодишопи, когато трябва да продадат човек на някакъв проект и им трябват повече впечатляващи думи за резюмето, или компанията не иска никого да взима, а просто се надигат, за да видят какви са Junior.

Нивото Middle
тук има няколко крайности по мое мнение. Първо, вероятно е трудно да се определи точно какво прави човек мидъл — или се опитват да го свалят до джуниор, или започват да го натискат като сеньор, опитвайки се да хванат сеньор на цената на мидъл (аха, пазарът решава, нищо лично).
Най-изненадващото, което съм виждал, е да се потопиш дълбоко в кодирането, да смачкаш питончето, да мъчиш Java GC, т.е. да влезеш в по-дълбоко специализирани теми, или обратното, да откриеш пропуски в отдавна неизползвани знания, да покараш по мрежи, типове драйвери на ОС, усмихвайки се и злорадствайки, как е могъл човек да забрави това. И тук става най-интересното!
По мое мнение, на мидъл ниво специалистът формулира кръг от интереси и личен поглед върху това, с което иска да работи — да се наслади на най-новия стек, смесвайки го в кубчета подмана, или да се развива за страшния ентърпрайз, потапяйки се в дълбочината на производителността на кода.
По мое мнение, тук е редно да разпиташ за процесите, по които човек е работил, да питаш какво е било най-интересно, а какво не, и въз основа на тези знания да построиш кластер от въпроси, задължително свързвайки въпросите с твоя стек. В противен случай, след като проведеш увлекателен разговор за един-два часа за конфигуриране на OpenShift клъстер, да наемеш човек и да го настаниш да изгражда мониторинг. Вероятно това ще хареса на двете страни.

Ниво Сеньор
О, моето любимо ниво.
Пред вас е силен специалист, който е израснал на различни проекти, човек, който вече знае какво иска и какво не му харесва толкова много.
И тук започва шоуто:
— дълбоки въпроси по системно администриране (вижте първия антипатерн)
— дълбоки въпроси по линукс като цяло, от теория, далечна от практическите знания (Нива на OSI, топов въпрос)
— академични въпроси по кодирането (защото самият интервюиращ не знае областта, просто е помолен да проведе интервю с някакъв странен девопс)
Ще направя тук малка забележка. Един път, на интервю, ме помолиха да напиша някакъв парче код. На лист хартия. Е, както всички обичат, всеки ден пишат, листа е всичко.
След като се справих със задачата, след преглед на листа ми и решението, беше издаден вердикт, че алгоритъмът ще бъде неоптимален. Предложих, интервюиращият да напише своя алгоритъм, на което получих отговор: 'Това не е в рамките на интервюто'. Помолих за минутка, преработих малко кода и показах, попитах, дали така ще бъде по-бързо или по-бавно? На което получих отговор, да преминем към следващия въпрос. Разликата беше в работата на кода в цикъл и без цикъл и имах подготвен отговор защо е по-добре да се направи така, а не иначе. След това вече не ми се искаше да отговарям на въпросите и да работя с този човек.
Трябва да се има предвид, че всички ние сме различни и всяка дреболия, която за вас не е съществена, може да изплаши кандидата.
Обикновено при специалисти на ниво Senior е ясно описан работният стек, но не, трябва да започнем да търсим нещо близко, например, при вас е написано Ansible, чудесно, а при нас Puppet, просто ви поканихме, хайде, разкажете за Puppet. Превъзходно! Работили ли сте с OpenShift? При нас е K8s, не познаваме разликите, но вашият опит е нерелевантен. Чудесно!

Има и такъв подклас - аз лично набирах стажанти, които да израснат до junior.
Много ми се искаше всички да разберат, че стажантът е нещо, което все още не е напълно формирано. Ужасно ме плаши, когато стажантите започнат да бъдат натоварвани на ниво 'крепък Junior' и след това, с доволен вид предлагат стаж (понякога неплатен, ужас!)
Не е нужно така.
Стажантът, на моето мнение, е или студент от по-горни курсове, или някой много иска да 'влезе в IT'.
Със студентите всичko е просто - отлично е да разберете, с какво се занимава в университета, какво е правил сам, да видите на какви въпроси му светват очите - ако светнат, да попитате защо точно DevOps и какво изобщо знае за него. Да усетите човека и да разберете, дали ще е приятно да се работи с него, иска ли да научи нещо точно този човек.
С тези, които искат 'да излязат в IT', е малко по-строго - да се види доколко човекът учи сам, какво е направил, преди да дойде на интервюто при вас, тук вече е добро да се погледне GitHub, ако разбира се, има такъв, плътността на комитите и какви упражнения са били направени. Да се пита и защо все пак DevOps, нали фронтендът е по-весел и интересен?

Накрая искам отново да дам съвет – определете кой наистина ви е нужен и веднага ще намерите подходящия човек. Разберете нуждите, погледнете на специалиста като на специалист, открийте силните му страни и успешно ги използвайте в работата си. Бъдете внимателни към интервюирания, той е дошъл при вас на разговор, а не на състезание, в което да се опитва да надвие другия.

Източник: habr.com