How to Interview and Hire ML/AI Engineers

eugeneyan

Начните отсюда Статьи Выступления Прототипирование О себе

Как проводить собеседования и нанимать ML/AI-инженеров

[ machinelearning career leadership 🔥 ] · 21 мин чтения

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

В этой статье Jason и я поделимся тем, что мы узнали о собеседовании кандидатов на роли в машинном обучении (ML) и AI. Сначала мы обсудим, какие технические и нетехнические качества стоит оценивать. Затем расскажем, как калибровать телефонные скрининги и проводить цикл интервью и дебриф. Наконец, мы завершим советами для интервьюеров и нанимающих менеджеров, а также нашим субъективным взглядом на некоторые черты хорошего кандидата. (И, как и во всех наших онлайн-текстах, мнения наши собственные.)

Какие технические навыки учитывать

Для большинства ML/AI-ролей ожидается базовое владение разработкой ПО. В зависимости от роли мы встречали простые задачи на программирование на 30–60 минут, в которых кандидата просят:

Проверить, удовлетворяют ли 2D/3D-массивы заданным критериям (например, валидация смоделированного маршрута робота по складу), с обработкой крайних случаев и написанием юнит-тестов. Реализовать и запустить inference-эндпоинт, включая валидацию ввода/вывода, логирование, мониторинг и команду для обновления состояния эндпоинта. Построить пайплайн обработки данных — сначала в пакетном режиме, а затем адаптировать его под стриминг.

Успешное выполнение задачи на программирование — лишь часть собеседования. Важнее то, как кандидат её решает: раскладывает ли он задачу логично, пишет ли чистый, читаемый, поддерживаемый код, учитывает ли крайние случаи, хорошо ли реагирует на обратную связь и т. д.? Бывали случаи, когда кандидат выполнял задачу, но получал решение «не нанимать», потому что то, как он её решил, не дотягивало до планки.

Далее, грамотность в работе с данными — критически важный, но недооценённый навык для ML/AI-ролей. Хотя он расплывчат и труден для количественной оценки, по сути, как мне кажется, грамотность в данных означает понимание и уважение к данным, владение анализом данных и интуицию на то, когда с данными или анализом что-то не так.

Можно ожидать, что инженерия в Google в основном состоит из реализации алгоритмов уровня PhD, и хотя иногда это так, значительная часть работы инженера поиска или AI состоит в просмотре примеров, выявлении паттернов, ручной разметке данных и прочем немасштабируемом анализе «в полях». — shreyans.org

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

Владение анализом данных выходит за рамки написания SQL или вычисления статистик. Объединяя таблицы, не дублируем ли мы и не теряем ли строки, ошибочно предполагая, что ключ соединения уникален и полон? Вычисляя статистики, не зацикливаемся ли мы только на агрегатах вроде среднего и медианы, упуская важные паттерны и подгруппы (см. парадокс Симпсона)? Направляют ли наши визуализации данных аудиторию к точным интерпретациям? В конечном счёте цель — не анализ ради анализа, а лучшие решения и действия.

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

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

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

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

Эти вопросы позволяют кандидату рассказать об ошибках, которые он совершал, и об извлечённых уроках. Это также раскрывает его самоосознанность, интеллектуальную честность и смирение, чтобы поделиться прошлыми промахами. См. также взгляд Jason на то, как НЕ выглядит грамотность в данных.

Также для ML/AI-инженеров полезно быть в ладу с выводом непрозрачных моделей. Иногда, когда инженеры-программисты только начинают работать с ML-моделями, они ожидают уровня контроля и предсказуемости, как у баз данных или обычных API. Но, к их удивлению, ML-модели — это совершенно иные звери. У них нет идеальной точности, их предсказания могут меняться при переобучении на новых данных, у них нет ясной интерпретируемости того, как они приходят к результатам, а для больших языковых моделей (LLM) вывод стохастичен — один и тот же ввод может приводить к разным результатам.

Хотя большинство инженеров со временем привыкают к этим причудам, некоторые так и не становятся вполне комфортны с присущей ML неопределённостью и непрозрачностью. И это нормально. Им, вероятно, будет счастливее в ролях, не связанных с непосредственным созданием ML-моделей или взаимодействием с ними.

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

Какой неожиданный/предвзятый вывод вы видели? Как вы с ним справились, если требовалось? Какие ограничители/политики вы выстраиваете вокруг модели, чтобы согласовать её с пользователем? Если вы замечаете смещение, возникающее у модели, как бы вы его смягчили?

Наконец, базовое понимание evals критично для любого, кто строит продукты на основе ML. По своей сути машинное обучение — эмпирическая дисциплина. Даже если ML/AI-инженер не обучает модели напрямую, на нём лежит ответственность оценивать модель, которую он использует, будь то простое дерево решений, рекомендательная система или готовый LLM API. Об опыте кандидата с evals можно спросить так:

Как вы измеряли качество модели во времени, по мере её переобучения или обновления? Когда качество модели нарушало заранее заданные пороги, как вы реагировали? Как вы собирали первоначальные данные для оценки и строили eval-харнесс?

Чтобы глубже разобраться в проведении evals для продуктов на основе LLM, вам могут пригодиться: (i) Your AI Product Needs Evals, (ii) Task-Specific LLM Evals that Do & Don’t Work, (iii) Evaluating the n levels of RAG, (iv) Data Flywheels for LLM Applications (Evaluation)

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

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

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

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

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

Как вы оценивали модель или систему и проводили анализ ошибок? С какими ограничениями вы столкнулись и какие трудные компромиссы пришлось сделать? Как вы реализовали защитные механизмы и политики вокруг модели или системы? Каков был результат, и оглядываясь назад, что бы вы сделали иначе?

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

Например, у нас может быть вопрос о проектировании рекомендательной системы для часто меняющихся объектов (например, рекламы). Большинство кандидатов исследуют такие вопросы, как холодный старт и разреженные данные, необходимость explore-exploit, метрики оптимизации (например, показы, клики, конверсии) и баланс между органической вовлечённостью и выручкой.

Подробнее об опыте одного кандидата на научных интервью читайте здесь.

Какие нетехнические способности стоит замечать

Помимо собеседования на технические навыки, полезно также учитывать нетехнические аспекты опыта кандидата, особенно для ролей уровня senior и выше. Среди измерений, которые стоит рассмотреть, — неопределённость (ambiguity), влияние (influence), сложность (complexity) и исполнение (execution), сокращённо AICE.

Неопределённость (ambiguity) — это насколько расплывчатой была задача, когда кандидат начал над ней работать. Иногда задача чётко очерчена с заранее заданными критериями успеха, что позволяет сосредоточиться на реализации. В других ситуациях кандидату приходится самому определять задачу и меры успеха. Кроме того, есть ли у задачи известные решения и лучшие отраслевые практики? Или она ранее не решалась и не имеет прецедентов? Уровень руководства тоже важен — работал ли кандидат под пристальным надзором или в основном самостоятельно? Наконец, одни задачи более узкие и сфокусированы на технике, а значит, вероятно, менее неопределённы, тогда как другие охватывают весь бизнес и организацию.

Влияние (influence) отражает масштаб того, как кандидат сотрудничает и добивается результата через других. Работа кандидата может в основном затрагивать влияние на его непосредственную команду, несколько команд, несколько направлений бизнеса или даже на область и сообщество. Полезно также понять механизмы его влияния — ревью дорожных карт/дизайна, office hours, консультирование по проекту или менторство. Его влияние может выходить за рамки технической стратегии и формировать продуктовые и бизнес-решения. Кандидаты-мультипликаторы повышают отдачу окружающих, а не только свой собственный непосредственный вклад.

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

Исполнение (execution) — это способность кандидата достигать результата при ограниченных ресурсах и сроках. Мы рассматриваем не только решения или продукты, хорошо показавшие себя в A/B-тесте — в конце концов, цена инноваций — это случайные неудачи, и мы хотим знать, насколько быстро кандидат умеет ошибаться, учиться и итерировать. Кроме того, одни сосредоточены на тактических, краткосрочных задачах, тогда как другие выдают стратегические решения, устраняющие сразу несколько укоренившихся проблем. В рамках исполнения некоторые даже создают новые подходы, которые перенимаются другими командами или отраслью. Объём и масштаб требуемых усилий (например, число команд) также учитываются.

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

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

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

• • •

До сих пор мы фокусировались на том, что оценивать на собеседовании для ML/AI-ролей. Далее обсудим, как калибровать телефонный скрининг, проводить цикл интервью и дебриф. (Цикл интервью обычно состоит из нескольких интервьюеров, оценивающих различные аспекты.) Затем завершим советами для интервьюеров и нанимающих менеджеров.

Калибровка телефонного скрининга для успеха цикла

Прежде чем вкладываться в цикл интервью, большинство нанимающих менеджеров проводят телефонный скрининг. Цель — отобрать кандидатов с высокой вероятностью успеха в цикле интервью. Циклы интервью обходятся дорого и часто требуют «игры в Tetris» по расписаниям нескольких интервьюеров. Типичный цикл может включать пять интервью по часу каждое плюс 30-минутный пре-брифинг и дебриф с участием всех интервьюеров. Это 10 часов коллективного времени, вложенных в одного кандидата, не считая времени на подготовку и написание обратной связи.

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

После такого детального телефонного скрининга нанимающий менеджер решает, склонен ли он нанять кандидата на основе собранных к этому моменту данных. Если да, кандидата приглашают на очное интервью. Иногда нанимающий менеджер не уверен в кандидате, но всё равно приглашает его пройти цикл интервью, надеясь, что это поможет принять решение о найме. Это ошибка. В большинстве случаев сомнительный кандидат работу не получит, а в процессе будет потрачено много времени. Нанимающий менеджер не должен приглашать кандидата на трудоёмкий и дорогой цикл интервью, если он не склонен нанять его после телефонного собеседования. — Working Backwards

Проведение цикла интервью и дебрифа

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

Например, циклу нужно знать, ориентирована ли роль больше на финансовый анализ и A/B-тесты, или на обучение и обслуживание recsys-моделей, или на RAG и создание пользовательских продуктов на основе LLM. Также полезно рассказать об ожидаемом уровне неопределённости, влияния, сложности и исполнения для роли, или о том, есть ли какие-либо ценности компании, по которым интервьюерам следует собрать данные.

Для самих интервью мы обнаружили, что формат STAR эффективен для сбора релевантных данных на основе прошлого поведения и работы:

Ситуация/Задача (Situation/Task): контекст и масштаб проблемы, включая ставки и потенциальное влияние, если не действовать. Также назначенная кандидату ответственность. Действие (Action): роль, которую сыграл кандидат, возникшие трудности, применённые навыки и знания. Также был ли он ключевым драйвером и как именно внёс вклад? Результаты (Results): измеримые итоги, такие как влияние на клиентов, новые возможности, выручка или экономия затрат. Также как он выбирал и измерял эти метрики?

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

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

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

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

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

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

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

В конечном счёте дебриф должен завершиться решением о том, делать ли оффер. Голосование не обязательно должно быть единогласным, но не должно быть сильных возражений против найма кандидата. Если интервьюер настолько уверен, что готов сказать что-то вроде «Я уволюсь, если мы наймём этого человека», — это тревожный сигнал, который стоит обсудить: что заметил этот интервьюер, что другие могли упустить? В целом, хотя консенсус идеален, окончательное решение принадлежит нанимающему менеджеру.

Для интервьюеров: кандидаты — это неогранённые алмазы

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

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

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

Для нанимающих менеджеров: продавайте миссию и плотность талантов

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

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

Наконец, будьте готовы к тому, что наём займёт время, особенно для более старших ролей. В целом найм junior/mid-level IC занимает несколько месяцев, тогда как старшие роли могут занять до года. Кроме того, лучшие кандидаты обычно не в поиске — они слишком заняты учёбой, созданием и удовольствием от своей работы. Тем не менее не повредит начать выстраивать отношения везде, где они появляются, — будь то митапы, конференции, хакатоны или просто онлайн.

• • •

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

Голод (Hunger) проявляется как склонность к действию, способность быстро учиться и упорство, чтобы прорываться сквозь трудности. В стартапах это помогает кандидатам быстро адаптироваться, пока стартап итерирует к product-market fit. В крупных организациях это помогает новым сотрудникам преодолевать технические и организационные препятствия, которые могли бы обескуражить других.

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

Здравое суждение (Judgement) — это с трудом добытая интуиция, позволяющая отличить то, что сработает, от погони за миражом или тупика. Суждение помогает принимать прагматичные решения, думать на несколько шагов вперёд и быть решительным перед лицом неопределённости. В контексте ML это может быть проектное решение сфокусироваться на техниках, хорошо работающих с разреженными данными для рекомендаций при холодном старте, или решение не делать ставку на чат для продуктов на основе LLM.

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

Эмпатия (Empathy) — это искренний интерес к клиентам, организации и команде. Она может проявляться как страсть к миссии/продукту и к тому, как он помогает клиентам. Эмпатия облегчает выстраивание доверия, расширение возможностей других и поддержание продуктивных отношений. Люди с эмпатией также лучше коммуницируют, потому что они «сначала стремятся понять, а затем быть понятыми». Это особенно важно для старших ролей, которым может приходиться влиять без формальной власти, ориентироваться в деликатных организационных вызовах и сглаживать остро обсуждаемые темы.

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

Что ж, это всё, что у нас было. Спасибо, что прочитали этот длинный материал! Если вы активно ищете ML/AI-роль, загляните на доску вакансий Jason. А какие ещё практики собеседований хорошо вам послужили? Пожалуйста, оставьте комментарий ниже или напишите мне в DM!

Если этот материал оказался вам полезен, пожалуйста, цитируйте его так:

Yan, Ziyou. (Jul 2024). How to Interview and Hire ML/AI Engineers. eugeneyan.com. https://eugeneyan.com/writing/how-to-interview/.

или

@article{yan2024default, title = {How to Interview and Hire ML/AI Engineers}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2024}, month = {Jul}, url = {https://eugeneyan.com/writing/how-to-interview/} }

Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.