Собеседование на должность старшего ML-инженера

Originally posted @ alexandruburlacu.github.io/posts/2022-07-23-senior-ml-interview

Собеседование — это всегда утомительный и порой неловкий процесс. К счастью, в Интернете есть множество ресурсов, которые помогут вам подготовиться. Но что если вам нужен более конкретный совет для более нишевой должности?

Этот пост основан на моем личном опыте прохождения собеседований в 5 компаниях, не относящихся к FAANG. В прошлом году у меня также был опыт прохождения собеседований на должности ML-инженеров не высшего звена еще в трех компаниях. Поэтому я также проведу сравнительный анализ.

Прежде чем мы начнем…

Позвольте мне начать с небольшого пролога, чтобы объяснить, почему я пишу эту статью. В январе 2022 года я снова решил, что пришло время искать другую работу за пределами моей родной страны. Но на этот раз я решил быть хитрым/умным, поэтому я изменил свой адрес в LinkedIn, чтобы показать, что я нахожусь в Лондоне. Я также немного подправил свою страницу LinkedIn, чтобы показать некоторые основные моменты моего недавнего опыта. И тут случилось волшебство. В течение нескольких недель рекрутеры приглашали меня на собеседования. Мне даже не пришлось ни к чему стремиться, только принимать или отклонять поступающие от рекрутеров предложения. Что меня удивило, так это то, что большинство вариантов были старшими или даже ведущими должностями. Поэтому я чувствовал себя как самозванец, но все же согласился на несколько из них и начал процесс. А потом я искал советы о том, как пройти собеседование на старших должностях в области ML-инженерии… и не нашел почти ничего. Ни-че-го. И вот так я встретил твою маму и решил написать этот пост в блоге.

Я оттачивал свои навыки проведения собеседований с помощью макетов. Я также искал технические вопросы для ролей Senior ML. Удивительно, но я ничего не смог найти. Вся информация была только для ролей MLE. Это казалось немного странным. Теперь, оглядываясь назад, я понимаю, что все это имеет смысл.

Я знаю, что вам не терпится узнать, почему, поэтому я просто расскажу TL;DR сразу — ML и Senior ML имеют более или менее одинаковую сложность/трудность технических вопросов. Сюрприз!

Держу пари, вы этого не ожидали. Я знаю, что не ожидал. Но что же тогда отличается? И как проходит процесс собеседования для старших ML-инженеров?

Старшие и нестаршие ML-инженеры

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

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

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

Одна из должностей, для которой я заметил значительные различия, когда дело доходит до технических вопросов, — это инженер-исследователь. Я имею в виду такие вопросы, как, например, как JPEG сжимает изображения, как вычислить n-го Фибоначчи за время O(log n) или как вычислить PCA с нуля. Теперь, для должности инженера-исследователя, такие вопросы действительно имеют смысл из-за инновационного и исследовательского характера проектов, над которыми им приходится работать. Они часто могут включать в себя множество задач типа «конвертируй математику в код» или «давайте сломаем и улучшим».

В любом случае, чтобы дать вам более детальное представление, давайте посмотрим, каков общий процесс собеседования, когда речь идет о подобных ролях.

Общий ход собеседования

Во-первых, давайте рассмотрим основные этапы этого процесса. Как правило, существует не менее 4 этапов:

1. Вы проводите первый разговор с рекрутером или менеджером по подбору персонала. Вы знакомитесь, просматриваете свое резюме в целом, обсуждаете, что заставляет вас искать работу или принимать приглашения на интервью, что вы знаете о компании, что вы ищете и так далее. Довольно простой шаг, как по мне. Затем, предположим, менеджер по найму считает, что ваши цели и интересы совпадают с тем, что ищет компания. В этом случае вас пригласят на второй, технический этап. Самый страшный.
2. Я не зря называю этот этап просто техническим. Некоторые компании делят его на две части: задание на дом и затем обсуждение на его основе. Другие проводят типичное собеседование по кодированию. А другие просто проводят техническую дискуссию. Техническое обсуждение обычно охватывает теорию ML и некоторые специфические вопросы, например, что такое трансфертное обучение или что такое трансформаторные архитектуры. Это также может быть упражнение с ручкой и бумагой, где вас могут попросить сделать вывод о том, как работает PCA. Последнее более характерно для ролей, ориентированных на исследования.
3. Чаще всего проводится два технических собеседования, второе из которых больше направлено на собеседование по проектированию системы. Или может быть несколько более технических задач и обсуждений, YMMV, потому что это очень специфично для компании и команды.
4. Наконец, последний раунд собеседования обычно предназначен для всего остального, что не было охвачено на предыдущих этапах, обычно это собеседование по поведению. Некоторые компании проводят три раунда, совмещая 3-й этап с 4-м.

Теперь давайте погрузимся в детали.

1-е собеседование

Довольно простое. Обязательно узнайте о компании, даже если вас пригласили на собеседование. На этом этапе компания, занимающаяся поиском кандидатов, преследует несколько целей:

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

