Антипаттерны DevOps собеседования

Приветствую вас всех, мои дорогие читатели!

Сегодня я хочу поделиться своими мыслями о давно наболевшей теме, и возможно, обсудить ее в комментариях.
Достаточно часто мне попадаются статьи по плохим практикам собеседования на должность программиста, которые на мой взгляд достаточно жизнены и, надеюсь, читаемы HR отделами компаний крупных и не очень.

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

Первый и наверное самый мой любимый антипаттерн — желание кого-нибудь, чтобы он делал все, или непонятно кто нужен, посмотрим кучу кандидатов, там поймем. Наверное, это применимо к любой области, но тут есть свои особенности.
Как я обратил внимание, люди больше падки на вакансии со словами DevOps чем System Administrator, хотя на мой взгляд на уровне Senior область задач максимально отличается в этих двух областях.
Любой работодатель, которому на самом деле нужен сисадмин, пишет в заголовке вакансии девопс, перечисляя в теле запроса абсолютно все подряд, K8S/Java/gradle/oracleDB и тд по списку, хотя изнутри человеку предстоит заниматься поддержкой кластера K8S и поддержкой OracleDB стека в отрыве от команды.
Ну то есть и какое тут взаимодействие формата Developers / Operations?
Далее выясняется, что и как такого процесса взаимодействия с командой не предусмотрено и вообще, operations как отдела нет и вам предстоит и компы разработчиков настраивать.
Такой вариант на самом деле, подходит части соискателей, но давай те будем честны, это Senior System Administrator, так почему не хотят так писать и что вообще в этом постыдного? Отличие в зп между разными названиями профессий? Но бюджет у компании один, и как корабль не назови, поплывет он на свой бюджет.
Ну и еще даже слышал про такое, сейчас кандидат все быстро автоматизирует и вольется в разработку продукта на питоне, какая разница, везде питон один и тот же. Разница в мировозрении и подходах не учитывается.

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

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

Уровень Senior
О, мой любимый уровень.
Перед вами крепкий спец, который взрастил себя на разного рода проектах, человек, который уже знает что хочет, а что ему не так сильно нравится.
И вот начинается шоу:
— глубокие вопросы по системному администрированию (см. первый антипаттерн)
— глубокие вопросы по линуксу в целом из области теории, далекой от практических знаний ( Уровни OSI топовый вопрос )
— академические вопросы по кодингу ( потому что сам интервьюер толком не знает область, его просто попросили пособеседовать странного девопса)
Сделаю тут ремарку небольшую. Как то раз, на собеседовании меня попросили написать какой то кусочек кода. На листочке. Ну как все любят, каждый день пишут, листочек наше все.
Справившись с задачей, после просмотра моего листочка и решения, был видвинут вердикт, что алгоритм будет неоптимальный. Я предложил, чтобы интервьер написал свой алгоритм, на что получил ответ «Это не входит в рамки собеседования». Я попросил минутку, переделал немного код и показал, спросив, так будет быстрее или медленее? На что получил ответ, перейдем к следующему вопросу. Разница была в работе кода в цикле и без цикла и у меня был заготовлен ответ почему лучше сделать так, а не так. Ну после этого мне уже не хотелось отвечать на вопросы и работать с данным человеком.
Надо учесть, что все мы разные и кандидата может отпугнуть любая вещь, которая для вас несущественна.
— обычно у спецов уровня Senior четко описан рабочий стек, так нет же, надо начинать гонять по близкому, к примеру, у вас написано Ansible, отлично а у нас Puppet, мы вас просто так позвали, ну ка расскажите про Puppet. Превосходно! Работали с OpenShift? У нас K8s, мы различий не знаем, но ваш опыт нерелеватный. Замечательно!

Есть еще такой подкласс — я лично себе беру стажеров на вырост в джунов.
Вот хочется, чтобы все понимали что стажер это сущность еще вообще не сформированная. Меня ужасно пугает, когда стажеров начинают гонять на уровень крепкий Junior и потом, с довольным видом предлогают стажировку (иногда неоплачиваемую, кошмар !)
Не надо так.
Стажер, на мой взгляд это либо студент старших курсов, либо вот кому то очень хочется «уйти в айти».
Со студентами все просто — отлично узнать, чем занимается в университете, что делал сам, посмотреть на каких вопросах загорятся глаза — если загорятся, спросить почему именно в девопс и что вообще про это известно. Почувствовать человека и понять, будет ли приятно с ним дальше возиться, хочется ли научить чему то именно этого человека.
С теми, кто хочет «уйти в айти», чуть все построже — посмотреть насколько человек самообучается, что сделал перед тем, как попасть к вам на собеседование, тут уже хороший вариант будет посмотреть гитхаб, если имеется конечно, плотность коммитов и какие были упражнения сделаны. Распросить так же, почему все же девопс, ведь в фронтенде веселее и затейливее?

Ну и напоследок, хочется дать в очередной раз совет, определитесь, кто вам на самом деле нужен и вы сразу же найдете необходимого человека. Выявите потребности, посмотрите на специалиста как на специалиста, найдите его сильные стороны и успешно используйте их в вашей работе. Будьте внимательны к собеседуемому, он пришел к вам на беседу, а не на соревнование, кто кого завалит или не завалит.

Автор: SicYar

Источник