How to Interview and Hire ML/AI Engineers
Юджин Ян и Jason делятся опытом проведения собеседований и найма на ML/AI-роли, рассматривая процесс интервью как систему, которая должна быть надёжной и валидной. Из технических навыков они оценивают базовое владение разработкой ПО (по тому, КАК кандидат решает задачу), грамотность в работе с данными, готовность работать с непрозрачными стохастическими моделями и понимание evals; для научных ролей добавляются интервью на широту, глубину и применение знаний. Среди нетехнических качеств для senior-ролей предлагается фреймворк AICE — неопределённость (ambiguity), влияние (influence), сложность (complexity) и исполнение (execution). Авторы подробно разбирают, как калибровать телефонный скрининг (loop из 5 интервью обходится примерно в 10 часов общего времени), вести цикл интервью по формату STAR и проводить дебриф с независимой обратной связью, где финальное решение остаётся за нанимающим менеджером. Они советуют интервьюерам относиться к кандидатам как к «неогранённым алмазам», а менеджерам — продавать миссию и плотность талантов, а не только компенсацию. В заключение выделяются три ключевые черты сильного найма: голод (hunger), здравое суждение (judgment) и эмпатия (empathy), которые чаще нанимают, чем развивают.
How to Interview and Hire ML/AI Engineers
Как проводить собеседования и нанимать ML/AI-инженеров
[ machinelearning career leadership 🔥 ] · 21 мин чтения
Hiring well is the highest leverage activity we can do for the mission and organization. And running effective interviews is key to hiring well. We can think of the interview process as a system: Given a candidate, assesses whether they are a good fit for the role and team. Thus, to hire well, the interview system should be reliable and valid, with minimal noise.
Качественный найм — это самая высокорычажная деятельность, которую мы можем предпринять ради миссии и организации. А эффективные собеседования — ключ к качественному найму. Процесс интервью можно представить как систему: получая кандидата, она оценивает, подходит ли он для роли и команды. Поэтому, чтобы нанимать хорошо, система интервью должна быть надёжной и валидной, с минимумом шума.
In this write-up, Jason and I will share a few things we’ve learned about interviewing candidates for machine learning (ML) and AI roles. First, we’ll discuss what technical and non-technical qualities to assess. Then, we’ll share how to calibrate phone screens, and run the interview loop and debrief. Finally, we’ll wrap up with some tips for interviewers and hiring managers, as well as our opinionated take on some traits of a good hire. (And like all our writing online, opinions our own.)
В этой статье Jason и я поделимся тем, что мы узнали о собеседовании кандидатов на роли в машинном обучении (ML) и AI. Сначала мы обсудим, какие технические и нетехнические качества стоит оценивать. Затем расскажем, как калибровать телефонные скрининги и проводить цикл интервью и дебриф. Наконец, мы завершим советами для интервьюеров и нанимающих менеджеров, а также нашим субъективным взглядом на некоторые черты хорошего кандидата. (И, как и во всех наших онлайн-текстах, мнения наши собственные.)
What technical skills to consider
Какие технические навыки учитывать
For most ML/AI roles, a basic proficiency in software engineering is expected. Depending on the role, we’ve seen simple 30-60 minute coding exercises that ask a candidate to:
Для большинства ML/AI-ролей ожидается базовое владение разработкой ПО. В зависимости от роли мы встречали простые задачи на программирование на 30–60 минут, в которых кандидата просят:
Проверить, удовлетворяют ли 2D/3D-массивы заданным критериям (например, валидация смоделированного маршрута робота по складу), с обработкой крайних случаев и написанием юнит-тестов. Реализовать и запустить inference-эндпоинт, включая валидацию ввода/вывода, логирование, мониторинг и команду для обновления состояния эндпоинта. Построить пайплайн обработки данных — сначала в пакетном режиме, а затем адаптировать его под стриминг.
Successfully completing the coding exercise is only part of the interview. What’s more important is how the candidate solves it: Do they break down the problem logically, write clean, readable, maintainable code, consider edge cases, respond well to feedback, etc? There’ve been cases where a candidate completes the coding exercise but receives a “no hire” decision because how they solved it did not meet the bar.
Успешное выполнение задачи на программирование — лишь часть собеседования. Важнее то, как кандидат её решает: раскладывает ли он задачу логично, пишет ли чистый, читаемый, поддерживаемый код, учитывает ли крайние случаи, хорошо ли реагирует на обратную связь и т. д.? Бывали случаи, когда кандидат выполнял задачу, но получал решение «не нанимать», потому что то, как он её решил, не дотягивало до планки.
Next, data literacy is a crucial yet overlooked skill for ML/AI roles. While it’s nebulous and hard to quantify, I think that at its core, data literacy means understanding and respecting the data, being proficient at data analysis, and having an intuition for when the data or analysis smells fishy.
Далее, грамотность в работе с данными — критически важный, но недооценённый навык для ML/AI-ролей. Хотя он расплывчат и труден для количественной оценки, по сути, как мне кажется, грамотность в данных означает понимание и уважение к данным, владение анализом данных и интуицию на то, когда с данными или анализом что-то не так.
One may expect Google engineering to largely consist of implementing PhD level algorithms, and while that’s sometimes true, much of a search or AI engineer’s job involves looking at examples, spotting patterns, hand labelling data, and other non-scalable, in-the-weeds analysis. — shreyans.org
Можно ожидать, что инженерия в Google в основном состоит из реализации алгоритмов уровня PhD, и хотя иногда это так, значительная часть работы инженера поиска или AI состоит в просмотре примеров, выявлении паттернов, ручной разметке данных и прочем немасштабируемом анализе «в полях». — shreyans.org
To respect the data is to make an effort to understand it—firsthand—beyond assumptions about how it was collected and stored. For example, data-savvy engineers understand that server-side and client-side logs will differ. They’ll also look at rows of data, and check for missing values, outliers, and inconsistencies. They know how to clean and preprocess data to make it easier to use downstream, whether for training models or serving features. And they monitor the data for contamination or drift over time.
Уважать данные — значит прилагать усилия, чтобы понять их из первых рук, выходя за рамки предположений о том, как они были собраны и сохранены. Например, инженеры, разбирающиеся в данных, понимают, что серверные и клиентские логи будут различаться. Они также смотрят на строки данных и проверяют их на пропущенные значения, выбросы и несоответствия. Они знают, как очищать и предобрабатывать данные, чтобы их было проще использовать дальше — будь то для обучения моделей или подачи признаков. И они отслеживают данные на загрязнение или дрейф со временем.
Proficiency in data analysis goes beyond writing SQL or computing statistics. When joining tables, are we accidentally duplicating or dropping rows by incorrectly assuming that a join key is unique and complete? When computing statistics, do we only focus on aggregate stats like mean and median and thus miss crucial patterns and subgroups (see Simpson’s paradox)? Do our data visualizations guide the audience toward accurate interpretations? Ultimately, the goal isn’t analysis per se but better decisions and actions.
Владение анализом данных выходит за рамки написания SQL или вычисления статистик. Объединяя таблицы, не дублируем ли мы и не теряем ли строки, ошибочно предполагая, что ключ соединения уникален и полон? Вычисляя статистики, не зацикливаемся ли мы только на агрегатах вроде среднего и медианы, упуская важные паттерны и подгруппы (см. парадокс Симпсона)? Направляют ли наши визуализации данных аудиторию к точным интерпретациям? В конечном счёте цель — не анализ ради анализа, а лучшие решения и действия.
Perhaps more important is the intuition (read: skepticism) to question an analysis that seems off. This may require domain knowledge to know when the analysis contradicts our intuition and we need to dig deeper. More specifically to ML, if we look at a precision-recall curve and see precision plunging or recall spiking at a certain threshold, do we have the curiosity and drive to figure out the root cause and fix it? In general, acting on good data intuition leads to healthier data and thus better performing ML systems.
Пожалуй, ещё важнее интуиция (читай: скептицизм), позволяющая усомниться в анализе, который выглядит подозрительно. Это может требовать знания предметной области, чтобы понять, когда анализ противоречит нашей интуиции и нужно копать глубже. Применительно к ML: если мы смотрим на кривую precision-recall и видим, что precision резко падает или recall взлетает на определённом пороге, есть ли у нас любопытство и стремление найти первопричину и исправить её? В целом, действия на основе хорошей интуиции о данных ведут к более здоровым данным и, как следствие, к более эффективным ML-системам.
When the data and the anecdotes disagree, the anecdotes are usually right. It’s usually not that the data is being miscollected. It’s usually that you’re not measuring the right thing. — Jeff Bezos
Когда данные и анекдотические свидетельства расходятся, обычно правы свидетельства. Дело, как правило, не в том, что данные собираются неверно. Дело обычно в том, что вы измеряете не то, что нужно. — Jeff Bezos
We can assess for data literacy by asking follow-up questions such as:
Оценить грамотность в данных можно с помощью уточняющих вопросов, таких как:
Как вы обрабатывали данные? С какими проблемами столкнулись и как их решили? Какая сводная статистика вводила в заблуждение? Какие оказались полезнее других? Какую содержательную визуализацию данных вы создали и почему? А какая была наименее полезной?
These questions let the candidate share about mistakes they’ve made and lessons learned. This also reveals the candidate’s self-awareness, intellectual honesty, and the humility to share their past errors. Also see Jason’s take on what data literacy does NOT look like.
Эти вопросы позволяют кандидату рассказать об ошибках, которые он совершал, и об извлечённых уроках. Это также раскрывает его самоосознанность, интеллектуальную честность и смирение, чтобы поделиться прошлыми промахами. См. также взгляд Jason на то, как НЕ выглядит грамотность в данных.
It also helps for ML/AI engineers to be comfortable with the output of opaque models. Sometimes, when software engineers first start working with ML models, they expect a level of control and predictability similar to databases or conventional APIs. But to their surprise, ML models are completely different beasts. They don’t have perfect accuracy, their predictions may change when the model is retrained on new data, they lack clear interpretability on how they arrive at outputs, and for large language models (LLMs), the output is stochastic where the same input can lead to different outputs.
Также для ML/AI-инженеров полезно быть в ладу с выводом непрозрачных моделей. Иногда, когда инженеры-программисты только начинают работать с ML-моделями, они ожидают уровня контроля и предсказуемости, как у баз данных или обычных API. Но, к их удивлению, ML-модели — это совершенно иные звери. У них нет идеальной точности, их предсказания могут меняться при переобучении на новых данных, у них нет ясной интерпретируемости того, как они приходят к результатам, а для больших языковых моделей (LLM) вывод стохастичен — один и тот же ввод может приводить к разным результатам.
While most engineers eventually adapt to these quirks, some never get fully comfortable with the inherent uncertainty and opacity of ML. And that’s okay. They’ll probably be happier in roles that don’t involve directly building or interacting with ML models.
Хотя большинство инженеров со временем привыкают к этим причудам, некоторые так и не становятся вполне комфортны с присущей ML неопределённостью и непрозрачностью. И это нормально. Им, вероятно, будет счастливее в ролях, не связанных с непосредственным созданием ML-моделей или взаимодействием с ними.
Folks who’re comfortable with ML understand we can’t have full control or interpretability over most models, and that all models will reflect biases from their training data. They also know to build validators and policies to align the system’s (instead of the model’s) behavior with the needs of users and the business. We can learn about this by asking:
Те, кому комфортно с ML, понимают, что мы не можем иметь полного контроля или интерпретируемости над большинством моделей и что все модели будут отражать смещения из обучающих данных. Они также знают, как строить валидаторы и политики, чтобы согласовать поведение системы (а не модели) с потребностями пользователей и бизнеса. Узнать об этом можно, спросив:
Какой неожиданный/предвзятый вывод вы видели? Как вы с ним справились, если требовалось? Какие ограничители/политики вы выстраиваете вокруг модели, чтобы согласовать её с пользователем? Если вы замечаете смещение, возникающее у модели, как бы вы его смягчили?
Finally, having a basic understanding of evals is key for anyone building ML-powered products. Fundamentally, machine learning is an empirical discipline. Even if an ML/AI engineer isn’t directly training models, they have a responsibility to evaluate the model they’re using whether it’s a simple decision tree, a recommender system, or an off-the-shelf LLM API. We can ask about a candidate’s experience with evals by asking:
Наконец, базовое понимание evals критично для любого, кто строит продукты на основе ML. По своей сути машинное обучение — эмпирическая дисциплина. Даже если ML/AI-инженер не обучает модели напрямую, на нём лежит ответственность оценивать модель, которую он использует, будь то простое дерево решений, рекомендательная система или готовый LLM API. Об опыте кандидата с evals можно спросить так:
Как вы измеряли качество модели во времени, по мере её переобучения или обновления? Когда качество модели нарушало заранее заданные пороги, как вы реагировали? Как вы собирали первоначальные данные для оценки и строили eval-харнесс?
To understand more about running evals for LLM-powered products, you might find these useful: (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)
Чтобы глубже разобраться в проведении 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)
For the increasing number of AI engineer roles that apply pretrained models and APIs to build products, the above is usually sufficient. Nonetheless, for roles closer to research or applied science, we typically also assess for science breadth, depth, and application.
Для растущего числа ролей AI-инженера, в которых применяют предобученные модели и API для создания продуктов, перечисленного выше обычно достаточно. Тем не менее для ролей, ближе к исследованиям или прикладной науке, мы обычно также оцениваем научную широту, глубину и применение.
Science breadth interviews assess a candidate’s familiarity with various ML domains. They’re usually based on what the team needs. I tend to start with the basics of supervised and unsupervised learning (to build the candidate’s confidence) before progressing to more specialized areas such as recommender systems, language modeling, and evaluation / benchmarking. Other teams might prioritize forecasting, operations optimization, computer vision, or multi-modal models.
Интервью на научную широту оценивают знакомство кандидата с различными областями ML. Они обычно строятся на том, что нужно команде. Я склонен начинать с основ обучения с учителем и без учителя (чтобы укрепить уверенность кандидата), прежде чем переходить к более специализированным областям, таким как рекомендательные системы, языковое моделирование и оценка/бенчмаркинг. Другие команды могут отдавать приоритет прогнозированию, оптимизации операций, компьютерному зрению или мультимодальным моделям.
While interviewing for breadth, we shouldn’t expect expertise in every area—that would be unrealistic, especially compared to the interviewer who has likely conducted the interview dozens, if not hundreds of times. Instead, the goal is to understand the candidate’s breadth of knowledge and where the gaps are. You can make a point to communicate this upfront, letting candidates know that you’ll continue probing till you reach the boundaries of their knowledge, and encourage them to call out when they’re unfamiliar with a topic so the interview can focus the time on their strengths.
Проверяя широту, не стоит ожидать экспертизы в каждой области — это было бы нереалистично, особенно в сравнении с интервьюером, который, скорее всего, проводил это интервью десятки, если не сотни раз. Вместо этого цель — понять широту знаний кандидата и где находятся пробелы. Стоит сразу проговорить это, дав кандидату знать, что вы будете продолжать прощупывать, пока не дойдёте до границ его знаний, и предложить ему сообщать, когда тема ему незнакома, чтобы интервью сфокусировалось на его сильных сторонах.
In contrast, science depth interviews invite the candidate to showcase their expertise on a project of their choice. The goal is to understand how rigorously they’ve thought about and executed on a problem. What were alternative designs or techniques considered, or what connections were drawn to adjacent fields? How did they navigate constraints and make difficult trade-offs? Can they discuss nitty-gritty details and implementation challenges? And how they they measure impact on customers and the business? Candidates who have depth in past work can likely bring similar rigor and thoughtfulness to future work.
В отличие от этого, интервью на научную глубину предлагают кандидату продемонстрировать свою экспертизу на проекте по его выбору. Цель — понять, насколько строго он продумал задачу и реализовал её. Какие альтернативные конструкции или техники рассматривались, какие связи проводились со смежными областями? Как он справлялся с ограничениями и принимал трудные компромиссы? Может ли он обсуждать мельчайшие детали и сложности реализации? И как он измерял влияние на клиентов и бизнес? Кандидаты, у которых есть глубина в прошлой работе, скорее всего, привнесут такую же строгость и вдумчивость в будущую.
I’ve found depth interviews to be the hardest to conduct, especially when the candidate’s expertise is very different from my own. Candidates could be working on anything from optimizing robot navigation in a warehouse to inserting virtual ad posters into movies and livestreams. In these cases, here are questions to collect data points on the fundamentals:
Я обнаружил, что интервью на глубину проводить труднее всего, особенно когда экспертиза кандидата сильно отличается от моей собственной. Кандидаты могут работать над чем угодно — от оптимизации навигации робота по складу до вставки виртуальных рекламных постеров в фильмы и прямые трансляции. В таких случаях вот вопросы для сбора данных об основах:
Как вы оценивали модель или систему и проводили анализ ошибок? С какими ограничениями вы столкнулись и какие трудные компромиссы пришлось сделать? Как вы реализовали защитные механизмы и политики вокруг модели или системы? Каков был результат, и оглядываясь назад, что бы вы сделали иначе?
Science application interviews challenge a candidate to apply their skills and knowledge to a practical problem, typically one directly relevant to the hiring team’s work. There’s usually no “right” solution. Instead, the focus is on the candidate’s thought process while they solve the problem, as well as the various perspectives they consider, such as science, engineering, product, and business. Often, the candidate’s questions are more insightful (on their ability) than the eventual solution proposed.
Интервью на научное применение предлагают кандидату применить свои навыки и знания к практической задаче, обычно напрямую связанной с работой нанимающей команды. «Правильного» решения, как правило, нет. Вместо этого фокус — на ходе мыслей кандидата при решении задачи, а также на различных перспективах, которые он учитывает: наука, инженерия, продукт и бизнес. Зачастую вопросы кандидата более показательны (о его способностях), чем итоговое предложенное решение.
For example, we might have a question on designing a recommendation system for frequently changing items (e.g., ads). Most candidates explore issues like cold-start and sparse data, the need to explore-exploit, optimization metrics (e.g., impressions, clicks, conversions), and balancing between organic engagement and revenue.
Например, у нас может быть вопрос о проектировании рекомендательной системы для часто меняющихся объектов (например, рекламы). Большинство кандидатов исследуют такие вопросы, как холодный старт и разреженные данные, необходимость explore-exploit, метрики оптимизации (например, показы, клики, конверсии) и баланс между органической вовлечённостью и выручкой.
Read more about one candidate’s experience on science interviews here.
Подробнее об опыте одного кандидата на научных интервью читайте здесь.
What non-technical abilities to look out for
Какие нетехнические способности стоит замечать
Beyond interviewing for technical skills, it helps to also consider the non-technical aspects of a candidate’s experience, especially for senior+ roles. Some dimensions to consider include ambiguity, influence, complexity, and execution (AICE).
Помимо собеседования на технические навыки, полезно также учитывать нетехнические аспекты опыта кандидата, особенно для ролей уровня senior и выше. Среди измерений, которые стоит рассмотреть, — неопределённость (ambiguity), влияние (influence), сложность (complexity) и исполнение (execution), сокращённо AICE.
Ambiguity is how nebulous the problem was when the candidate started working on it. Sometimes, the problem is clearly scoped with predefined success criteria, allowing them to focus on implementation. In other situations, the candidate may have to define the problem and measures of success. Also, does the problem have known solutions and best practices from industry? Or is it previously unsolved with no prior art? The level of guidance is also relevant—did the candidate operate with close supervision, or largely on their own? Finally, some problems are more narrow and focused on the technical, and thus likely less ambiguous, while others span across the business and organization.
Неопределённость (ambiguity) — это насколько расплывчатой была задача, когда кандидат начал над ней работать. Иногда задача чётко очерчена с заранее заданными критериями успеха, что позволяет сосредоточиться на реализации. В других ситуациях кандидату приходится самому определять задачу и меры успеха. Кроме того, есть ли у задачи известные решения и лучшие отраслевые практики? Или она ранее не решалась и не имеет прецедентов? Уровень руководства тоже важен — работал ли кандидат под пристальным надзором или в основном самостоятельно? Наконец, одни задачи более узкие и сфокусированы на технике, а значит, вероятно, менее неопределённы, тогда как другие охватывают весь бизнес и организацию.
Influence captures the scope of how the candidate collaborates and drives impact through others. A candidate’s work may primarily involve influence on their immediate team, multiple teams, multiple lines of business, or even the field and community. It also helps to understand their mechanisms of influence, such as roadmap/design reviews, office hours, advising on a project, or being a mentor. Their influence may also extend beyond technical strategy into shaping product and business decisions. Candidates who are a force multiplier elevate the output of those around them, not just their own direct contribution.
Влияние (influence) отражает масштаб того, как кандидат сотрудничает и добивается результата через других. Работа кандидата может в основном затрагивать влияние на его непосредственную команду, несколько команд, несколько направлений бизнеса или даже на область и сообщество. Полезно также понять механизмы его влияния — ревью дорожных карт/дизайна, office hours, консультирование по проекту или менторство. Его влияние может выходить за рамки технической стратегии и формировать продуктовые и бизнес-решения. Кандидаты-мультипликаторы повышают отдачу окружающих, а не только свой собственный непосредственный вклад.
Complexity refers to the intricacy of the problem space. (Not to be confused with the complexity of the solution! Ideally, we’d solve complex problems with simple, elegant solutions.) Some problems can be isolated to a specific component or system, while others require work across multiple interdependent systems with competing constraints and trade-offs. We want to understand the level of complexity the candidate has worked on and is used to, while getting a sense of the effectiveness of their solutions.
Сложность (complexity) относится к запутанности пространства задачи. (Не путать со сложностью решения! В идеале мы решаем сложные задачи простыми, элегантными решениями.) Одни задачи можно изолировать в рамках конкретного компонента или системы, тогда как другие требуют работы в нескольких взаимозависимых системах с конкурирующими ограничениями и компромиссами. Мы хотим понять уровень сложности, с которым кандидат работал и к которому привык, заодно составив представление об эффективности его решений.
Execution is the candidate’s ability to deliver within limited resources and timelines. We don’t only consider solutions or products that did well on an A/B test—after all, the cost of innovation is the occasional failure and we want to know how fast the candidate can fail, learn, and iterate. Also, some focus on tactical, short-term problems, while others deliver strategic solutions that solve multiple endemic problems. As part of execution, some even pioneer new approaches that are adopted across teams or industry. The scope and scale of effort required (e.g., number of teams) is also a consideration.
Исполнение (execution) — это способность кандидата достигать результата при ограниченных ресурсах и сроках. Мы рассматриваем не только решения или продукты, хорошо показавшие себя в A/B-тесте — в конце концов, цена инноваций — это случайные неудачи, и мы хотим знать, насколько быстро кандидат умеет ошибаться, учиться и итерировать. Кроме того, одни сосредоточены на тактических, краткосрочных задачах, тогда как другие выдают стратегические решения, устраняющие сразу несколько укоренившихся проблем. В рамках исполнения некоторые даже создают новые подходы, которые перенимаются другими командами или отраслью. Объём и масштаб требуемых усилий (например, число команд) также учитываются.
As we listen to a candidate describe their experiences, we can pick up cues that indicate the level of AICE they operate on. For example, a candidate working on a project to boost subscription rates through signup bonuses may have to frequently collaborate with finance, suggesting cross-team influence. But if their manager handled most of the negotiation and debates, their influence may be more limited than it appears.
Слушая, как кандидат описывает свой опыт, мы можем улавливать сигналы, указывающие на уровень AICE, на котором он работает. Например, кандидат, занятый проектом по повышению числа подписок через бонусы за регистрацию, мог часто сотрудничать с финансовым отделом, что говорит о межкомандном влиянии. Но если большую часть переговоров и споров взял на себя его менеджер, его влияние может быть более ограниченным, чем кажется.
Depending on the role and stage of the company, we may prioritize different AICE traits. An early-stage startup may prioritize ambiguity and execution while a mature tech company might need more influence and complexity management.
В зависимости от роли и стадии компании мы можем расставлять приоритеты по разным чертам AICE. Стартап на ранней стадии может ставить во главу угла неопределённость и исполнение, тогда как зрелой технологической компании может потребоваться больше влияния и управления сложностью.
Finally, it’s worth reflecting which technical and non-technical qualities can be coached, and which can only be hired. IMHO, most technical skills can be coached, while traits such as ownership, resourcefulness, and grit are likely hired. Being clear on the qualities to coach vs. hire will help with identifying candidate gaps that are truly dealbreakers.
Наконец, стоит поразмыслить, какие технические и нетехнические качества можно развить, а какие можно только нанять. ИМХО, большинство технических навыков поддаётся развитию, тогда как такие черты, как чувство собственности, находчивость и упорство, скорее нанимаются. Ясность в том, какие качества развивать, а какие нанимать, поможет выявить пробелы кандидата, которые действительно являются непреодолимыми.
• • •
• • •
So far, we’ve focused on what to interview for in ML/AI roles. Next, we’ll discuss how to calibrate the phone screen, run an interview loop, and conduct a debrief. (An interview loop typically consists of multiple interviewers who assess for various aspects.) Then, we’ll wrap up with some tips for interviewers and hiring managers.
До сих пор мы фокусировались на том, что оценивать на собеседовании для ML/AI-ролей. Далее обсудим, как калибровать телефонный скрининг, проводить цикл интервью и дебриф. (Цикл интервью обычно состоит из нескольких интервьюеров, оценивающих различные аспекты.) Затем завершим советами для интервьюеров и нанимающих менеджеров.
Calibrating the phone screen for loop success
Калибровка телефонного скрининга для успеха цикла
Before investing in an interview loop, most hiring managers conduct a phone screen. The goal is to select candidates who’ll have a high likelihood of success in the interview loop. Interview loops are costly, often requiring a game of Tetris across multiple interviewer schedules. A typical loop might involve five interviews of an hour each, plus a 30-minute pre-brief and debrief involving all interviewers. That’s 10 hours of collective time invested in a single candidate, excluding the time taken to prepare and write feedback.
Прежде чем вкладываться в цикл интервью, большинство нанимающих менеджеров проводят телефонный скрининг. Цель — отобрать кандидатов с высокой вероятностью успеха в цикле интервью. Циклы интервью обходятся дорого и часто требуют «игры в Tetris» по расписаниям нескольких интервьюеров. Типичный цикл может включать пять интервью по часу каждое плюс 30-минутный пре-брифинг и дебриф с участием всех интервьюеров. Это 10 часов коллективного времени, вложенных в одного кандидата, не считая времени на подготовку и написание обратной связи.
Given how costly a loop is for candidates and interviewers, a rule of thumb from Working Backwards is for the phone screen to be sufficiently selective. The hiring manager should advance candidates that they believe will perform well in the interview loop. Of course, we may need to recalibrate the phone screen if the pipeline is sparse or if the number of candidates making it to the loop is extremely low. But in general, a rigorous phone screen reduces the number of borderline candidates who end up struggling in the interview loop.
Учитывая, насколько дорог цикл для кандидатов и интервьюеров, эмпирическое правило из книги Working Backwards — делать телефонный скрининг достаточно избирательным. Нанимающий менеджер должен продвигать дальше кандидатов, которые, по его мнению, хорошо справятся в цикле интервью. Конечно, возможно, придётся перекалибровать скрининг, если воронка скудна или число доходящих до цикла кандидатов крайне мало. Но в целом строгий телефонный скрининг снижает количество пограничных кандидатов, которые в итоге испытывают трудности в цикле интервью.
After this detailed phone screen, the hiring manager decides whether they are inclined to hire the candidate based on the data they’ve collected so far. If so, then the candidate will be invited for an in-house interview. Sometimes, the hiring manager isn’t sure about a candidate but still invites them to go through the interview loop, hoping that this will assist in the hiring decision. This is a mistake. In most cases, the questionable candidate will not get the job, and a lot of time will have been wasted in the process. The hiring manager should not bring the candidate in for the time-consuming and expensive interview loop unless they are inclined to hire them after the phone interview. — Working Backwards
После такого детального телефонного скрининга нанимающий менеджер решает, склонен ли он нанять кандидата на основе собранных к этому моменту данных. Если да, кандидата приглашают на очное интервью. Иногда нанимающий менеджер не уверен в кандидате, но всё равно приглашает его пройти цикл интервью, надеясь, что это поможет принять решение о найме. Это ошибка. В большинстве случаев сомнительный кандидат работу не получит, а в процессе будет потрачено много времени. Нанимающий менеджер не должен приглашать кандидата на трудоёмкий и дорогой цикл интервью, если он не склонен нанять его после телефонного собеседования. — Working Backwards
Running the interview loop and debrief
Проведение цикла интервью и дебрифа
It helps to have a pre-brief before the interview loop, especially if some interviewers are unfamiliar with role requirements or come from different teams. This is where the hiring manager can align the loop on what’s needed for the role, and what to look out for.
Полезно провести пре-брифинг перед циклом интервью, особенно если некоторые интервьюеры не знакомы с требованиями к роли или приходят из других команд. Именно здесь нанимающий менеджер может настроить цикл на то, что нужно для роли и на что обращать внимание.
For example, the loop would need to know if the role focuses more on financial analysis and A/B tests, or training and serving recsys models, or RAG and building LLM-powered user experiences. It’s also helpful to share about the level of ambiguity, influence, complexity, and execution expected for the role, or if there are any company values that interviewers should collect data points on.
Например, циклу нужно знать, ориентирована ли роль больше на финансовый анализ и A/B-тесты, или на обучение и обслуживание recsys-моделей, или на RAG и создание пользовательских продуктов на основе LLM. Также полезно рассказать об ожидаемом уровне неопределённости, влияния, сложности и исполнения для роли, или о том, есть ли какие-либо ценности компании, по которым интервьюерам следует собрать данные.
For the actual interviews, we’ve found the STAR format to be effective at gathering relevant data points based on past behavior and work:
Для самих интервью мы обнаружили, что формат STAR эффективен для сбора релевантных данных на основе прошлого поведения и работы:
Ситуация/Задача (Situation/Task): контекст и масштаб проблемы, включая ставки и потенциальное влияние, если не действовать. Также назначенная кандидату ответственность. Действие (Action): роль, которую сыграл кандидат, возникшие трудности, применённые навыки и знания. Также был ли он ключевым драйвером и как именно внёс вклад? Результаты (Results): измеримые итоги, такие как влияние на клиентов, новые возможности, выручка или экономия затрат. Также как он выбирал и измерял эти метрики?
As we guide the candidates through their STAR response, there will be opportunities to dive deeper with follow-up questions around both the technical and non-technical aspects of their work and experience:
По мере того как мы проводим кандидатов через их ответ по STAR, появятся возможности углубиться с уточняющими вопросами как по техническим, так и по нетехническим аспектам их работы и опыта:
Ситуация/Задача: данные о неопределённости и сложности исходной проблемы, а также о том, как кандидат сформулировал постановку задачи и критерии успеха. Действие: данные о том, как кандидат влиял на других, справлялся с ограничениями и компромиссами, а также о трудностях и технических деталях его решения. Результат: данные об исполнении при ограниченных ресурсах и в срок, а также о результатах и о том, как он их измерял.
As we gather data points, it’s important to clarify the candidate’s direct contributions vs. those of the broader team. Some candidates may overstate their role while others may be overly humble. Asking targeted questions can help tease this out: “What was the hardest decision made on the project and who made that call?” or “Can you share an example of when you disagreed with the team?” Strong candidates will give nuanced responses that acknowledge the role others played while being clear about their contribution.
Собирая данные, важно прояснять прямой вклад кандидата по сравнению с вкладом более широкой команды. Одни кандидаты могут преувеличивать свою роль, другие — быть чрезмерно скромными. Целенаправленные вопросы помогают это вытянуть: «Какое самое трудное решение было принято на проекте и кто его принял?» или «Можете привести пример, когда вы не соглашались с командой?» Сильные кандидаты дадут нюансированные ответы, которые признают роль других, оставаясь чёткими в отношении собственного вклада.
Watch out for less seasoned candidates rambling or going off-tangent, especially if the question is uncomfortable. As the interviewer, our job is to steer the interview and gather the data points needed for the hiring manager to make a good decision. Thus, if the response is headed in an unproductive direction, we can politely interject and redirect: “In the interest of time, let’s move on to …” or “I’d love to dig into your role in that project …” Don’t be afraid to firmly but gently guide the candidate through the interview.
Остерегайтесь менее опытных кандидатов, которые растекаются мыслью или уходят в сторону, особенно если вопрос неудобный. Как интервьюер, наша задача — направлять интервью и собирать данные, нужные нанимающему менеджеру для принятия хорошего решения. Поэтому, если ответ уходит в непродуктивное русло, можно вежливо вмешаться и перенаправить: «В интересах времени давайте перейдём к…» или «Мне бы хотелось углубиться в вашу роль в том проекте…» Не бойтесь твёрдо, но мягко вести кандидата через интервью.
Sometimes, a candidate’s first STAR example falls flat and doesn’t provide the data points needed for the role and level. If so, consider pivoting and asking the candidate to share another example. For instance, if we have a 15-minute block for a question and can tell that the response doesn’t demonstrate what’s needed by the 10-minute mark, make the call to cut it short and ask for another example. Sometimes, this can elicit a stronger example with solid data points across both technical and non-technical aspects, even within five minutes. Having different questions that assess for the same data point helps.
Иногда первый пример кандидата по STAR оказывается слабым и не даёт данных, нужных для роли и уровня. В таком случае подумайте о том, чтобы сменить направление и попросить кандидата привести другой пример. Например, если у нас есть 15-минутный блок на вопрос и к 10-й минуте видно, что ответ не демонстрирует нужного, примите решение прервать его и попросить другой пример. Иногда это позволяет получить более сильный пример с надёжными данными как по техническим, так и по нетехническим аспектам, даже за пять минут. Полезно иметь разные вопросы, оценивающие один и тот же показатель.
After the interview, interviewers should spend 15 - 30 minutes independently writing feedback as well as making an initial “hire” or “no hire” vote. Writing feedback independently prevents groupthink and biased individual assessments. The feedback should be anchored on data points for the specific technical and non-technical aspects the interviewer was responsible for.
После интервью интервьюерам следует потратить 15–30 минут на самостоятельное написание обратной связи, а также на первоначальный голос «нанимать» или «не нанимать». Самостоятельное написание обратной связи предотвращает групповое мышление и предвзятые индивидуальные оценки. Обратная связь должна опираться на данные по конкретным техническим и нетехническим аспектам, за которые отвечал интервьюер.
Once all interviewer feedback has been logged, all interviewers get together for the debrief. (In some companies, this may just involve the hiring manager, recruiter, and a senior team member.) All interviewers spend some time to review each others’ written feedback and potentially update their initial vote based on the additional data points they now have. Sometimes, if there are conflicting data points from multiple interviewers, discussion is needed to understand the candidate better.
После того как обратная связь всех интервьюеров зафиксирована, все интервьюеры собираются на дебриф. (В некоторых компаниях это может включать лишь нанимающего менеджера, рекрутера и старшего члена команды.) Все интервьюеры тратят некоторое время на изучение письменной обратной связи друг друга и могут скорректировать свой первоначальный голос на основе появившихся у них дополнительных данных. Иногда, если есть противоречивые данные от нескольких интервьюеров, нужна дискуссия, чтобы лучше понять кандидата.
Ultimately, the debrief must conclude with a decision on whether to extend an offer. The vote doesn’t necessarily need to be unanimous, but there shouldn’t be strong objections against hiring a candidate. If an interviewer feels strongly enough to say something like “I’ll quit if we hire this person,” that’s a red flag to discuss—what did the interviewer observe that others might have missed? Overall, while consensus is ideal, the hiring manager owns the final decision.
В конечном счёте дебриф должен завершиться решением о том, делать ли оффер. Голосование не обязательно должно быть единогласным, но не должно быть сильных возражений против найма кандидата. Если интервьюер настолько уверен, что готов сказать что-то вроде «Я уволюсь, если мы наймём этого человека», — это тревожный сигнал, который стоит обсудить: что заметил этот интервьюер, что другие могли упустить? В целом, хотя консенсус идеален, окончательное решение принадлежит нанимающему менеджеру.
For interviewers: Candidates are rough diamonds
Для интервьюеров: кандидаты — это неогранённые алмазы
Even for the most qualified candidates, the interview process can be daunting. Thus, making the candidate feel comfortable goes a long way in helping them perform their best. It can be as simple as offering a quick bathroom break before starting your interview, or a word of encouragement that they’re nearly done with the loop.
Даже для самых квалифицированных кандидатов процесс собеседования может быть пугающим. Поэтому помочь кандидату почувствовать себя комфортно — это многое решает в том, чтобы он показал свой лучший результат. Это может быть так же просто, как предложить быстрый перерыв на туалет перед началом вашего интервью или ободряющее слово о том, что он почти завершил цикл.
It also helps to approach each interview with the mindset that the candidate is a diamond in the rough. Thus, our job is to uncover their stengths and potential. This doesn’t mean to lower the bar, but to give them the benefit of the doubt and work together to discover their abilities. You can even make this explicit in the interview intro. Let them know up front that your goal is to help the hiring manager gather as many data points as possible. This puts the interview in a collaborative mood and eases some of the interview anxiety.
Также помогает подходить к каждому интервью с установкой, что кандидат — это алмаз, требующий огранки. Поэтому наша задача — раскрыть его сильные стороны и потенциал. Это не значит снижать планку, а значит давать ему презумпцию доверия и совместно открывать его способности. Это можно даже проговорить явно во вступлении к интервью. Дайте ему сразу знать, что ваша цель — помочь нанимающему менеджеру собрать как можно больше данных. Это задаёт интервью атмосферу сотрудничества и снимает часть тревоги.
Finally, think of each candidate as a customer of your business or a user of your product. Regardless of whether we eventually hire the candidate, strive to make the interview a valuable experience that helps them grow. While they may not be the right fit now, they could be a strong hire down the road or refer other great talent your way.
Наконец, думайте о каждом кандидате как о клиенте вашего бизнеса или пользователе вашего продукта. Независимо от того, наймём ли мы кандидата в итоге, стремитесь сделать интервью ценным опытом, который помогает ему расти. Пусть сейчас он и не подходит, но он может стать сильным сотрудником в будущем или порекомендовать вам других талантливых людей.
For hiring managers: Sell on mission & talent density
Для нанимающих менеджеров: продавайте миссию и плотность талантов
While compensation is important, it’s rarely the primary factor for in-demand candidates who likely have multiple competitive offers. Instead, consider attracting top talent via the organization’s mission, the talent density of the team, and the manager who will develop them. Thus, sell candidates on the ambitious problem they’ll solve, the opportunity to work with exceptional team members, and their personal growth.
Хотя компенсация важна, она редко становится главным фактором для востребованных кандидатов, у которых, скорее всего, есть несколько конкурентных офферов. Вместо этого подумайте о привлечении лучших талантов через миссию организации, плотность талантов команды и менеджера, который будет их развивать. Поэтому продавайте кандидатам амбициозную задачу, которую они будут решать, возможность работать с исключительными коллегами и их личный рост.
That said, set the right expectations. Don’t sugarcoat the role. If there’s unglamorous work that needs to be done, such as setting up data infra and pipelines, be upfront about it. Overselling the position will likely lead to disappointment and regrettable attrition. It’s better to not hire a candidate who’s not the right fit than to bring them on with incorrect expectations and have them leave within a few months.
Тем не менее задавайте правильные ожидания. Не приукрашивайте роль. Если есть неблагодарная работа, которую нужно выполнить, например настройка инфраструктуры и пайплайнов данных, говорите об этом прямо. Перепродажа позиции, скорее всего, приведёт к разочарованию и нежелательной текучке. Лучше не нанять кандидата, который не подходит, чем взять его с неверными ожиданиями и потерять через несколько месяцев.
Finally, be prepared for hiring to take time, especially for more senior roles. In general, it takes a few months to hire a junior/mid-level IC while senior roles can take up to a year. Also, the best candidates are usually not looking out—they’re too busy learning, building, and having fun in their work. Nonetheless, it doesn’t hurt to start building relationships wherever they graze, be it meetups, conferences, hackathons, or simply online.
Наконец, будьте готовы к тому, что наём займёт время, особенно для более старших ролей. В целом найм junior/mid-level IC занимает несколько месяцев, тогда как старшие роли могут занять до года. Кроме того, лучшие кандидаты обычно не в поиске — они слишком заняты учёбой, созданием и удовольствием от своей работы. Тем не менее не повредит начать выстраивать отношения везде, где они появляются, — будь то митапы, конференции, хакатоны или просто онлайн.
• • •
• • •
Finally, we’ll conclude with an opinionated take on the traits that strong hires have: hunger, judgment, and empathy.
Напоследок мы завершим субъективным взглядом на черты, которыми обладают сильные кандидаты: голод, здравое суждение и эмпатия.
Hunger shows up as having bias for action, being able to learn fast, and the grit to push through challenges. In startups, this helps candidates adapt quickly as the startup iterates toward product-market fit. In larger organizations, this helps new hires push through technical and organizational challenges that might discourage others.
Голод (Hunger) проявляется как склонность к действию, способность быстро учиться и упорство, чтобы прорываться сквозь трудности. В стартапах это помогает кандидатам быстро адаптироваться, пока стартап итерирует к product-market fit. В крупных организациях это помогает новым сотрудникам преодолевать технические и организационные препятствия, которые могли бы обескуражить других.
IMHO hunger is more hired than coached. While budget and time constraints can simulate urgency, it’s a poor substitute for the intrinsic drive that gets shit done.
ИМХО, голод скорее нанимается, чем развивается. Хотя ограничения бюджета и времени могут имитировать срочность, это плохая замена внутреннему драйву, который доводит дело до конца.
Judgement is the hard-won intuition to distinguish between what will work and what’s a wild goose chase or dead end. Judgment helps one make pragmatic decisions, think several steps ahead, and be decisive in the face of uncertainty. In the context of ML, this could be making a design decision to focus on techniques that work well with sparse data for cold-start recommendations, or deciding not to focus on chat for LLM-powered products.
Здравое суждение (Judgement) — это с трудом добытая интуиция, позволяющая отличить то, что сработает, от погони за миражом или тупика. Суждение помогает принимать прагматичные решения, думать на несколько шагов вперёд и быть решительным перед лицом неопределённости. В контексте ML это может быть проектное решение сфокусироваться на техниках, хорошо работающих с разреженными данными для рекомендаций при холодном старте, или решение не делать ставку на чат для продуктов на основе LLM.
While judgment can be cultivated, it takes time. The impact of design decisions may only become apparent after 12 - 18 months. Thus, for roles that need good judgment, it may be easier to hire for a track record of good decisions than to develop it on the job.
Хотя суждение можно культивировать, это требует времени. Эффект проектных решений может проявиться лишь через 12–18 месяцев. Поэтому для ролей, требующих хорошего суждения, может быть проще нанять кандидата с послужным списком хороших решений, чем развивать его на рабочем месте.
Empathy is the genuine interest in customers, the organization, and the team. This may show up as passion for the mission/product and how it helps customers. Empathy makes it easier to build trust, empower others, and foster productive relationships. People with empathy are also better communicators because they “seek first to understand, then to be understood”. This is especially crucial for senior roles who may have to influence without authority, navigate delicate organization challenges, and moderate hotly debated topics.
Эмпатия (Empathy) — это искренний интерес к клиентам, организации и команде. Она может проявляться как страсть к миссии/продукту и к тому, как он помогает клиентам. Эмпатия облегчает выстраивание доверия, расширение возможностей других и поддержание продуктивных отношений. Люди с эмпатией также лучше коммуницируют, потому что они «сначала стремятся понять, а затем быть понятыми». Это особенно важно для старших ролей, которым может приходиться влиять без формальной власти, ориентироваться в деликатных организационных вызовах и сглаживать остро обсуждаемые темы.
Empathy is likely innate and thus mostly hired. While there are techniques to demonstrate empathy, they’re superficial if there isn’t a sincere interest in others and their challenges.
Эмпатия, скорее всего, врождённа и потому в основном нанимается. Хотя есть техники, чтобы продемонстрировать эмпатию, они поверхностны, если нет искреннего интереса к другим и их трудностям.
Okay, that’s all we had. Thanks for reading this long write-up! If you’re actively looking for an ML/AI role, check out Jason’s job board. Also, what other interview practices have served you well? Please comment below or DM me!
Что ж, это всё, что у нас было. Спасибо, что прочитали этот длинный материал! Если вы активно ищете ML/AI-роль, загляните на доску вакансий Jason. А какие ещё практики собеседований хорошо вам послужили? Пожалуйста, оставьте комментарий ниже или напишите мне в DM!
If you found this useful, please cite this write-up as:
Если этот материал оказался вам полезен, пожалуйста, цитируйте его так:
Yan, Ziyou. (Jul 2024). How to Interview and Hire ML/AI Engineers. eugeneyan.com. https://eugeneyan.com/writing/how-to-interview/.
Yan, Ziyou. (Jul 2024). How to Interview and Hire ML/AI Engineers. eugeneyan.com. https://eugeneyan.com/writing/how-to-interview/.
or
или
@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/}
}
@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/} }
Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.
Присоединяйтесь к 11 800+ читателям, получающим обновления о машинном обучении, RecSys, LLM и инженерии.