Но не обольщайтесь, даже на этом этапе существует вероятность неудачи. Например, если рекрутер считает, что вы не заинтересованы в данной должности, или если ваши карьерные планы не совпадают с обязанностями данной должности.

2-е/3-е собеседование

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

Племя «взять домой — назначить».

Взять домой — либо решение, обслуживающее ML, либо EDA + моделирование. Никто не будет ожидать от вас надежного, готового к производству решения для проекта ML-сервиса, как и никто не будет жаловаться, что в вашем блокноте Jupyter нет модели SotA ML для данного набора данных. Основное внимание уделяется качеству кода, наличию тестов и функций, простоте выполнения кода для первых, и воспроизводимости и обоснованности решения для вторых.

Сосредоточьтесь на качестве, а не на количестве. Хороший способ продемонстрировать профессионализм — задать уточняющие вопросы после получения задания. И, пожалуйста, внимательно прочитайте его. Слишком часто я видел, как люди делают все неправильно и даже не удосуживаются проверить точные ограничения для домашнего задания.

«Претенденты на кодирование»

Об этом было сказано слишком много. Я считаю, что стоит повторить один момент: как важно на самом деле проговаривать процесс решения проблемы и задавать уточняющие вопросы. Я бы сказал, что это может быть даже важнее, чем решение проблемы. Также не забывайте о следующем:

• Спросить о возможных крайних случаях и затем рассказать о них.
• Объяснить временную и пространственную сложность вашего решения.
• Если у вас есть время, дополнительные очки за то, что вы пройдете через свой код «в стиле отладчика». То есть, шаг за шагом, рассказывая при этом, каковы текущие значения всех ваших переменных.

«Технические дискуссанты»

Обсуждение с командой инженеров. Обычно это происходит следующим образом: Technical/ML Trivia + NotSoOptional[ML System Design] + Optional[Behavioral]. Вопросы ML в основном состоят из:

• «Как бы вы поступили со сценарием X»
• «Что такое Y? Как это работает?».
• Изредка, для ролей, связанных с исследованиями — «Не могли бы вы вычислить Z с нуля, вот Google Doc», в качестве продолжения предыдущих вопросов.

Где $$ Y in {BatchNorm, DropOut, SkipConnections, DataAugmentation, SGD, Transformers, Attention, et al.} $$
$$ Z in {PCA, линейная регрессия, kNN, kMeans} $$.

Иногда технические дискуссии принимают более близкий к ML-системе дизайн.

Это COVID, поэтому проектирование системы обычно только устное, если только вы не можете нарисовать решение в текстовом виде, поделившись своим экраном. Псевдокод также помогает.
ML System Design, похоже, ничем не отличается. Это все еще один из вариантов «Разработайте поисковую систему для X» или «Как вы собираетесь разработать систему X-which-is-actually-a-recommender-system».

---------   r/w  ----------    ----------   HTTP/2
|  DB   | <------| API    |<-- | NGINX  |  <-------  Client
|       |        |        |    ---------- 
---------        ----------

                                 /-------> Users Service --> MySQL
                                /
Client w/ Browser Cache ---> Gateway -----> Posts Service  --> Cassandra x 6
                                                |                 write_to: 2
                                              Redis               read_from: 1

Дополнительные баллы за обсуждение эффективности/бюджета/бизнес-соображений на этом этапе. Например, предложение разделить приложение на две части: логика ML на машине с GPU, а бизнес-логика на более обычном сервере. Или размышления вслух о решении «купить или собрать» в отношении какого-либо компонента.

Некоторые личные мнения

Я предпочитаю домашние проекты + технические дискуссии. Такая комбинация делает техническую дискуссию более содержательной. Она позволяет кандидату выразить свои идеи о том, как должна быть спроектирована правильная производственная система на основе домашнего задания. Кроме того, хороший домашний проект может подчеркнуть способности кандидатов писать код и то, как они справляются с протоколированием, тестированием, документированием и развертыванием. Я бы сказал, что это гораздо лучше, чем просто решение задач по написанию кода.

Я даже использовал домашние задания для отбора кандидатов, когда мы набирали сотрудников в свою команду. Я знаю основные минусы, но я считаю, что хорошо поставленную задачу можно решить за один-два вечера, по паре часов каждый. Не очень здорово, но я чувствую себя гораздо более расслабленным, чем проводя 45-метровое собеседование по кодингу. Кстати, о дьяволе…

Я не люблю кодинговые задачи. ИМО, это обычно просто ленивая ерунда. Подобная практика может быть понятна для компаний FAANG (ну, скорее MANGA в наши дни) из-за их масштаба*. Но когда проблемы с кодированием возникают в небольших компаниях, я в основном считаю это просто дурным вкусом.

