И что делать вместо этого

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

"Как бы вы объяснили линейную регрессию пятилетнему ребенку?"

Давайте посмотрим правде в глаза, поиск работы — даже такой увлекательной, как инженер по машинному обучению — имеет свои взлеты и падения. Для человека с нетрадиционным образованием (в моем случае, он поступил в инновационный колледж под названием Make School, а не в традиционный университет) в процессе собеседования вы столкнетесь с некоторыми вещами, которые вы, возможно, вообще не планировали.

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

Чтобы убедиться, что это стоит вашего времени: вот список всех советов, которые я НЕ собираюсь повторять в этом блоге, потому что я уверен, что вы слышали это раньше:

  1. Понимание концептуальных основ машинного обучения
  2. Имея практический опыт через исследования, OSS, стажировки в промышленности,
  3. Нетворкинг!
  4. Ищите тренера, который успокоит ваши нервы и направит ваше внимание, и/или
  5. Проводите инсценированные интервью, чтобы стать более уверенным перед реальными делами.

Если вы хотите выйти за рамки этого совета (что не означает, что он не имеет законной ценности, и вы должны, вероятно, тратить на это 80% своего времени), то давайте начнем.

Ошибки

№ 1. Решения, которые вы предлагаете, слишком сложны

Этот урок занял у меня мучительно много времени, чтобы усвоить. Около 2,5 месяцев назад я брал интервью у команды ИИ в компании FAANG, которая работала над личным помощником, которого я не буду называть (но я уверен, что вы слышали о нем раньше). Одна из их ключевых функций заключалась в том, чтобы помощник отправлял уведомления пользователям с регулярными интервалами в течение недели, сопоставляя время уведомления со временем дня, когда они обычно регистрируются в соответствующем приложении (например, получая пинг в 7 утра каждый день, поэтому вы можете уточнить расписание занятий йогой в вашем районе). Вы могли бы спросить, что они задали мне во время интервью?

"Итак, как бы вы построили рекомендательную систему для этой функции?"

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

«О, конечно! Позвольте мне посмотреть... а почему бы нам не сделать бота, который мог бы понять ВСЕ привычки пользователя и использовать сверточную функцию, чтобы предсказать, когда пользователю нужно увидеть конкретное уведомление...

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

Введите рекомендательные системы

В качестве примечания — всем, кто ищет отличное введение в рекомендательные системы (с кодом), я настоятельно рекомендую эту записную книжку Kaggle Системы рекомендаций в Python 101 Габриэля Морейры.

# 2: Код, который вы пишете, слишком медленный

Может быть, вы читаете это и думаете: «Ну, разве Python не должен быть медленным? Что я могу с этим поделать?»

Проблема здесь в том, что вы на самом деле правы (и неправы) насчет Python.

Позвольте мне объяснить: в ходе другого собеседования стартап по компьютерному зрению дал мне оценку на вынос и попросил написать базовый алгоритм (о котором, я гарантирую, вы слышали, если изучали компьютерное зрение) fс нуля в Python. После 7–8 часов целенаправленной работы я сделал то, что, по моему мнению, было лучшим, что я мог, и отправил его.

Я потерял эту возможность. И что сказали в отзыве?

"Можно было бы еще оптимизировать".

Это тот момент, когда мы либо 1) рвем на себе волосы, либо 2) узнаем больше о векторизации (и я рекомендую второй вариант). Что на самом деле ищут интервьюеры в оптимизированном коде?

Правда, многое. Как вы уже, наверное, догадались, Python действительно медленный, поскольку его нужно интерпретировать перед компиляцией. Но это не значит, что мы должны соглашаться. Как же так?

Включить векторизацию

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

Самое приятное в векторизации то, что, хотя это звучит сложно, ваш интервьюер легко заметит, что вы это делаете: например, я рекомендую просто использовать больше функций, встроенных в NumPy API, вместо ваших собственных. Как и подарок, который продолжает дарить, векторизованный код также обычно короче, чем обычный Python, потому что вам больше не нужно явно записывать длинные for циклы и тому подобное. Давайте рассмотрим пример: ниже у меня есть функция, которая проецирует набор векторов из одной плоскости в другую в 3-х измерениях (как объяснил AGN Gazer on Stack Overflow). Я покажу вам, как это выглядит без векторизации (ака, с циклом for), а затем снова с использованием функций NumPy:

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

