Собесы в Цельсе

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

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

Например, некоторые особенности нашей компании можно описать так:

• Стартап, но уже не в фазе рождения, сложилась определённая культура работы и общения, в ML-отделе больше 20 человек
• Достаточно research-heavy деятельность, количество DL-задач, связанных с генерацией и имплементацией гипотез, выше среднего
• При этом это не research-лаба, 5 медицинских ИИ-систем в проде, их нужно поддерживать, мониторить и обновлять
• Нет возможности делать безумные офферы сильно выше рынка
• Люди достаточно редко уходят, иногда появляются новые проекты, но в целом в массовом найме нет необходимости, предпочтение отдаётся точечному найму

Всё это и многое другое, естественно, влияет на то, как мы выстраиваем процессы найма - поиск кандидатов, собес, принятие решений. Рекомендации в стиле “тестовые дают только дебилы”, “лайвкодинг не нужен”, “технические собесы - прошлый век” хороши для вирусных твитов или постов в ТГ-каналах, но достаточно бесполезны вне контекста конкретной компании. Сегодня мы хотим рассказать, как у нас устроен процесс собеседования, почему были приняты те или иные решения, и какие сохранились слабые места. В подготовке этого поста участвовали оба автора этого канала и наш коллега, Антон Голубев (вот его крутое видео про парный DS).

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

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

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

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

• Первый контакт, реакция человека, стиль общения уже даёт немало информации о совпадении вайбов, целей и мотивации
• HRы обычно пишут более сухо и официально (иногда это поддаётся настройке), а я сразу начинаю шпарить так, как принято общаться у нас - с шутками и без капли формализма. Некоторым кандидатам это может не нравиться, но тогда мы, скорее всего, и не сойдёмся в вопросах culture fit. Понимаю, что нарываюсь на критику и поднятые брови за этот пойнт, мол, это работа, а не клуб друзей и не балаган, но мы когда-то решили так и пока не пожалели. Чаще всего кандидаты, которые нам нравятся, ценят такую прямоту, и наоборот проникаются к компании
• Есть возможность сразу, без посредников, задать вопросы кандидату и ответить на возникшие вопросы о компании
• Мне не жалко на это тратить время, потому что найм умных, весёлых, креативных ребят за адекватные деньги - это (на данный момент) одна из моих ключевых задач в роли руководителя 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) Тестовое. Тестовое мы раньше давали постоянно, и они, как мне кажется, даже были интересными. Мы могли попросить: 

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

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

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