Отказ от ответственности *: Я не имею в виду, что в масштабах Google им нужно, чтобы их разработчики хорошо знали, как отсортировать массив или найти 2 числа, которые в сумме дают что-то. Я имею в виду, что им приходится перебирать такое количество кандидатов, что им нужен стандартизированный, эффективный по времени и повторяемый способ проверки их способностей. Для таких крупных компаний не представляется реальным давать задания на дом и тщательно проверять их без значительных потерь времени и производительности. Такова печальная реальность.

В довершение ко всему компании используют собеседования по кодированию не по назначению. Собеседования по кодированию должны проверять умение кандидата решать проблемы и коммуникативные навыки. Вы должны показать интервьюеру, каков ход ваших мыслей и как вы решаете новую проблему. Обычно не имеет большого значения, является ли решение, которое вы реализовали, оптимальным или нет. Однако вы должны знать об этом. К сожалению, интервьюеры обычно просто ищут «правильные» ответы, как будто это экзамен, а не дискуссия, что делает весь опыт несчастным.

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

Итак, если бы я составлял рейтинг интервью по кодированию, я бы расположил их следующим образом:

1. «Дискуссионное» интервью по кодированию
2. Тест на кодирование без интервьюера
3. Интервью по кодированию, похожее на экзамен, без особой поддержки со стороны интервьюера.

Конечно, бывают исключения. Однажды, в лагере группы (jk), у меня был фантастический опыт с кодовым испытанием без интервьюера. Это было 3,5-часовое испытание HackerRank, состоящее из трех этапов, для позиции инженера-исследователя. Вопросы варьировались от вероятности до обслуживания модели ML, численной устойчивости и основ теории ML. Затем, на втором этапе, это было упражнение на проверку кода! Мне дали кусок кода, и я должен был определить ошибку и предложить улучшение. Как это круто! Заключительная часть была реальным заданием по кодированию для реализации графового алгоритма. Это было утомительно, но, по крайней мере, это не было общим заданием, и поскольку оно было настолько разнообразным, я почувствовал, что оно позволило людям показать, в чем их истинная сила.

Ладно, я перестаю жаловаться и перехожу к следующей части этого поста.

4-е собеседование

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

Мне очень нравятся вопросы о прошлом опыте и о том, как его можно улучшить, или если что-то не сработало, то почему?
Мне кажется, что эти вопросы больше соотносятся с реальными навыками, чем общие теоретические вопросы.

Несколько вопросов, которые мне очень понравились, были следующими:

• Если я спрошу вашего менеджера, в чем ваша самая большая слабость, что он мне ответит?
• В какой ситуации вы допустили ошибку? Как бы вы предотвратили ее сейчас, имея больше опыта?
• Приведите пример, когда вы приняли неверное техническое решение, а потом пришлось его исправлять. Как вы это сделали?

Вообще, любой вопрос, который просит задуматься о прошлых ошибках, особенно крут. Почему? Они помогают выяснить, как вы выросли с тех пор, насколько вы скромны и как работает ваше критическое мышление.

Я не припомню таких вопросов на собеседовании с ML-специалистами не старшего звена, но на старших/ведущих должностях их было предостаточно. Так что, возможно, подумайте о таких сценариях перед следующим собеседованием.

Несколько последних советов по подготовке

Чтобы по-настоящему проникнуться процессом собеседования, я люблю проводить имитационные собеседования. Лучший способ сделать это (который я нашел) — Pramp.com. Это не реклама, вы можете проверить ссылку — там нет реферального кода или чего-то еще. Я просто нахожу их действительно полезными, особенно для собеседований по кодированию и в некоторой степени для собеседований по проектированию систем.

Для проектирования систем ML лучшее, что я нашел на данный момент, это брошюра Чипа Хуена — Machine Learning Systems Design. И, конечно, для общего проектирования систем — The System Design Primer.

И помните, что нужно действительно готовиться к поведенческим интервью. Будьте готовы ответить на вопросы о том, как вы потерпели неудачу и что вы из этого вынесли. Больше внимания уделяйте поведенческим вопросам, особенно тем, которые подчеркивают ваш лидерский потенциал и ситуации типа «учиться на ошибках». Хороший список поведенческих вопросов см. в этом PDF-файле от LinkedIn.

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

Хотите стать старшим инженером? Чтобы занять эту должность, вам понадобятся как сильные профессиональные навыки, так и превосходные мягкие навыки. Также ознакомьтесь с моей статьей «Стать старшим инженером», которая поможет вам определить свою собственную дорожную карту.

Небольшой отказ от ответственности (последний в этом посте)

Эти посты были почти готовы еще в феврале, но в связи с трагическими событиями, разворачивающимися в Украине, я подумал, что было бы, мягко говоря, нехорошо публиковать их тогда. В Молдове есть поговорка «Satu’ arde da baba sî chiaptănă», что в переводе означает что-то вроде «Неразумная старуха охаживает, пока вся деревня горит». Я не хотела быть этой дамой, поэтому решила, что лучше подождать, пока все станет хотя бы немного менее хаотичным.

#Слава Україні! #Героям слава!