"Часы работы"

Как пройти домашнее собеседование с инженером по машинному обучению

Самый важный первый раунд, который всегда должен делать каждый инженер по машинному обучению

Эта статья вдохновлена ​​Тессой Се, которая недавно написала статью о домашних упражнениях Data Science (DS), в которой она делится почему и как выполнять домашние упражнения DS и как к ним следует подходить.

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

Во-первых, краткое представление о себе ...

  • Родился, вырос и работаю в Сингапуре.
  • В 2017 году получил степень бакалавра экономики и финансов и присоединился к японскому инвестиционному банку.
  • В начале 2020 года переключился на AI / ML, работая на стороне (подробнее об этом здесь!)
  • Переход на новую должность инженера машинного обучения для decacorn в конце месяца

Далее, быстрое заявление об отказе от ответственности ...

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

Давайте начнем!

За последние несколько месяцев я подавал заявки (в основном) на должности начального и среднего звена с названием «Инженер по машинному обучению» (пример снимка экрана с описанием вакансии ниже).

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

Экран телефона рекрутера / отдела кадров → Общая оценка → Технические экраны (от 1 до 3 раундов) → Поведенческий экран (т. Е. Собеседования типа соответствия / повышения планки)

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

  1. 🗺 Исследовательский анализ данных (EDA)
  2. 🧑🏼‍💻 Моделирование
  3. 🤖 Служба API
  4. 🪵 Ведение журнала
  5. 🧪 Модульное и интеграционное тестирование
  6. 🐳 Контейнеризация
  7. 📙 Документация

Прежде чем я буду разбирать 💡 выводы и подводные камни приведенных выше 7 требований, ОЧЕНЬ ВАЖНО иметь в виду следующие рекомендации, когда вы беретесь за самостоятельную оценку.

  • Выделите время, чтобы сосредоточиться на экзамене. Обычно на это уходит неделя или две, но заявки обычно подаются на постоянной основе (т. Е. Чем быстрее вы ее заполняете, тем быстрее может продвигаться цикл собеседований) . Помните, что вы также соревнуетесь со многими другими кандидатами! Стремитесь завершить оценку в течение 48 часов, чтобы вы почти гарантировали следующий раунд (при условии, что отправка хорошая), и вы также дали интервьюерам хорошее впечатление о вас, потому что это указывает им на то, что вы знакомы с требованиями.
  • Расставьте приоритеты! Будьте хорошо осведомлены о требованиях, изложенных в оценке. Некоторые оценки могут даже не включать все строгие требования, в то время как некоторые могут уделять больше внимания одним требованиям и меньше - другим. 48 часов - очень короткий период времени для выполнения всех семи требований - расставьте приоритеты на основе акцента, указанного в полученной вами оценке.
  • Будьте проще, глупо (ПОЦЕЛУЙ). Предполагается, что предварительные оценки должны быть выполнены в очень короткие сроки, поскольку интервьюеры не хотят терять слишком много времени кандидата. НЕ воспринимайте это как возможность продемонстрировать свой чрезмерно сложный набор технологий для решения простой игрушечной задачи. Чрезмерная инженерия - строгое запрещение.
  • Кодируйте как инженер. Вы видели слово «инженер» в слове «инженер машинного обучения»? Да, от вас требуется хорошее программирование и соблюдение передовых практик. Это означает отсутствие мертвого кода, хорошее форматирование кода, модульный код, соблюдение соответствующего руководства по стилю языка (например, PEP8) и многое другое. Да, здесь также требуется хорошая структура папок.

Имея это в виду, позвольте мне разбить каждое из 7 требований.

Исследовательский анализ данных

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

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

  • Отсутствующие данные (выбор метода вменения или удаление данных)
  • Выбросы (и как с ними бороться)
  • Коррелированные признаки
  • Данные, которые просто не имеют смысла

💡 Вывод: разберитесь с набором данных, с которым работаете, и очистите его. Всегда предоставляйте четкие объяснения важных вариантов решения (например, отбрасывание или вменение). Начните с одномерных графиков, а затем переходите к двумерным и многомерным графикам, обеспечивая при этом четкое понимание.

