Как проводить собеседование на позицию DevOps-Engineer. И как готовиться к нему

Всем привет! Меня зовут Антон, я DevOps-инженер в MacPaw, экс-сотрудник Swiftype (an Elastic company), Grammarly, Bigmir.net. За 10 лет в ИТ я успел побывать в мире VoIP-хаоса, FreeBSD-сект, тимлидства, MacOS-разработки (со стороны DevOps), стандартного веба. Минимум половину своей карьеры мне приходилось собеседовать людей, поэтому с опытом я выработал для себя некие правила и чекпоинты, которыми и хотел бы сегодня с вами поделиться.

Статья будет полезна техническим специалистам, которые проводят интервью в стиле «как карта ляжет» или понадеявшись на импровизацию. Особенно для тех, кто проводит интервью на роли DevOps/SRE Engineer, преимущественно для уровней middle, senior, TL.

Хотел бы отметить, что мой карьерный путь проходил только по продуктовым компаниям, поэтому, вероятно, кое-что из написанного может отличаться в мире аутсорса.

Сломанный процесс

Что не так? Я бы хотел начать с того, что немного поворчуя часто встречал поломанные процессы интервью в разных компаниях! И это даже не затрагивая моменты, когда интервью превращается в прогревание своего ЧСВ.

Что такое inode? Разница между Apache и Nginx? Что произойдет, если я нажму Tab-Tab? Как часто, будучи в роли кандидата, вы слышали подобные вопросы? И как часто вы делали мысленный фейспалм на них? Высока вероятность, что ваш собеседник просто загуглил список вопросов «Linux System Administrator/DevOps Interview Questions», который вы даже когда-то скролили, попивая пивко вечером, но вряд ли запомнили все ответы. В итоге проверили вашу память, и, в лучшем случае, немного знаний.

Что делать, если вы собеседующий

Готовиться к интервью! Да, с вашей стороны это не менее важно, чем со стороны кандидата. У вас должен быть список вопросов, ответы на которые помогут вам понять, насколько ценным будет опыт человека для текущей компании.

Не надо так

Это очень важный блок! Перечитайте его дважды, даже, если вы не относитесь к DevOps. Не нужно спрашивать:

• Как бы кандидат разруливал сложности «прогонки» 10 Tbit/s на FreeBSD, потому что это прикольная история, которую рассказал сосед по общаге в 2005.
• Про межпланетный интернет. Да-да, такой проект существует, и правда интересно обсудить, как он работает. Но прочтите ниже блок «Поведенческие моменты» и поговорите об этом с будущим коллегой в пабе ;)
• О чем сами узнали только вчера. То, что кандидат ничего не знает из недавних changelogs, ни о чем не говорит. Не все мы ноулайферы.
• О том, чего у вас нет в компании. Вы планируете когда-то использовать Kafka? Нет? Вот и не нужно спрашивать!
• Специфический опыт, который доступен тем, кто строил какой-то левый хостинг, но денег у вас не было, и вы извращались как могли, и познали дзен! Туда же VoIP, CI/CD on MacOS/Windows и подобное! Само собой, только если это не требуется от позиции.
• Что делает вот тот ресурс в Chef и почему DSL там сработает так, а не иначе? Впрочем, если у вас колбаса самописного шефа и самописные LWRP, которые надо будет редактировать, то вопрос может быть и правильным.
• Не задавайте вопросы, на которые можно ответить первой строкой из описания в «Википедии». Такие вопросы не помогают понять, сможет ли человек делать конкретную работу. Один мой друг жаловался, что не может проходить собеседования, так как не знает все о HAProxy, о Postgres, да еще и про MongoDB. Я посоветовал заучивать первые предложения из описаний, и количество пройденных интервью возросло.
  
  • Вы знаете, что такое риак?
  • Ну, это распределенный KV датастор, как Динамодб.
  • А, ну ок!

Let’s talk about real systems

Задавайте открытые вопросы, в которые можно углубляться. Если вы не знаете таких вопросов, то возьмите вопросы, которые вам близки, и умножайте нагрузку, пользователей, rps в X2-X5-X1000 раз.

Пример открытого вопроса:

Опиши шаги, необходимые для построения приложения с автоскейлингом в AWS. Далее это позволит вам развивать тему максимально глубоко, в зависимости от вашего опыта и опыта вашего собеседника:

• А если мы хотим использовать Spot Instances, что изменится?
• ALB или NLB?
• Мы же уже на Spot? Zero downtime shutdown, как?
• MySQL master-master, master-slave, автоматическое переключение, как?
• Зашивать код в AMI? Идет в разрез с системой деплоймента? Как можно по-другому? Или триггерить билд на конкретный инстанс? А чтобы не деплоить на всех в группе при этом?
• Куда будем класть сикреты?
• А если у нас часть инфраструктуры в другом облаке или до сих пор на bare-metal? VPN? Хм...

