Всем привет! Я Жека Никитин, Head of AI в медтех-стартапе «Цельс».

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

Невозможно прожить день и не наткнуться на срач на тему того, как правильно проводить собеседования.  Недавно в ТГ-чате тимлидов был длинный спор на тему «лайвкодинг – ненужный стресс и хрень или важный этап проверки компетенций». Пару недель назад читал в твиттере мнение, что все собесы – говно по умолчанию. А на прошлой неделе обсуждали с коллегами пост Амазона об «идеальном найме».

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

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

• Стартап, но уже не в фазе рождения. Сложилась определённая культура работы и общения, в ML-отделе больше 20 человек.

• Достаточно research-heavy деятельность. Количество DL-задач, связанных с генерацией и имплементацией гипотез, выше среднего.

• При этом это не research-лаба: 5 медицинских ИИ-систем в проде, их нужно поддерживать, мониторить и обновлять.

• Нет возможности делать безумные офферы сильно выше рынка.

• Люди достаточно редко уходят. Иногда появляются новые проекты – но в целом в массовом найме нет необходимости, предпочтение отдаётся точечному найму.

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

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

• Zero bullshit. Найм – это решение не только с нашей стороны, но и со стороны кандидата. Поэтому в общении с ними не должно быть никакой лажи: человек должен обладать всей информацией, необходимой для принятия взвешенного решения. Если берём человека в проект с достаточно серьезным легаси в плане дата-инфраструктуры – прямо говорим об этом. У нас много мата в рабочем общении – предупреждаем заранее, чтоб это не стало неприятным сюрпризом. То же самое касается и вопросов на собесе: 99% вопросов взяты из реальных рабочих задач и ситуаций. Так мы лучше проверяем релевантные навыки и одновременно даём кандидату понять, чем он тут будет заниматься.

• Жить в кайф. Мы делаем всё, чтобы наше взаимодействие с кандидатом было приятным и для него, и для нас. Следим за флоу беседы: если человек начал нервничать или путаться, аккуратно возвращаем собес в спокойное, приятное русло. Обязательно даём подробную обратную связь по итогам собеса и отдельно просим дать фидбек по собесу: что понравилось, что можно было сделать лучше. Очень редко мы выходим с собеса с чувством, что мы потратили время – и, судя по отзывам, похожие ощущения и у наших кандидатов.

Первый контакт

Когда в стартапе было 5 человек-основателей, естественно, всем ML-щикам писал Head of AI тогда ещё пустого отдела – потому что больше было некому. Сейчас в компании более 60 человек, из них треть работает в ML-отделе, появился HR-отдел. Но я по-прежнему предпочитаю писать кандидатам лично. Причин несколько:

1. Первый контакт, реакция человека, стиль общения уже даёт немало информации о совпадении вайбов, целей и мотивации

2. HRы обычно пишут более сухо и официально (иногда это поддаётся настройке), а я сразу начинаю шпарить так, как принято общаться у нас: с шутками и без капли формализма. Некоторым кандидатам это может не нравиться, но тогда мы, скорее всего, и не сойдёмся в вопросах корпоративной культуры. Понимаю, что нарываюсь на критику и поднятые брови за этот пойнт: мол, это работа, а не клуб друзей или балаган. Но мы когда-то решили так – и пока не пожалели. Чаще всего кандидаты, которые нам нравятся, ценят такую прямоту и наоборот проникаются к компании.

3. Есть возможность сразу, без посредников, задать вопросы кандидату и ответить на возникшие вопросы о компании

4. Мне не жалко на это тратить время, потому что найм умных, весёлых, креативных ребят за адекватные деньги – это (на данный момент) одна из моих ключевых задач в роли руководителя ML-отдела

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

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

Для трекинга статуса собесов используем Трелло с примерно такими колонками:

Колонки на доске найма

Кто хочет в последнюю колонку?

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

Собес

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

1) Структура собеса:

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

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

• Просим кандидата рассказать о себе, о своём ML-опыте. Этот шаг тоже проходит, скорее, в формате диалога. Задаём много вопросов, начинаем залезать в технические аспекты работы, выясняем, чем человеку интересно заниматься.

• Техническая часть. Об этом подробнее ниже.

• Немного об условиях работы. Графики, режимы работы, гпушки, перфоманс-ревью, вот это всё.

• Вопросы кандидата.

2) Собесим группой. Часто встречаю мнение, что групповой собес – это стресс для кандидата, размазывание ответственности и так далее. Да, любой собес – это стресс, но если он построен в виде живой, приятной беседы, кажется, что несколько собеседников наоборот снижают градус накала. С нашей стороны присутствуют 2-3 человека: я провожу вступиловку, «продаю» компанию, начинаю беседу о человеке, на этом этапе уже включаются технические эксперты, которых мы выбираем из пула 4-5 человек. Плюсы: 

• складывается более полное мнение о человеке;

• если у кандидата возникли трудности с пониманием вопроса, партнёры всегда могут правильно почуять момент и переформулировать вопрос;

• для разрядки атмосферы можно немного перешутиться между собой.

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

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

4) Скор-карты. Любая встреча должна порождать артефакт – и собес тут не исключение. По итогам собеса каждый его участник заполняет карту, в которой:

• проставляет галочки по ряду субъективных впечатлений (энергичный, увлеченный ML, подходит по духу и так далее);

• оценивает каждый этап технической части (плохо/норм/хорошо);

• описывает свои впечатления в свободной форме;

• заполняет графу для рекомендаций кандидатам и пишет общую рекомендация по офферу по шкале.

5) Нет лайв-кодинга. У нас нет лайв-кодинга, и даже вопросов на Питон толком нет. Это, наверное, самое спорное решение: его правильность до сих пор время от времени обсуждается. 

Главная мотивация – не было ощущения, что мы получаем ценную информацию. Если у человека есть опыт работы в разработке – скорее всего, код он писать умеет. Если человек чистый MLщик – скорее всего, код у него максимум средненький. Как я и говорил, у нас действительно много дип лёрнинга, сеток, кастомизации, задач по повышению метрик, поэтому при прочих равных мы чаще берём хороших MLщиков. С другой стороны, сейчас мы, наконец, дозрели до создания полноценной Data Engineering команды, и там требования уже совсем другие.

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

7) Вопросы на ML-дизайн. Отдельной секцией идут вопросы на дизайн ML-системы. Мы их очень любим, и у нас они имеют следующую форму: берём какую-то ситуацию из нашего опыта, отсекаем лишние детали, чтоб не усложнять, и формулируем проблему. Есть такие-то данные, такие-то ограничения по бюджету на разметку, такая-то бизнес задача. Что и как будем обучать? Лично на мой вкус, одна из самых информативных секций, причем подходит как джунам, так и синьорам, варьируется глубина погружения.

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

9) Тестовое. Тестовое мы раньше давали постоянно, и они, как мне кажется, даже были интересными. Мы могли попросить: 

• имплементировать какую-то интересную, но не очень популярную статью;

• сравнить разные способы решения какой-то нестандартной задачи (например, ординальной регрессии);

• хитрым образом кастомизировать какую-нибудь популярную архитектуру под необычную задачу;

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

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

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

Приятных вам собесов – вне зависимости от того, собеседующий вы или собеседуемый!

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML