Достаточно часто я сталкиваюсь с существенной проблемой, которую допускают многие компании на уровне почти всех отделов при найме DevOps. Она многоуровневая и затрагивает как взаимодействие и зоны ответственности HR-отдела и нанимающей команды, так и выстраивание общих процессов внутри компании, например актуальной базы знаний и открытость дальнейших планов для лидов.
Меня зовут Андрей Сухоруков, я DevOps TeamLead в «Лаборатории Касперского». В IT я в общей сложности более 11 лет и в течение карьеры очень часто примерял на себя роль антикризисного лида, разрешая большие проблемы в больших проектах практически во всех отраслях бизнеса: металлургия, банки, госструктуры; был консультантом на аутсорсе. А еще — нанимал и, соответственно, собеседовал. Поэтому отлично знаю, о чем говорю.
Как будто бы для того, чтобы проверить работоспособность будущего коллеги, достаточно просто задать несколько вопросов из этой хабрастатьи на 75 минут чтения. Грамотность и профессионализм инженера таким образом выяснить достаточно легко, ведь это такая база, без понимания которой невозможен ни один процесс развертывания и тем более построения архитектуры. Смог ответить, что такое SDN и ICMP, какие есть файловые системы и каковы недостатки монолитной архитектуры — высылаем оффер, нет — «к сожалению, вы нам не подходите». Все.
В целом я против такой практики найма ничего не имею, она отлично подходит для отбора… стажеров и джунов, чтобы узнать, ходили ли они вообще на пары в универе. Навыки и опыт специалиста уровня мидл и выше никак не коррелируют со знанием этих терминов: ни практической, ни смысловой нагрузки они не несут.
Заучивание этих терминов, типа TCP/IP или DMA, безусловно, важный процесс обучения. Без него будет достаточно сложно понять, как работают сети, файловые хранилища, сервера или операционные системы. Однако в ежедневной работе академические определения едва ли пригодятся, а значит, за ненадобностью забудутся. Сеньор вполне может и не ответить на вопросы — он давно учил терминологию. Значит ли это, что он «купил» грейд? Да нет, конечно.
Лично мне куда было бы интересно узнать, сможет ли кандидат расшифровать dump трафика. Это уже будет намного практичнее: какой смысл, если человек знает, что такое TCP/IP, но не может сказать, что же написано в большом куске dump?
Да и в целом отталкиваться от знаний академических терминов неправильно: интервью должно строиться от потребностей и задач команды. С какими инструментами она работает, что и как автоматизирует. Практический опыт сеньора едва ли соприкасается со списком этих терминов. Кроме того, если интервью начинается с подобных вопросов, то затрудняется взаимопонимание компании и кандидата с большим опытом в принципе: сеньор не сможет оценить состояние компании и масштабность предстоящих задач, а компания оставит скорее негативное впечатление.
Есть ли тогда вообще в этом чек-листе смысл? Да, есть. Когда вам нужно нанять человека на старте — стажера или джуна. Здесь академические знания будут иметь смысл: как минимум они покажут заинтересованность человека в развитии и понимание структуры современных технологий. Но для уже состоявшихся специалистов такой метод отбора не подходит — вы просто не сможете друг друга понять.
Как понять, что собеседование прошло хорошо? Принято считать, что все стороны друг другу понравились. Но для технических специальностей появляется еще один вопрос, который всем нужно задать для оценки интервью: а было ли собеседование технически правильным? К примеру: интервью проходит по упомянутому выше чек-листу и соискатель, предварительно все выучив, с легкостью получает оффер. И, с одной стороны, раз он ответил на эти базовые вопросы, значит, он подходит на должность и вообще — молодец, а с другой — заучив все эти понятия, он может прийти на работу и сломать прод. Дальше встает очевидный вопрос: как же мы так провели собеседование, если на интервью все было хорошо, а на деле человек приходит, радостный, и сразу все сервера ложатся?
Отсюда мы приходим к тому, что такое качественное интервью. Это совместная работа рекрутера и лида (или сеньора), в чью команду идет наем. Технический эксперт здесь знает, как грамотно составить и задать технические вопросы, придумать практический кейс и оценить, подходит ли кандидат по хард-скилам. HR-специалист, учитывая пожелания заказчика по поводу будущего коллеги, должен грамотно подобрать кандидата. Качественное интервью должно включать в себя правильные вопросы, чтобы проанализировать ход мыслей человека и оценить, сможет ли он справиться с нашей практикой, а также профессиональную и, если нужно, психологическую характеристику, чтобы понять, подойдет ли кандидат той или иной команде.
Здесь стоит подробнее остановиться на процессе рекрутмента. Мой достаточно большой опыт поиска сотрудников позволил мне сформировать собственный взгляд на то, каким должно быть взаимодействие HR и лида. Единого пути отбора DevOps нет, это связано со спецификой их работы и набором используемых инструментов: в каких-то проектах упор на Windows, а в других — на Linux; где-то используется оркестрация, а где-то ее нет; где-то идет упор на облачные системы, а где-то работают с «железом».
Прескрин-вопросы должны формироваться под каждый стек отдельно. Поэтому рекрутер должен, во-первых, правильно понять требования к позиции и подобрать нужного кандидата по его резюме, а во-вторых — уметь выявлять реальные знания и навыки кандидата: в резюме можно написать все что угодно.
А для того, чтобы рекрутер мог качественно выполнить свою часть задач, должна быть проведена та самая совместная работа. Перед тем как начать бегать по рынку и искать людей, нам нужно составить:
Последний пункт особенно важен: именно он гарантирует прозрачность процесса. Аргументация в стиле «этого мы взяли, потому что подошел, а того — нет, потому что ну как-то не очень» со стороны, мягко говоря, выглядит странной. Особенно для руководителя выше, который выделяет колоссальные деньги на налаживание этого процесса.
В случае стандартизации технических собеседований протоколирование коммуникаций также позволяет повысить качество найма: различные команды могут обмениваться информацией о кандидате (и в отчетной форме это куда удобнее), и, если он не подойдет в одну команду, например по софт-скилам, его может забрать другая. Кстати, об этих «софт-скилах», во всех их проявлениях, рекрутер должен написать в отчете, особенно если при общении некоторые аспекты поведения соискателя ему показались странными.
Для чего все это нужно? Представим ситуацию, что рекрутер успешно провел прескрин кандидата, резюме его было вполне себе ничего, так что его пригласили на собеседование. Там он на все вопросы ответил правильно, потому что знания имелись. Однако лид не получил от рекрутера никакого фидбэка о его некорректном поведении на прескрине, а на интервью кандидату удалось показать свои знания в тех областях, в которых силен он и которые нужны проекту, а держал при этом он себя по-другому. В итоге кандидату стоило лишь «хорошо и респектабельно себя вести», чтобы получить оффер. Тут уже начинаются проблемы у всей компании, потому что она уже потратила много денег и времени. «Проявил» человек себя только через пару недель, а через месяц уже весь отдел воет от нежелания работать с таким новичком. И мало того что такому человеку надо отказать в работе: необходимо будет проверить все, что он за это время успел натворить, а времени-то уже прошло немало.
Что мы получаем в результате такого смещения обязанностей? Команда какое-то время работала в крайне неблагоприятной атмосфере. Вместо полезной работы время DevOps тратится на ревью «работы» токсика. HR и бухгалтерия уже отправили все его документы по ведомствам, компании нужно заново начинать процесс поиска, и еще куча проблем. Конечно, выше я описал крайнюю ситуацию, далеко не всегда последствия будут такими тяжелыми, но рабочая атмосфера в команде напрямую зависит от совместимости коллег и напрямую влияет на ее продуктивность. Поэтому очень важно грамотно выстроить процессы как общения между рекрутером и лидом, так и подхода к найму в целом, в частности протоколирования.
С другой стороны, могут быть и исключения, которые зависят чаще от лида и от ситуации. У меня, например, как-то был человек, который был очень тяжело совместим со всеми остальными, но он был очень сильным сеньором и технарем. Я понимал, что я, как тимлид, могу его взять, но тогда я должен буду отгораживать его от взаимодействия с его коллегами. И это работало: я его отгораживал и держал в некотором информационном вакууме, не давал ему проявлять свою токсичность в отношении остальных (потому что все контакты вел я), но при этом он работал намного быстрее, нежели любой другой среднестатистический сеньор. Но это все же исключение, и, по-хорошему, стоит подбирать людей, психологически совместимых с командой, с компанией, которые будут более стабильны.
Лайвкодинг — тоже не панацея. Во-первых, он подходит скорее программистам. Во-вторых, это небольшая задача, в которой мы хотим посмотреть, как человек напишет какой-то кусочек алгоритма. Является ли это объективно стрессовой ситуацией? Ну, в целом нет. Потому что, как правило, этот кусочек кода — простая гипотетическая задача, которую просто надо решить. Как правило, за ней не следуют вопросы про последствия применения этого алгоритма. Мы спрашиваем про причины выбора решения.
Я же даже не буду смотреть, как быстро код инженера будет что-то раскатывать, потому что в рамках автоматизации это не имеет значения, у DevOps главное, чтобы все работало. Я могу спросить, почему кандидат выбрал тот или иной алгоритм, почему он считает его лучшим, может ли он ускорить процесс.
Однако я считаю куда более эффективными умственные задачи на расследование. Мне нужно удостовериться, может ли человек установить связь между следствием и причиной, расследовать их. Так я смогу понять, насколько оптимально он сумеет перейти к проблеме в продакшене: умеет ли он банально пользоваться Google. Через эту задачу я прогоняю его алгоритм мышления, оцениваю, как он по этому алгоритму идет и предполагает ли он, какие последствия могут быть.
Для ясности приведу пример из личной практики: есть двастула пода в Kubernetes, они общаются через Интернет, и вдруг один под начал получать какую-то ошибку nginx. Вопрос: почему это происходит и как ты будешь это локализовывать? То есть в одной задаче я даю необычную ситуацию: эти два пода общаются между собой не внутри Kubernetes, а через Интернет. Это значит, что я хочу посмотреть, будет ли он рассматривать различные ингрессы, балансировщики. Я изначально создаю некоторую нестандартную ситуацию, чтобы посмотреть, как человек будет расследовать ситуацию, что он будет предполагать. И это не академический вопрос из разряда «расскажите, как работает под», это именно задача на подумать. Но академические знания здесь также проверяются: размышляя вслух, он покажет, что знает по Kubernetes, трафику, ингрессам и т. д.
Очень многие люди, после того как внедрили что-то впервые в жизни, начинают думать, что это единственный верный способ. Это происходит в том числе потому, что люди, которые пришли после них, не говорят, как плохо и больно это решение выглядит со стороны. Самая большая ошибка эксперта — полагаться на субъективный опыт.
В нашей IT-сфере существует в этом смысле некоторый парадокс: вроде бы мы все делаем одно и то же, а на самом деле в каждой компании всегда все по-новому. Даже несмотря на идентичный стек технологий, реализация решений может быть настолько другой, что потребуется перестраивать весь свой опыт, все свои знания под другое решение, потому что твое здесь работать не будет. Если человек не понимает этого и пытается внедрить свое решение (ведь оно было успешным!) и вдруг почему-то что-то перестает работать, то начинается колоссальная трата времени, денег и очень большая головная боль.
Вообще, каждый год нужно себе задавать один и тот же вопрос, вне зависимости от места работы и проекта: действительно ли мой опыт применим в том же кейсе, который я делал ранее? Чаще всего уже нет. Отдельные решения — может быть, но не целиковое. Особенно в других компаниях, которые по-другому строят свой продукт, у них другая реализация работы с очередями, событийными моделями, данными по клиентам, хотя технологии, скорее всего, те же. Банально у нового работодателя может не быть столько денег, чтобы поддерживать твое решение, если ты решил уйти в стартап, например.
Возникает еще один парадокс: нам нужен опытный сотрудник, но его опыт будет мешать нашей и его работе. Решение есть: даже если это сеньор, нельзя отпускать его в свободное плавание и давать, как говорится, флаг в руки. В компании должна существовать система противовесов. У новоприбывшего сеньора должна быть возможность доказать, что его решение будет лучше, однако для этого ему нужно будет погрузиться в существующую систему, предоставить архитекторам свои расчеты. В общем, он должен понять, на обломках чего он собирается возводить что-то новое и нужно ли это вообще.
В моей практике часто бывало, что некоторые бравые ребята приходили в компании, говорили «щас я вам тут все сделаю». Потом приходил я. Смотрел на все это. Чесал репу. И понимал, что все это больно и дорого и придется все переделывать, потому что их идеи привели к огромным проблемам, безостановочным падениям, конфликтам. Проще и дешевле было бы вообще все эти перестановки не начинать.
Поэтому следующий этап грамотного найма — качественная интеграция нового коллеги. Ему нужно показать все процессы, объяснить традиции, рассказать, как и почему здесь приятно поступать так, а не иначе. Если этого не сделать, человек может пойти сам искать информацию, а все гайды, как правило, на уровне «10 лет назад написали и забыли», а с тех пор уже двадцать раз все поменялось. Очевидно, что на основе этой информации он сделает неправильный вывод. Дальше придется обращаться к огромному количеству людей, которые имеют разрозненный пул информации. Этот процесс будет долгим, и даже не факт, что предоставленная информация будет верна.
Поэтому нужно, чтобы человека именно интегрировали. Такая интеграция будет полезна в том числе и самой компании: если для интеграции одного человека ему надо встретиться еще с двадцатью, то с базой знаний явно что-то не то. Кроме того, если не иметь привычки своевременно обновлять свои базы данных, то сам в один момент запутаешься, что где и как сделано. Особенно, если человек, который разрабатывал какую-то фичу, ушел. Это не значит, что БЗ нужно держать всегда в суперактуальном состоянии, но некоторые фундаментальные вещи, например описание инфраструктуры, HLA, диаграммы развертывания, сетевые карты, должны обновляться по факту изменения. Обязательно также должна быть схема матрицы связей — к кому по какому вопросу обратиться. Отталкиваясь от этого, можно и нужно будет задавать вопросы по рабочим деталям, но этого уже достаточно для понимания, где и почему приложение может сбоить. В итоге получается двойная проверка: компания, с одной стороны, проверяет кандидата, а с другой — процесс найма проверяет саму компанию: как внутри нее налажена коммуникация, поддерживается ли база знаний, работают ли процессы интеграции и системы противовесов «бравых» сеньоров, готовых поставить компанию вверх ногами.
Почему мы вообще начинаем расширять команду? Всегда будет ответ один — нам не хватает рабочих рук, потому что резко прибавилось работы. Но работа как прибавилась, так и убавится: с помощью новых людей, например, все автоматизировали. Встает вопрос, а что с этими людьми теперь делать, раз для поддержки проекта теперь нужно не 50 человек, а 25? Загружать их какими-то ненужными компании (и им самим) тасками? Часто, кстати, так и получается: команда выполняет свою задачу и дальше сидит без дела и без каких-либо перспектив, потому что планы не определились или купить чужое решение руководству кажется выгоднее, чем разрабатывать свое: мы препарировали все это вот тут.
Для того чтобы избежать такой ситуации, нужна предварительная совместная работа лида и его руководителя (или еще выше), то есть человека, который отвечает за техническое и продуктовое планирование в компании и который знает, что в компании будет происходить дальше, какие фичи запланировал бизнес. Например, после разработки и внедрения системы ее планируют развить в MLOps или в DataLake. И вот мы набрали людей, заточенных на автоматизацию, они со своей задачей успешно справились, но для последующих планов их квалификации недостаточно, и не факт, что они смогут эту квалификацию получить. А бизнес хочет в следующем году выпускать что-то большое, крутое и страшное.
Оговорюсь, что такой подход не всегда должен применяться: например, не обязательно рассматривать с заделом на другие проекты кандидатов, которых набирают в продуктовые команды, для аутсорсеров или интеграторов такой подход тоже необязателен. Да и стартапам такой подход ни к чему.
Однако для крупных корпораций просто обязательно рассматривать кандидатов, учитывая их дополнительный опыт или способность переориентироваться с автоматизации на тот же MLOps. Поэтому дальнейшие планы компании должны быть доступны лидам, которые и будут составлять матрицу компетенций для кандидатов. Открытость планов (и вообще их наличие) — обязательный принцип компании. Нанимать людей, чтобы их потом уволить, — ну такое. В «Лаборатории Касперского», кстати, с пониманием относятся к желанию сотрудников перейти из одного проекта в другой, поэтому, если вы хотите поработать как с Linux, так и с нашей собственной микроядерной KasperskyOS, — добро пожаловать к нам в команду. Тем более попасть к нам можно всего лишь за 2–3 дня.
Кстати, возможно, именно я буду вас собесить :)
Итак, каков финальный алгоритм?
Вообще, рецепт грамотного найма DevOps на самом деле прост: это «система мер и весов». Когда мы безостановочно взваливаем ответственность на кого-то одного, забывая о том, что он не является специалистом во всем, то мы сами нарушаем свою систему, вынуждая людей делать больше и делать некачественно. Это касается взаимодействия рекрутера и тимлида, это касается выстраивания процессов внутри компании.
Чаще всего нет четкого разделения зон ответственности, а когда они не прописаны, начинаются большие проблемы и большие затраты. Поэтому, если обобщать все вышесказанное, необходимо создавать «систему мер и весов». Все должны понимать, что за какой-либо процесс отвечает не один человек, а огромное количество людей, поэтому процесс должен быть формализован, понятен, должны быть прописаны границы разделения ответственности и как будут решаться конфликты.
Автор обитает здесь -> tg @happy_devops
Меня зовут Андрей Сухоруков, я DevOps TeamLead в «Лаборатории Касперского». В IT я в общей сложности более 11 лет и в течение карьеры очень часто примерял на себя роль антикризисного лида, разрешая большие проблемы в больших проектах практически во всех отраслях бизнеса: металлургия, банки, госструктуры; был консультантом на аутсорсе. А еще — нанимал и, соответственно, собеседовал. Поэтому отлично знаю, о чем говорю.
Оставьте термины вузам (а лучше вообще их забудьте)
Как будто бы для того, чтобы проверить работоспособность будущего коллеги, достаточно просто задать несколько вопросов из этой хабрастатьи на 75 минут чтения. Грамотность и профессионализм инженера таким образом выяснить достаточно легко, ведь это такая база, без понимания которой невозможен ни один процесс развертывания и тем более построения архитектуры. Смог ответить, что такое SDN и ICMP, какие есть файловые системы и каковы недостатки монолитной архитектуры — высылаем оффер, нет — «к сожалению, вы нам не подходите». Все.
В целом я против такой практики найма ничего не имею, она отлично подходит для отбора… стажеров и джунов, чтобы узнать, ходили ли они вообще на пары в универе. Навыки и опыт специалиста уровня мидл и выше никак не коррелируют со знанием этих терминов: ни практической, ни смысловой нагрузки они не несут.
Заучивание этих терминов, типа TCP/IP или DMA, безусловно, важный процесс обучения. Без него будет достаточно сложно понять, как работают сети, файловые хранилища, сервера или операционные системы. Однако в ежедневной работе академические определения едва ли пригодятся, а значит, за ненадобностью забудутся. Сеньор вполне может и не ответить на вопросы — он давно учил терминологию. Значит ли это, что он «купил» грейд? Да нет, конечно.
Лично мне куда было бы интересно узнать, сможет ли кандидат расшифровать dump трафика. Это уже будет намного практичнее: какой смысл, если человек знает, что такое TCP/IP, но не может сказать, что же написано в большом куске dump?
Да и в целом отталкиваться от знаний академических терминов неправильно: интервью должно строиться от потребностей и задач команды. С какими инструментами она работает, что и как автоматизирует. Практический опыт сеньора едва ли соприкасается со списком этих терминов. Кроме того, если интервью начинается с подобных вопросов, то затрудняется взаимопонимание компании и кандидата с большим опытом в принципе: сеньор не сможет оценить состояние компании и масштабность предстоящих задач, а компания оставит скорее негативное впечатление.
Есть ли тогда вообще в этом чек-листе смысл? Да, есть. Когда вам нужно нанять человека на старте — стажера или джуна. Здесь академические знания будут иметь смысл: как минимум они покажут заинтересованность человека в развитии и понимание структуры современных технологий. Но для уже состоявшихся специалистов такой метод отбора не подходит — вы просто не сможете друг друга понять.
Качество собеседования = качество сотрудников
Как понять, что собеседование прошло хорошо? Принято считать, что все стороны друг другу понравились. Но для технических специальностей появляется еще один вопрос, который всем нужно задать для оценки интервью: а было ли собеседование технически правильным? К примеру: интервью проходит по упомянутому выше чек-листу и соискатель, предварительно все выучив, с легкостью получает оффер. И, с одной стороны, раз он ответил на эти базовые вопросы, значит, он подходит на должность и вообще — молодец, а с другой — заучив все эти понятия, он может прийти на работу и сломать прод. Дальше встает очевидный вопрос: как же мы так провели собеседование, если на интервью все было хорошо, а на деле человек приходит, радостный, и сразу все сервера ложатся?
Отсюда мы приходим к тому, что такое качественное интервью. Это совместная работа рекрутера и лида (или сеньора), в чью команду идет наем. Технический эксперт здесь знает, как грамотно составить и задать технические вопросы, придумать практический кейс и оценить, подходит ли кандидат по хард-скилам. HR-специалист, учитывая пожелания заказчика по поводу будущего коллеги, должен грамотно подобрать кандидата. Качественное интервью должно включать в себя правильные вопросы, чтобы проанализировать ход мыслей человека и оценить, сможет ли он справиться с нашей практикой, а также профессиональную и, если нужно, психологическую характеристику, чтобы понять, подойдет ли кандидат той или иной команде.
Здесь стоит подробнее остановиться на процессе рекрутмента. Мой достаточно большой опыт поиска сотрудников позволил мне сформировать собственный взгляд на то, каким должно быть взаимодействие HR и лида. Единого пути отбора DevOps нет, это связано со спецификой их работы и набором используемых инструментов: в каких-то проектах упор на Windows, а в других — на Linux; где-то используется оркестрация, а где-то ее нет; где-то идет упор на облачные системы, а где-то работают с «железом».
Прескрин-вопросы должны формироваться под каждый стек отдельно. Поэтому рекрутер должен, во-первых, правильно понять требования к позиции и подобрать нужного кандидата по его резюме, а во-вторых — уметь выявлять реальные знания и навыки кандидата: в резюме можно написать все что угодно.
А для того, чтобы рекрутер мог качественно выполнить свою часть задач, должна быть проведена та самая совместная работа. Перед тем как начать бегать по рынку и искать людей, нам нужно составить:
- Матрицу компетенций, которые мы хотим видеть у человека. Это должен быть бумажный документ, от которого будет строиться весь дальнейший процесс найма.
- Шаблон отчетов: и нанимающий, и рекрутер должны понимать, в каком виде они предоставят друг другу отчет о кандидате.
Последний пункт особенно важен: именно он гарантирует прозрачность процесса. Аргументация в стиле «этого мы взяли, потому что подошел, а того — нет, потому что ну как-то не очень» со стороны, мягко говоря, выглядит странной. Особенно для руководителя выше, который выделяет колоссальные деньги на налаживание этого процесса.
В случае стандартизации технических собеседований протоколирование коммуникаций также позволяет повысить качество найма: различные команды могут обмениваться информацией о кандидате (и в отчетной форме это куда удобнее), и, если он не подойдет в одну команду, например по софт-скилам, его может забрать другая. Кстати, об этих «софт-скилах», во всех их проявлениях, рекрутер должен написать в отчете, особенно если при общении некоторые аспекты поведения соискателя ему показались странными.
Для чего все это нужно? Представим ситуацию, что рекрутер успешно провел прескрин кандидата, резюме его было вполне себе ничего, так что его пригласили на собеседование. Там он на все вопросы ответил правильно, потому что знания имелись. Однако лид не получил от рекрутера никакого фидбэка о его некорректном поведении на прескрине, а на интервью кандидату удалось показать свои знания в тех областях, в которых силен он и которые нужны проекту, а держал при этом он себя по-другому. В итоге кандидату стоило лишь «хорошо и респектабельно себя вести», чтобы получить оффер. Тут уже начинаются проблемы у всей компании, потому что она уже потратила много денег и времени. «Проявил» человек себя только через пару недель, а через месяц уже весь отдел воет от нежелания работать с таким новичком. И мало того что такому человеку надо отказать в работе: необходимо будет проверить все, что он за это время успел натворить, а времени-то уже прошло немало.
Что мы получаем в результате такого смещения обязанностей? Команда какое-то время работала в крайне неблагоприятной атмосфере. Вместо полезной работы время DevOps тратится на ревью «работы» токсика. HR и бухгалтерия уже отправили все его документы по ведомствам, компании нужно заново начинать процесс поиска, и еще куча проблем. Конечно, выше я описал крайнюю ситуацию, далеко не всегда последствия будут такими тяжелыми, но рабочая атмосфера в команде напрямую зависит от совместимости коллег и напрямую влияет на ее продуктивность. Поэтому очень важно грамотно выстроить процессы как общения между рекрутером и лидом, так и подхода к найму в целом, в частности протоколирования.
С другой стороны, могут быть и исключения, которые зависят чаще от лида и от ситуации. У меня, например, как-то был человек, который был очень тяжело совместим со всеми остальными, но он был очень сильным сеньором и технарем. Я понимал, что я, как тимлид, могу его взять, но тогда я должен буду отгораживать его от взаимодействия с его коллегами. И это работало: я его отгораживал и держал в некотором информационном вакууме, не давал ему проявлять свою токсичность в отношении остальных (потому что все контакты вел я), но при этом он работал намного быстрее, нежели любой другой среднестатистический сеньор. Но это все же исключение, и, по-хорошему, стоит подбирать людей, психологически совместимых с командой, с компанией, которые будут более стабильны.
Как же должно проходить техническое интервью у DevOps
Лайвкодинг — тоже не панацея. Во-первых, он подходит скорее программистам. Во-вторых, это небольшая задача, в которой мы хотим посмотреть, как человек напишет какой-то кусочек алгоритма. Является ли это объективно стрессовой ситуацией? Ну, в целом нет. Потому что, как правило, этот кусочек кода — простая гипотетическая задача, которую просто надо решить. Как правило, за ней не следуют вопросы про последствия применения этого алгоритма. Мы спрашиваем про причины выбора решения.
Я же даже не буду смотреть, как быстро код инженера будет что-то раскатывать, потому что в рамках автоматизации это не имеет значения, у DevOps главное, чтобы все работало. Я могу спросить, почему кандидат выбрал тот или иной алгоритм, почему он считает его лучшим, может ли он ускорить процесс.
Однако я считаю куда более эффективными умственные задачи на расследование. Мне нужно удостовериться, может ли человек установить связь между следствием и причиной, расследовать их. Так я смогу понять, насколько оптимально он сумеет перейти к проблеме в продакшене: умеет ли он банально пользоваться Google. Через эту задачу я прогоняю его алгоритм мышления, оцениваю, как он по этому алгоритму идет и предполагает ли он, какие последствия могут быть.
Для ясности приведу пример из личной практики: есть два
Опыт вредит эксперту
Очень многие люди, после того как внедрили что-то впервые в жизни, начинают думать, что это единственный верный способ. Это происходит в том числе потому, что люди, которые пришли после них, не говорят, как плохо и больно это решение выглядит со стороны. Самая большая ошибка эксперта — полагаться на субъективный опыт.
В нашей IT-сфере существует в этом смысле некоторый парадокс: вроде бы мы все делаем одно и то же, а на самом деле в каждой компании всегда все по-новому. Даже несмотря на идентичный стек технологий, реализация решений может быть настолько другой, что потребуется перестраивать весь свой опыт, все свои знания под другое решение, потому что твое здесь работать не будет. Если человек не понимает этого и пытается внедрить свое решение (ведь оно было успешным!) и вдруг почему-то что-то перестает работать, то начинается колоссальная трата времени, денег и очень большая головная боль.
Вообще, каждый год нужно себе задавать один и тот же вопрос, вне зависимости от места работы и проекта: действительно ли мой опыт применим в том же кейсе, который я делал ранее? Чаще всего уже нет. Отдельные решения — может быть, но не целиковое. Особенно в других компаниях, которые по-другому строят свой продукт, у них другая реализация работы с очередями, событийными моделями, данными по клиентам, хотя технологии, скорее всего, те же. Банально у нового работодателя может не быть столько денег, чтобы поддерживать твое решение, если ты решил уйти в стартап, например.
Возникает еще один парадокс: нам нужен опытный сотрудник, но его опыт будет мешать нашей и его работе. Решение есть: даже если это сеньор, нельзя отпускать его в свободное плавание и давать, как говорится, флаг в руки. В компании должна существовать система противовесов. У новоприбывшего сеньора должна быть возможность доказать, что его решение будет лучше, однако для этого ему нужно будет погрузиться в существующую систему, предоставить архитекторам свои расчеты. В общем, он должен понять, на обломках чего он собирается возводить что-то новое и нужно ли это вообще.
В моей практике часто бывало, что некоторые бравые ребята приходили в компании, говорили «щас я вам тут все сделаю». Потом приходил я. Смотрел на все это. Чесал репу. И понимал, что все это больно и дорого и придется все переделывать, потому что их идеи привели к огромным проблемам, безостановочным падениям, конфликтам. Проще и дешевле было бы вообще все эти перестановки не начинать.
Поэтому следующий этап грамотного найма — качественная интеграция нового коллеги. Ему нужно показать все процессы, объяснить традиции, рассказать, как и почему здесь приятно поступать так, а не иначе. Если этого не сделать, человек может пойти сам искать информацию, а все гайды, как правило, на уровне «10 лет назад написали и забыли», а с тех пор уже двадцать раз все поменялось. Очевидно, что на основе этой информации он сделает неправильный вывод. Дальше придется обращаться к огромному количеству людей, которые имеют разрозненный пул информации. Этот процесс будет долгим, и даже не факт, что предоставленная информация будет верна.
Поэтому нужно, чтобы человека именно интегрировали. Такая интеграция будет полезна в том числе и самой компании: если для интеграции одного человека ему надо встретиться еще с двадцатью, то с базой знаний явно что-то не то. Кроме того, если не иметь привычки своевременно обновлять свои базы данных, то сам в один момент запутаешься, что где и как сделано. Особенно, если человек, который разрабатывал какую-то фичу, ушел. Это не значит, что БЗ нужно держать всегда в суперактуальном состоянии, но некоторые фундаментальные вещи, например описание инфраструктуры, HLA, диаграммы развертывания, сетевые карты, должны обновляться по факту изменения. Обязательно также должна быть схема матрицы связей — к кому по какому вопросу обратиться. Отталкиваясь от этого, можно и нужно будет задавать вопросы по рабочим деталям, но этого уже достаточно для понимания, где и почему приложение может сбоить. В итоге получается двойная проверка: компания, с одной стороны, проверяет кандидата, а с другой — процесс найма проверяет саму компанию: как внутри нее налажена коммуникация, поддерживается ли база знаний, работают ли процессы интеграции и системы противовесов «бравых» сеньоров, готовых поставить компанию вверх ногами.
Понимание потребностей компании в навыках
Почему мы вообще начинаем расширять команду? Всегда будет ответ один — нам не хватает рабочих рук, потому что резко прибавилось работы. Но работа как прибавилась, так и убавится: с помощью новых людей, например, все автоматизировали. Встает вопрос, а что с этими людьми теперь делать, раз для поддержки проекта теперь нужно не 50 человек, а 25? Загружать их какими-то ненужными компании (и им самим) тасками? Часто, кстати, так и получается: команда выполняет свою задачу и дальше сидит без дела и без каких-либо перспектив, потому что планы не определились или купить чужое решение руководству кажется выгоднее, чем разрабатывать свое: мы препарировали все это вот тут.
Для того чтобы избежать такой ситуации, нужна предварительная совместная работа лида и его руководителя (или еще выше), то есть человека, который отвечает за техническое и продуктовое планирование в компании и который знает, что в компании будет происходить дальше, какие фичи запланировал бизнес. Например, после разработки и внедрения системы ее планируют развить в MLOps или в DataLake. И вот мы набрали людей, заточенных на автоматизацию, они со своей задачей успешно справились, но для последующих планов их квалификации недостаточно, и не факт, что они смогут эту квалификацию получить. А бизнес хочет в следующем году выпускать что-то большое, крутое и страшное.
Оговорюсь, что такой подход не всегда должен применяться: например, не обязательно рассматривать с заделом на другие проекты кандидатов, которых набирают в продуктовые команды, для аутсорсеров или интеграторов такой подход тоже необязателен. Да и стартапам такой подход ни к чему.
Однако для крупных корпораций просто обязательно рассматривать кандидатов, учитывая их дополнительный опыт или способность переориентироваться с автоматизации на тот же MLOps. Поэтому дальнейшие планы компании должны быть доступны лидам, которые и будут составлять матрицу компетенций для кандидатов. Открытость планов (и вообще их наличие) — обязательный принцип компании. Нанимать людей, чтобы их потом уволить, — ну такое. В «Лаборатории Касперского», кстати, с пониманием относятся к желанию сотрудников перейти из одного проекта в другой, поэтому, если вы хотите поработать как с Linux, так и с нашей собственной микроядерной KasperskyOS, — добро пожаловать к нам в команду. Тем более попасть к нам можно всего лишь за 2–3 дня.
Кстати, возможно, именно я буду вас собесить :)
Заключение
Итак, каков финальный алгоритм?
- Лид идет «наверх» и узнает о дальнейших планах компании.
- Рекрутер и эксперт вдвоем составляют портрет (по хард- и софт-скилам) кандидата и шаблон отчета.
- На интервью у кандидата проверяется его ход мышления, умение решать нетипичные задачи (и ни в коем случае не спрашивается определение TCP/IP(!!!)).
- Нанимающий и HR обмениваются мнениями о собеседовании в отчетном виде.
- Если все всем довольны, нового коллегу интегрируют в компанию, предоставляя ему доступ к актуальной БЗ и знакомя его со всеми процессами и их причинами.
Вообще, рецепт грамотного найма DevOps на самом деле прост: это «система мер и весов». Когда мы безостановочно взваливаем ответственность на кого-то одного, забывая о том, что он не является специалистом во всем, то мы сами нарушаем свою систему, вынуждая людей делать больше и делать некачественно. Это касается взаимодействия рекрутера и тимлида, это касается выстраивания процессов внутри компании.
Чаще всего нет четкого разделения зон ответственности, а когда они не прописаны, начинаются большие проблемы и большие затраты. Поэтому, если обобщать все вышесказанное, необходимо создавать «систему мер и весов». Все должны понимать, что за какой-либо процесс отвечает не один человек, а огромное количество людей, поэтому процесс должен быть формализован, понятен, должны быть прописаны границы разделения ответственности и как будут решаться конфликты.
Автор обитает здесь -> tg @happy_devops