⚠️ Попался: держитесь подальше от автоматизированных инструментов EDA / построения графиков. Это обычно не оставляет хорошего впечатления у рецензента.

Моделирование

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

💡 Вывод: выберите модель, которая хорошо подходит для постановки задачи. Часто бывает достаточно линейной модели (если иное не указано в требованиях).

⚠️ Попался: не выбирайте непонятную или слишком сложную модель (т. Е. Требует много времени для обучения).

Служба API

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

На что следует обратить внимание и понять при создании конечных точек API:

  • Загрузка / повторная загрузка модели
  • Требования к задержке каждой конечной точки
  • Типы методов
  • RESTful API
  • Структура папок каждого роутера

💡 Вывод: используйте передовой опыт при разработке конечных точек API - убедитесь, что вы понимаете, когда следует использовать путь или параметр запроса. При необходимости используйте схемы для определения ответов и моделей базы данных. Раздельная обработка ввода и логика конечной точки. Всегда проверяйте свои конечные точки!

⚠️ Попался: имейте в виду, что службы API обычно тестируются на практике, но это не единственная микросервисная архитектура. Обмен сообщениями также очень широко используется (но его труднее включить в качестве практического использования). Подробнее читайте здесь.

Ведение журнала

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

💡 Вывод: включите ведение журнала в свои модули. Такое простое, но часто игнорируемое требование.

Модульное и интеграционное тестирование

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

Контейнеризация

Поскольку микросервисные архитектуры становятся нормой, Docker также стал синонимом контейнеров. Скорее всего, вы должны будете поместить свое приложение в контейнеры с помощью Docker.

💡 Вывод: продемонстрируйте лучшие практики при создании контейнеров для вашего приложения. Как правило, всегда создавайте максимально эфемерный контейнер. Помните: лучше меньше, да лучше.

Документация

Всегда имейте хорошую документацию по вашим функциям и модулям. Также не забудьте задокументировать другие высокоуровневые решения либо в README, либо с помощью генератора документации (например, Sphinx). Сюда входят такие вещи, как:

  • Почему репо было структурировано определенным образом
  • Использование модуля
  • Настройка и запуск кода
  • Почему были выбраны определенные модели (алгоритмы)
  • Метрики оценки модели
  • Интерпретируемость результатов модели
  • Улучшения, на которые можно потратить больше времени

💡 Вывод: ваш код должен быть в основном самодокументированным. Сосредоточьтесь на документировании вариантов дизайна, которые не объясняются вашим кодом.

Поздравляем с победой в следующем раунде! Что теперь?

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

  • Удовлетворение некоторых требований, которые вы, возможно, пропустили / пропустили
  • Альтернативные модели, которые можно использовать для решения проблемы (и их плюсы и минусы)
  • Как масштабировать службу API (например, горизонтальное и вертикальное масштабирование)
  • Как сделать службу API более эффективной (например, кэширование памяти, индексация базы данных, использование очередей сообщений и т. Д.)
  • Альтернативы выбору дизайна

Заключительные слова

Общая оценка инженера по машинному обучению может принимать разные формы, но я обнаружил, что вышеизложенное отражает типичного инженера по машинному обучению. Если ваша практическая оценка больше ориентирована на EDA и моделирование, ваша роль, скорее всего, будет больше ориентирована на позицию специалиста по данным. В таком случае рекомендую посмотреть эту статью.

Еще раз спасибо, что прочитали мою статью. Обязательно оставьте комментарий, если у вас есть какие-либо мысли о практическом упражнении по машинному обучению машинного обучения! :)

Поддержите меня! - Если вам нравится мой контент и вы не подписаны на Medium, рассмотрите возможность поддержки меня и подписки по моей реферальной ссылке здесь (ПРИМЕЧАНИЕ: часть ваших членских взносов будет распределена мне как реферальные взносы).