Я — айтишник, я не хочу много знать
За последнее время мне довелось провести немало технических собеседований на позицию DevOps инженера, в связи с чем появилась идея формализовать полученные выводы в этой статье. Хочу поделиться своими наблюдениями, субъективным мнением, и задать самому себе вопросы, ответы на которые, возможно, мне помогут получить читатели данной статьи.
Я понимаю, что под определение так называемого DevOps инженера от компании к компании подпадает очень разный набор навыков, следовательно, требования также будут заметно варьироваться. Поэтому попробую описать что такое DevOps инженер, или SRE (как мне привычнее) для меня в рамках нынешней организации: специалист, поддерживающий инфраструктуру проекта на всех уровнях, реализующий автоматизацию инфраструктуры, процессов разработки и тестирования, в некоторой степени DBA, конечно SRE и евангелист DevOps культуры. Так как цель статьи в другом, то не хотелось бы тут размышлять на тему того, кто такой DevOps инженер, существует ли он, маркетинговый ли это термин и вот это вот всё, оставим этот холивар. Я думаю, что в основном понятно, о каких специалистах я говорю.
Я являюсь тимлидом команды именно таких инженеров. Мы не профилируемся внутри команды по направлениям, каждый занимается бóльшей частью из перечисленного.
Пару слов о кандидатах
Встречают по одежке. Одежкой в нашем случае является резюме соискателя.
Просматривая резюме, полученные от HR, которые прошли первичные фильтры и соответствуют корпоративным нормам, глаз радуется, представляется, если не полностью, то очень сильно удовлетворяющий ожиданиям кандидат. Ощущается прилив радости, и появляется настрой на интересный продуктивный для обеих сторон разговор.
Как правило, кандидаты — это люди разных возрастов и из разных стран, имеющих опыт работы в компаниях разного размера и рода деятельности, иногда с немалым опытом администрирования различных nix систем, с опытом автоматизации инфраструктуры и процессов разработки/тестирования, взаимодействия с базами данных, кластерными системами, и, конечно же, с серьезными ожиданиями по заработной плате (серьёзность запросов по ЗП относительна, имеются в виду мощные запросы в рамках условного грейда). Многие не хотят участвовать в мелком предварительном тестировании, обосновывая это неприемлемой тратой времени.
Немного о первичном отборе. Он представляет из себя традиционное вводное знакомство с HR. HR не проводит предварительного технического интервью, а лишь субъективно оценивает опыт кандидата, стремясь удовлетворить пожеланиям команды, находящейся в процессе поиска.
В рамках технического интервью, проводимых для поиска новых специалистов, я общаюсь с кандидатами, разделяя разговор на два больших блока: фундаментальные темы (операционные системы, сети, базы данных, методологии, точечно прочие компьютерные науки) и инструментарий (здесь может быть всё что угодно, Ansible, Terraform, Helm, Kubernetes, контейнеры, скриптинг, реализация конкретной небольшой задачи в определенных условиях и так далее). В среднем, общаемся в районе полутора часов, за которые я прихожу всё чаще к тем выводам, о которых буду рассказывать далее, и которые подчеркивают тему данной статьи.
Ниже приведу несколько вопросов и частые ответы кандидатов. Замечу, что среди отвечающих были преподаватели онлайн школ и сертифицированные специалисты по разным технологиям/облакам/методологиям.
Зачем мне что-то знать про память, всё же в кубере
Это та мысль, которую в разных формулировках я слышу очень часто от соискателей. Приходим мы к этому умозаключению после того, как я задаю свой первый вопрос, про то, сколько памяти занимает процесс с указанным PID (кандидату демонстрируется скриншот или экран с выводом top). 80% соискателей с опытом администрирования nix систем не знают ответ, теряются или говорят очень странные вещи, 10% без объяснения выбора способны указать на колонку RES, и оставшиеся с разным успехом могут поговорить и порассуждать про виртуальное адресное пространство, разделяемую память, OOM, оверкоммиты, стэки, кучи и так далее.
Приведенный вопрос, как и любой другой в рамках собеседования, может получить множественное развитие как в глубину, так и в ширину, но происходит это крайне редко. Не совсем понятно, каким образом такой инженер выставляет адекватные реквесты/лимиты приложению в кубере, каким образом задаёт max-old-space-size для V8 (и делает ли это вообще). Может быть вопрос действительно лишний (пусть не всё, но большинство приложений же в кубере) и морально устарел?
Сети… Это всегда было не моё, а в облаках оно вообще не актуально
Следующая частая формулировка, которая появляется после вопросов про понимание, например, маски подсети или TCP-сессии. То есть инженер работает с кластерными системами, с кубером, наливает ансиблом большие группы узлов, а сети, получается, это что-то лишнее, недосягаемое? Видимо, во всем многообразии «сетевых» процессов вряд ли что-то может пойти не так, а в случае чего, лучше, наверное, нанять отдельного специалиста, который умеет запускать ping, traceroute и dig, да ещё и понимать их выхлоп.
Вряд ли же придётся заниматься дебагом NAT в облаках при множественных подключениях изнутри (при наличии единственного IP адреса на облачном маршрутизаторе), вряд ли нужно будет разбираться, почему пакетики из одного региона страны не доходят в облако до приложения, вряд ли понадобится VPN до API облачного кубера. И ведь действительно, вопросы сетевого взаимодействия в 2023-ем уже могли изжить себя?
HTTP GET используется только для получения информации
Это 90% ответов на просьбу сравнить GET и POST методы. Мы говорим тут про GET и POST как таковые, не привязываясь, например, к CRUD для REST. Возможно, понимать суть и отличие данных методов сегодня действительно не нужно, ведь всегда есть документация к API, а разработчик никогда не реализует метод против стандартов?
Почему у вас нет Argo CD?
Встречный вопрос, который я получаю в контексте беседы про GitOps как в нашей реализации, так и в целом. То есть для многих соискателей есть прямая и неразрывная связь между GitOps подходом и инструментом, реализующим его, при этом беседа про абстрактный GitOps, не привязанный к инструментам, вызывает бурю негодований и странное предвзятое отношение.
Другим ярчайшим и популярным примером про неразрывность инструментов и методологий, как мне кажется, является разговор про CI/CD. Зачастую, CI/CD — это Gitlab CI, Teamcity или Jenkins, а не методологии, решающие конкретный список проблем/задач в процессах разработки, для удобной реализации которых есть готовые, ранее перечисленные инструменты. Кажется, пришло время внедрять Argo CD, мы же GitOps делаем?
Приведенные примеры подчеркивают нежелание большого количества нынешних специалистов погружаться в вопрос и разбираться в теме, что не может радовать. Бывали случаи, когда кандидаты не просто показывали незнание по тому или иному вопросу, а вступали в конфликт о том, что не должно быть таких, как мы задаём, глубоких вопросов на собеседовании DevOps инженеров, не должно быть бóльшей части затронутых тем. И всё бы ничего, но расстраивает факт отстранения работников интеллектуального труда от своей непосредственной деятельности, не желая о ней думать. Такое происходит конечно же не только в рамках DevOps инженеров, а распространяется и на другие направления, что я могу наблюдать, общаясь с соискателями на позиции бэкенд разработчиков и тестировщиков.
По описанным выше вопросам становится понятно, что ничего из ряда вон мы не требуем, нормальные инженерные вопросы, которые с разных сторон пытаются раскрыть кандидата. Мы не гоняем по алгоритмам, не просим спроектировать нагруженный онлайн видео сервис в масштабах планеты (хотя, системный дизайн был бы классным модулем), да и не просим тонко под задачу затюнить СУБД, но как ни крути, только лишь опыт использования облачного K8s вместе с Ansible на несколько узлов и деплой всего через Gitlab CI, не является для нас достаточным, как уже должно быть понятно из описания в начале статьи.
Я понимаю, что далеко не везде желаемые мной запросы к кандидатам. На рынке немало мест, на которых поверхностное понимание инструментария является достаточным, а какие-то более глубокие проблемы решают местные гуру. Может ли это говорить о том, что ИТ как сфера приходит к более четкому квалификационному разделению? Может ли это говорить о том, что насыщения рынка соискателями, владеющих лишь инструментарием, станет со временем трендом и стоит ли переживать на этот счет? И да, ни в коем случае не хочу сказать, что я тут один тут стою в пальто белом, я всего лишь рассуждаю «вслух» о сложившейся вокруг меня ситуации.
Выводы
Резюме не имеет ничего общего с реальными знаниями и навыками соискателя.
Многих интересуют только зарплаты, без реального увлечения технологиями.
Фундаментальные, нетленные знания пугают соискателей, всерьёз не воспринимаются как необходимые, иногда вызывают улыбки.
Большинство соискателей видят роль DevOps инженера следующим образом: YAML, какая-нибудь технология контейнеризации (на уровне пользователя), какая-нибудь система оркестрации (на уровне пользователя), Terraform, Ansible.
Эти же соискатели не согласны с тем, что DevOps инженер это: основы операционных систем, основы баз данных, основы сетей, основы распределенных систем, любые другие основы, не связанные с верхнеуровневым инструментарием и перекладыванием конфигов, для получения очередной абстракции.
В чем я могу ошибаться
Я считаю себя энтузиастом в ИТ, для меня это не только работа, но и одно из увлечений, в связи с чем могут проявляться завышенные ожидания к соискателям.
Субъективное ощущение реальности и рынка, выстраивают неверный набор запросов и уровень ожидаемых ответов. Мой личный и сторонний (коллеги, статьи и т. п.) опыт собеседований в крупные и небольшие ИТ компании, склоняет меня в сторону тех примеров, в которых присутствовал более жесткий отбор с более высокими требованиями.
Наличие слишком малой, нерепрезентативной выборки, приводящей к ошибочным умозаключениям о соискателях.
Вопросы без ответа
Не слишком ли широкий спектр обязанностей падает на каждого инженера в нашей команде, может быть нужно делиться по профилям?
Может быть я неправильно (или крайне неудачно) подобрал блоки вопросов для собеседования?
Что мы можем улучшить, как ужесточить фильтр на этапе отбора резюме и первичного общения с HR для обеспечения наиболее продуктивного общения на всех последующих этапах, но при этом не отпугнуть кандидата?