Пример вопроса с «умножением»:

У нас есть Data Pipeline: ALB-Nginx-Python-RabbitMQ-Some_Workers-S3-Hadoop-Whatever. Система хорошо работает при количестве запросов X1, но при X2 начинает скапливаться очередь, где может быть проблема, что делать?

• При X5 nginx начинает выдавать 502, что не так и куда смотреть? Трейсинг, интересно?
• При X20 опять очередь, и наш реалтайм процессинг уже совсем не похож на реалтайм.
• У нас прилетело Х100, реббит упал, и потерял все данные? План по High Availability, как это будет выглядеть, сколько чего добавляем, а если опять чертов Spot? А как быть с остальными частями системы?
• Kubernetes? Отлично, давай поговорим, как будет выглядеть вся система?
• Мы же не забываем все это замониторить и читать логи, CI/CD? А как, откуда кто куда пишет и т.д.

Troubleshooting + hands-on

Это все отлично, скажете вы, но как же мне работать с человеком, который не знает, что такое LA или всех флагов lsof на память?

Нет, конечно, никто вам не запретит опять скатиться в «Apache vs Nginx». Но лучше сами немного подготовьтесь, сделайте виртуалку, сломайте в ней что-нибудь и дайте своему собеседнику. Эта часть займет у вас минут 5-7,но закроет очень много скучных вопросов. Заодно можно узнать что-то новое.

Deep dive

Если вам интересно узнать, например, как работает GTID в MySQL, то воспользуйтесь советами из блока «Let’s talk about real systems» и подведите к этому в обсуждении про увеличение нагрузки. То же самое с сетями, конфиг-менеджментами и т. д. Не стоит спрашивать подобные вопросы, ни к чему не привязываясь. Человек не в контексте, а вы такие бац! А как ElasticSearch делает flush-commit под капотом? И тут судорожно приходится вспоминать что-то про Lucene, что приведет к неловким попыткам выдать хоть что-нибудь.

Программирование и тестирование

Программирование, как английский, должно быть by default. А вот на каком уровне — это очень холиварный вопрос. Имхо, чем чаще вы пишете код для повседневных задач, тем лучше.

Здесь нужно учитывать нюанс, что инфраструктурные вещи, как правило, отличаются от CRUD, например. Поэтому, самое худшее, что можно придумать — это позвать проверить эту часть программиста. Я даже помню (но не буду вслух) одну украинскую компанию, которая просила от DevOps-инженера алгоритмы, структуры данных и вот это вот все.

Понимая под какие задачи вы пишете код, можно подготовить правильные вопросы или тестовое. Например, вам по задачам достаточно только bash и прочий sh. Даем вот такой кусок лога Nginx:

host=setapp.com remote_addr=134.21.127.86 request="GET /v4/customer?access_token=lol HTTP/1.1" status=200 bytes_sent=813 user_agent="Setapp/1.18.2 CFNetwork/974.1 Darwin/18.0.0 (x86_64)" request_length=385 request_time=0.078 upstream_time=0.078 request_id=47f01df614e6c777d88270417c9ac871
host=setapp.com remote_addr=134.21.127.86 request="POST /v4/apns_token HTTP/1.1" status=204 bytes_sent=454 user_agent="Setapp/1.18.5 CFNetwork/974.1 Darwin/18.0.0 (x86_64)" request_length=655 request_time=0.081 upstream_time=0.074 request_id=9174d3b3712c4fd1e93696457f255439
host=setapp.com remote_addr=99.59.88.166 request="GET /v5/token/lol HTTP/1.1" status=200 bytes_sent=910 user_agent="Setapp/1.18.5 CFNetwork/975.0.3 Darwin/18.2.0 (x86_64)" request_length=371 request_time=0.011 upstream_time=0.011 request_id=d51d8230b753f5c9ac5fe31f4d1279a3

И просим вывести только IP-адреса, затем убрать из вывода remote_addr=, а после отсортировать, вывести топ повторяющихся IP, удалить дубликаты и т. д. Набросать подобных и более сложных задачек из жизни по bash совсем не сложно.

Идем дальше. Кандидат знает Python, Ruby, Go? Попросите сделать такой же парсинг лога, только на любимом ЯП. Хочу отметить, что во время интервью, под стрессом, скорее всего, мало кто справится со следующими просьбами, и для их выполнения может понадобиться несколько часов или больше. Скажу честно, что сам довольно редко просил делать тестовое, однако вы можете всегда иметь заготовки под рукой. Адекватно оценивайте количество времени, которое кандидат будет готов потратить на тестовое задание ради вашей компании на данном этапе.

Еще примеры:

• Написать CLI программу, которая будет парсить JMX и высчитывать процент или частоту запуска GC.
• Программу, которая сможет принять вебхук, распарсить json и, используя готовые библиотеки, отправить ключевые значения в Slack или в Jenkins API.
• Написать какой-то «кукбук» для Chef/Puppet — тоже вариант. Ansible? Скажи что-нибудь по YAMLовски :)

К сожалению или к счастью, 99% задач по написанию кода в этой профессии сводятся к подобному.

Хотел было что-то добавить про написание k8s operators, но голос разума подсказал, что это оверкил. Скорее всего, нужно будет готовиться к подобному в недалеком будущем, но пока я и сам не сталкивался с такими заданиями на интервью.

Тестирование тоже желательно должно быть. Не буду долго тут расписывать, но, если кандидат когда-то имел опыт с inspecили подобным, то это уже хорошо! Умеет и писал тесты к своему коду — отлично!

Поведенческие моменты

Я не предлагаю спрашивать о том, кем вы себя видите через 5 лет! Скорее, о чем-то, что может быть важным для вашей команды или компании. Очень простой и банальный пример, когда вы решили внедрить, ну я не знаю, blameless postmortems, а перед вами типичный злой сисадминхейтер всего и всех. Также можно расспросить, работал ли человек в команде, как принимали решения о внедрении чего-то нового. Это покажет, работал ли он с другими людьми и есть ли вообще опыт принятия решений с кем-то вместе.

Если у кандидата были ограничения в прошлых компаниях, в тулах, деньгах, чем угодно, то я обычно прошу рассказать, что бы он изменил в процессах, если бы ему эти ограничения сняли.

Часто в нашей работе приходится сталкиваться с tradeoff между быстрым «подставлю костыль» и сделаю правильно. Как решить, когда выбирать первое, а когда второе? Иногда аргументация очень интересная для обоих вариантов и базируется на прошлом опыте.

Один из моих любимых вопросов: если бы мы с тобой поменялись местами, то что бы ты у меня спрашивал? Как по технической части, так и в целом? Чтобы тебе было важно выяснить обо мне?

Доводилось ли тебе быть «евангелистом»? Как ты доносил (бы) людям идею изменений какого-либо процесса или технической части в продукте, команде?

Подумайте какого типа вам нужен новый коллега: инноватор, или хороший исполнитель, или кто-то другой. В зависимости от этого выстраивайте диалог в этом блоке. Например, можно спросить, насколько человеку комфортно залазить в чужие области ответственности, при необходимости. Какую роль он хотел бы попробовать, если бы у него была возможность безболезненного возврата на текущую?

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

London is the capital of Great Britain

Не проверяйте английский у кандидатов на техническом собеседовании, это задача HR. Более того, когда интервьюер начинает «лет ми спик фром май харт» с целью проверить ваш английский, то выглядит это очень так себе. Плюс на интервью все и так стрессуют и иногда забывают ответы на банальные вопросы, а на английском можно вообще ненароком кандидата прибить.

Фидбэк после интервью

Для HR

В 100% случаев HR будет просить у вас фидбэк. За варианты «норм» или «не катит» HR заносят вас в список на аннигиляцию в случае восстания машин. Поэтому старайтесь, не откладывая, сразу после интервью написать свои мысли о кандидате. Если вам это сложно, то попробуйте делать пометки в процессе общения, только обязательно предупредите об этом собеседника. Фидбэк HR нужен не из вредности, а потому, что HR в идеале хочет хорошо делать свою работу и поддерживать как свою репутацию, так и компании.

Вспомните, как часто на DOU мелькают недовольные отзывы кандидатов «Все было хорошо, но потом HR так и не перезвонил и не дал фидбэка». Но HR не было на собеседовании с вами, скорее всего, и поэтому нельзя просто взять и придумать фидбэк самостоятельно. Кандидат уделил время нам, и мы проявляем к нему уважение, не просто говоря «Прости, ты не подходишь нам», а объясняя, почему именно и где уже хорошо, а над чем еще стоит поработать.

Для кандидата напрямую

Тут нужно быть осторожным, так как ненамеренно можно и обидеть человека, и оставить плохую ассоциацию с компанией! У меня был случай, когда я выдал человеку аккуратное «слабенько с AWS», а он оказался каким-то там трижды сертифицированным по AWS. Было неудобно. C тех пор я стараюсь показать свой отзыв кому-то из коллег и конкретизировать: «Не хватило знаний с такой-то и такой-то штукой в AWS».

В большинстве случаев человек сам способен провести ретроспективу и понять, где он плавал, а где был силен. Но, если речь явном запросе «что бы почитать?», то вам же несложно накидать список хороших книг, WebOps/DevOps/SRE Weekly и дать ссылочку на UkrOps Slack, правда?

Послесловие

В конце хотелось бы обобщить важное:

• Готовьтесь к интервью независимо от того, на какой вы будете стороне.
• Не превращайте интервью в сценку «Я здесь самый крутой чувак!».
• Не делайте из интервью экзамен, их, вроде, и в универе должно было хватить :)
• Выбирайте себе коллегу, а не набор чекпоинтов напротив нужных скиллов.