Почему ломается рекрутинг в ML?

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

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

Взгляд рекрутера

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

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

Точка зрения кандидата

Вернуться к тому, чтобы стать кандидатом. Мне очень повезло, что меня выбрали, по крайней мере, для первого раунда собеседований с некоторыми из самых популярных стартапов AI/ML. Да, я считаю, что это больше связано с удачей, чем с моей квалификацией. По крайней мере, для нестарших руководящих должностей. Опять же, я могу сказать это, поскольку я был с обеих сторон. В чем-то я справился отлично, в чем-то прилично, а в чем-то просто ужасно. Просто чтобы представить ситуацию в перспективе, под ужасом я подразумеваю время, когда я не мог распечатать содержимое генератора Python. В свою защиту могу поклясться, что смог сделать это, как только интервью закончилось.

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

Большая картина

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

Размытые границы между исследованиями и инженерией

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

Проблема. Рекрутеры не уверены, что именно они ищут. Ищете ли вы исследователя машинного обучения с опытом работы в SWE или SWE с некоторыми знаниями в области исследований? В этом вся разница.

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

Отсутствие ясности в домашних заданиях

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

Проблема.Если метод оценки основан на домашнем задании, он обязательно будет открытым. Это вызывает недоумение с обеих сторон. Это не всегда так, но иногда постановщики проблем просто используют шаблонный вопрос, потому что это переход, и они действительно не знают, что именно они ищут. В конечном итоге они сбиты с толку после получения решения. Кандидат, с другой стороны, не знает, на чем сосредоточиться — работает ли он над улучшением производительности, удобочитаемости, форматирования и тестирования как SWE или просто пытается провести как можно больше экспериментов, чтобы сформировать исследование, как исследователь? Может быть, и то, и другое в идеале, но мы живем не в идеальном мире, где нет дедлайнов.

Решение — точно определите, насколько «открытым» является формулировка проблемы. Лучше заранее решить, в каких областях вы будете оценивать кандидатов, и четко сообщить им об этом. Зная, как их будут оценивать, кандидаты могут легко уделить больше внимания требуемым доменам.

Отсутствие стандартизации

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

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

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

Имейте в виду, что предоставление информации о темах интервью — это не то же самое, что стандартизация процесса. Представьте, что вы работаете в 3 компаниях, где первая проверяет ваше понимание научных работ, вторая хочет, чтобы вы спроектировали распределенную систему, а третья хочет проверить ваши знания DSA. Я не преувеличиваю. Это случилось со мной однажды, и это было одно из тех интервью, когда я замер, распечатывая содержимое генератора. Старые добрые времена.

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

Нижняя граница

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