Если вы ищете бесплатное введение в NumPy, я обязательно приглашу вас попробовать вводный учебник Стэнфорда в рамках их класса CS231n. Для более глубокого изучения векторизации я настоятельно рекомендую пройти курс Эндрю Нг Нейронные сети и глубокое обучение на Coursera.

# 3: Думали ли вы об ООП?

В каждом командном программном проекте, над которым я когда-либо работал, всегда был как минимум один человек, которого я называю «няня» — это человек, который заботится о качестве кода.

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

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

Это не всегда необходимо — как и ошибка № 2, это в основном связано с выделением на итоговых оценках, и особенно когда вам не разрешено использовать библиотеки (иначе говоря, вы будете создавать алгоритмы с нуля). . Например, предположим, что компания, занимающаяся искусственным интеллектом, ставит перед вами следующие задачи:

  1. Подгонка многочлена к набору точек XY (без внешних библиотек).
  2. Сопоставьте полином с набором точек XY и сделайте модель устойчивой к выбросам (без внешних библиотек)
  3. Подгонка плоскости к набору точек XYZ (без внешних библиотек)

В чем реальная проблема с этой оценкой? Для меня в начале это было просто избегание ловушки заблудиться в моем собственном коде. Я не осознавал, что все время, проведенное с использованием популярных фреймворков (например, Keras, Scikit-learn), на самом деле тренировало мой мозг работать на автопилоте в моих проектах по машинному обучению.

Чтобы не попасть в эту ловушку, я бы посоветовал вам неначинать кодирование сразу. Если вы это сделаете, это очень похоже на ошибку № 1, когда вы, вероятно, пойдете с чем-то, что не работает и трудно объяснимо. Вместо этого вы, возможно, захотите охватить проблему: определить правильные места для повторного использования кода, а затем создать правильные вспомогательные методы и классы. Продолжая этот пример, вот что я мог бы написать в пакете util в своем проекте:

Я призываю вас уделить немного времени изучению этого кода и посмотреть, что вам в нем нравится/не нравится. Вот несколько вопросов для начала:

  • Я знаю, что это делает?
  • Легко ли это понять?
  • Где я хотел бы использовать это? Сколько это дало бы мне «из коробки», чтобы заняться этим?

Надеюсь, это даст вам хороший шанс задуматься о собственном стиле кодирования и начать развиваться от разработчика, которому просто удобно пользоваться чужими библиотеками (например, Scikit-learn, Keras, PyTorch и т. д.), до разработчика, с которым может справиться ваша команда. полагаться на создание собственного собственного внутреннего API с нуля.

Это может быть много работы, но поверьте мне, это посылает правильный сигнал — я неоднократно получал комплименты от менеджеров компаний по поводу моего кода. Если вас интересуют дополнительные советы по прохождению домашнего тестирования для инженеров-программистов, я рекомендую другой замечательный блог Jane Philipps on freeCodeCamp.

Заключение

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

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

Представьте себе: сто пятьдесят лет назад почти ни у кого в доме не было электрических лампочек. Затем, в 1882 году, Томас Эдисон запустил первую коммерческую электростанцию ​​в Нью-Йорке, изменив все. Теперь перенесемся в сегодняшний день: все наши дома, биомедицинские устройства и даже устройство, на котором вы читаете это, были бы невозможны без сети. И вдруг теперь «ИИ — это новое электричество», по крайней мере, так говорит доктор Эндрю Нг из Стэнфорда.

Почему это важно? Для большинства из нас 1882 год — далекое воспоминание. Но каждый инженер машинного обучения, которого я когда-либо встречал, каждая компания ИИ, с которой я беседовал, напоминали мне, что мы пытаемся стать Эдисонами нашего времени. Прежде чем мы сможем изменить мир, нам нужно получить большой опыт. Итак… почему бы это не быть сложной задачей?