Привет, Хабр!
Хочу поделиться опытом поиска стажеров - аналитиков данных. Статья может быть интересна тимлидам аналитики, а при некоторой адаптации — и для лидов других направлений. Скорее всего, какие-то подходы вы найдете спорными, давайте дискутировать. Кандидатам на стажерские позиции статья тоже может пригодиться, но все секреты не выдам :)
Сам я пришел к аналитике немного извилистым путем: начинал с программирования сложных технических и математических задач, продолжил, создавая хранилища и платформы для аналитики, после чего стал лидировать направление аналитики в компании реального сектора. Постепенно переходя от оптимизации абстрактных вещей к вполне конкретным миллиардам, которые дополнительно получает наша компания. Аналитика хороша тем, что это комбинация технически интересных задач и результатов прямо сейчас.
Почему стоит брать стажеров? Даже сейчас лучшие умы находят себе хорошее место задолго до окончания университета, поэтому если хотите получить к себе в команду таких, нужно подсуетиться. Холивар на тему "брать стажеров или нет" оставлю на постскриптум. А сейчас расскажу о сложностях, с которыми столкнулись, и изложу относительно простой алгоритм, выработанный для их решения. Подход заключается в том, что оценивается не столько правильный ответ на прямой вопрос, сколько большое количество сопутствующих паттернов поведения.
В чем сложность?
Хороший аналитик обладает практически несовместимым в одном человеке набором качеств. Он должен хорошо знать математику, быть технарем, обладать продуктовым и бизнесовым мышлением… Все это надо проверить. Причем, в случае найма стажеров надо оценить не столько текущее состояние, сколько потенциал. Потенциал же определяется образовательной базой, способностью обучаться, самостоятельному поиску, независимостью мышления и коммуникабельностью.
Задача выбора осложняется тем, что входящий поток кандидатов может быть очень большой. В последний раз я просмотрел более чем 800 одинаковых резюме: студент курса N такого-то ВУЗа, без опыта работы. Это ограничивает применение традиционных приемов или методик типа STAR, поскольку они опираются на рабочий опыт, которого нет. Можно опираться на учебный опыт, но это лишь покажет, как кандидат вел себя в нерелевантных условиях.
Вкратце про STAR
Я расскажу своими словами, но рекомендую почитать подробнее по ссылке выше.
Есть очень простое соображение: на интервью избегать общих рассуждений, рассматривать только конкретные ситуации в прошлом. Если вы слышали про CustDev или читали The Mom Test — это почти оно, только применительно к интервью.
Это позволяет отделить теоретиков от практиков. Обе группы считают, что заниматься спортом полезно и надо делать это регулярно. Отличить их можно вопросом “когда вы последний раз занимались спортом?” и углубившись в детали. На работе от теоретиков толку не будет.
Плохой вопрос: Важно ли смотреть статистику использования вашего продукта?
Ответ: Я убежден, что очень важно знать, как и кем используется ваш продукт, из этого можно получить для себя массу полезной информации.
Из такого ответа нельзя сделать никаких выводов, ни хороших, ни плохих.
Вопрос получше: расскажите, когда в последний раз вашим продуктом не пользовались, что вы предприняли?
Ответ: Отчет, который мы сделали в начале прошлого года, был использован всего 2 раза. Тогда я решил позвонить главному заказчику и выяснить в чем дело. Но он не взял трубку, и я больше не пытался.
Тут уже можно сделать выводы. Хороший вывод — что на проблему вообще обратили внимание, статистику мониторили. Плохой вывод — что для решения проблемы не хватило настойчивости.
Так вот, STAR задает рамки — что обязательно нужно выяснить, чтобы сделать адекватные выводы:
Situation — ситуацию, в которой находился человек
Task — что хотел достичь
Action — что для этого предпринимал
Result — и что в итоге получилось
Используя STAR в рассмотренной выше ситуации вы бы узнали, что это была заказная разработка, и задач по повышению популярности отчета команде не ставилось. И это знание несколько сместит вашу оценку.
Можно попробовать использовать STAR, спрашивая про учебный опыт, но ситуации и задачи скорее всего будут очень сильно отличаться от того, что возникает на работе.
Оговорюсь, что в нашей стажерской программе мы берем только студентов старших курсов: это формальное ограничение. Но именно на позицию стажера я бы других и не рассматривал, потому что на младших курсах работать некогда, а после окончания ВУЗа уже не стажерскую позицию пора искать.
Правда, тут не покрывается один кейс: иногда в ИТ успешно работают люди без высшего образования вообще, а мы их не возьмем, это минус.
Отбор состоит из нескольких этапов:
1 этап — отбор резюме
На этом этапе HR отбирают студентов из релевантных технических университетов. Если в воронке много кандидатов, то можно брать только топовые институты. Причины две:
Там дают хорошую фундаментальную базу по математике. Если тут будет пробел, то восполнить его на работе не получится.
Если кандидат сумел поступить в хороший институт, то это свидетельствует о его мотивации.
Но в целом в хороших институтах не дают хороших навыков аналитика. У меня порой даже обратное ощущение. В не самых лучших институтах студенты понимают бесполезность даваемых знаний, они сразу ищут работу, и получают там необходимые навыки. Но, в конце концов, скиллы я дам стажеру легко, а фундаментальное образование — нет.
Кроме хороших ВУЗов, большим плюсом считаю следующее:
Есть какой-то личный проект, напрямую не связанный с учебой, который кандидат сделал сам. Это позволяет увидеть как мотивацию, так и достаточную фундаментальную базу.
Есть какой-то совершенно необычный опыт, который стоит рассмотреть отдельно. Например, у нас в воронке был студент - ассистент советника бывшего президента США :)
Уже есть очень релевантный опыт работы и результаты.
Кстати, нерелевантный опыт, типа McDonalds, тоже считаю плюсом, так как показывает хорошую мотивацию.
Альтернативный подход — давать всем тестовое задание. Тогда все в равных условиях, оценка только по результатам, а не формальным признакам. Но есть минусы. Мои знакомые делятся на тех, кто никогда не делал тестовое задание, и тех, кто делал их большой сплоченной командой. Да-да, не только у вас воронка из сотен кандидатов — у хороших кандидатов воронка из десятков других возможностей, и пары часов на тестовое задание может не найтись. Или же задание сделает не ваш кандидат, а его друг. И еще — нужно потратиться на автоматизацию тестирования, поскольку глазами просмотреть все решения не будет возможности.
2 этап — видеоинтервью
При большой воронке имеет смысл проводить видеоинтервью.
Суть в том, что кандидат самостоятельно в онлайне отвечает на подготовленные вопросы, ответы потом можно посмотреть в записи. У кандидата это занимает 15 минут, а мы на удвоенной скорости вполне можем просмотреть сотню кандидатов, т.к. в большинстве случаев не требуется смотреть полностью. Есть готовые платформы для видеоинтервью, свою писать не нужно.
Кандидаты, которые показались супер-релевантными уже по резюме, в этот этап не попадают. Они не будут отвлекаться на разговор с бездушной машиной, зовите их на собеседование сразу. Таких будет немного. Из оставшихся больше половины не запишут интервью, но наиболее мотивированные запишут. В конце концов, это всего 15 минут.
Начинается интервью с вопроса “Расскажите о себе”. Главная цель — помочь кандидату расслабиться, ведь про себя все могут спокойно рассказать. Времени на ответ дается много. Еще вариант: какое ваше самое большое достижение? Вопрос тоже расслабляющий, но иногда тут выявляются какие-то личные приоритеты и ценности.
Далее идут вопросы по хард скиллам, в нашем случае — Python, SQL, BI. Мы задаем вопросы трех видов:
Тривиальный вопрос. Позволяет понять, знает ли кандидат это вообще. Времени давать очень мало, чтоб не успеть загуглить.
Открытый вопрос. "Расскажите какие конструкции в <...> вы знаете". Позволяет определить охват, не гарантируя что кандидат это действительно знает глубоко. Потом проверите.
Хитрый вопрос. Ответ на него не знают многие спецы. 99% кандидатов на него не ответят. И зачем его задавать?
Многие говорят "я не знаю, но могу предположить что ..", и далее следует неправильный ответ. Это вполне нормально, человек попытался предложить хоть какое-то решение. Но иногда кандидаты уверенно отвечают чушь, что точно означает профнепригодность для аналитика.
Тот же самый вопрос (!) потом задается на очном собеседовании. Если кандидат столкнулся с чем-то незнакомым и прошел мимо, то такой любознательности не хватит для нашей работы.
Отмечу, что SQL часто просто нулевой. Многим студентам его просто негде получить. Это не блокер для дальнейшего. Но Python (или R) уже в каком-то виде должен быть.
Из кандидатов я отбираю достойных, и их уже смотрит вся команда. Мы голосуем, и в итоге отбираем человек 10 для следующего этапа.
3 этап — зум собеседование
Пожалуй, это самый ответственный и длительный этап. Я на него подключаю еще и команду, ну как минимум по финалистам команда смотрит запись интервью.
Начинаю с короткого small talk, потом рассказываю в общих словах про позицию и чем мы занимаемся. Дальше вопросы кандидату:
Расскажите о себе. Снова и с той же целью — войти кандидату в комфортный режим.
Когда комфортный режим достигнут, я цепляюсь за какой-то учебный кейс и пытаюсь оценить глубину погружения. Бывают зубрилы, от которых отскакивает вся теоретическая часть и нет абсолютно никакого понимания о чем все это. Например, ошибки разного рода в медицинской диагностике, когда в случае False Negative человек умер, а при False Positive принимал лишний раз безобидное лекарство. Тут рассуждения о площади под ROC кривой не помогают, но обычно именно про это и рассказывают. Хорошо, если кандидат рассуждает про последствия ошибок, которые могут и не быть безобидными в конкретных кейсах.
Задача на логику. Она показывает сообразительность и понимание асимптотических штук. Считаю важным, чтобы аналитик понимал, "а что будет в пределе?".
На задаче очень многие тупят! Это ни о чем не говорит, нужно давать подсказки и направлять решение. В процессе этого можно понять, насколько легко с кандидатом "думать вместе". А я обычно думаю вместе с командой. Если "думать вместе" не получается и подсказки не находят понимания, это довольно плохо, сработаться будет тяжело. Если же находят — задача будет рано или поздно решена.Задача на Python, которую следует решить онлайн с шарингом экрана. Мы предпочитаем не использовать специальных сервисов онлайн собеседований, а просим кандидата продемонстрировать свой экран. Что мы тут смотрим:
Конечно, как человек пользуется поиском! Как он ищет по документации, на каком языке (английский лучше!), быстро ли понимает, то он нашел, или не то. Можно оценить бэкграунд кандидата по поисковым подсказкам, или когда по части ссылок ранее проходили.
Вообще, далеко не все понимают, что можно пользоваться поиском. Но зачем даже профессионалу держать в голове функции для работы с датами для всех 5 языков, которые он активно использует? Прямой вопрос "а можно ли искать" показывает хорошие коммуникативные навыки кандидата.
Один кандидат, удостоверившись что можно пользоваться поиском, начала гуглить не функции с датами, а готовое решение именно этой задачи. Ценю! Но для нашей задачи не помогло.Знаком ли вообще с горячими клавишами или хотя бы с интерфейсом Jupyter, Pycharm или чего-то еще. Именно по владению IDE понятен реальный бэкграунд кандидата.
Вообще, если Python стоит на компьютере кандидата, это уже плюс, скорее всего он когда-то что-то на нем делал. Если не стоит какая-то библиотека, можно посмотреть, сможет ли кандидат её поставить. Вопрос от кандидата "что такое pip?" — это блокер.Если доходит дело до получения ответа, то проверит ли кандидат свой ответ на common sense. При самой частой технической ошибке в итоге получается, что все рейсы авиакомпании задерживаются. А данных за 5 лет. Реально ли, чтобы такая авиакомпания проработала 5 лет?
Бывает, что человек говорит "я вот на Python не особо, вот бы на R порешать". В таком случае я говорю — ок, решайте как привыкли. Забавно, что получал ответ "Ой, а на R я уже два года ничего не писал". Короче, Python можно заменить SQL или R, задача должна это позволять.
Простые и провокационные вопросы по статистике. Один из таких: "Билл Гейтс заходит в случайный бар, где 10 посетителей. В результате этого посетители бара становятся в среднем миллиардерами. Так ли это?"
Если кандидат может порассуждать о выбросах, отличиях медианы и среднего — это хорошо. Можно поспрашивать, когда выбросы нужно игнорировать, а когда нельзя.
Завершается интервью тем, что я рекламирую нашу команду, и рассказываю почему в целом стоит идти именно в эту компанию. Вы должны уметь очень хорошо это продавать, надо тренироваться! Я оставляю это под конец, поскольку при отрицательном исходе этот этап можно пропустить.
Финальное решение
Решение обсуждается всей командой. Это позволяет нивелировать личные симпатии или антипатии к кандидату. Берем только единогласно.
Заключение
Такой подход позволяет оценить множество софт-скиллов параллельно с оценкой хард скиллов. В большинстве вопросов трудно показаться лучше, чем ты есть на самом деле, или наоборот — зафакапиться из-за волнения.
Полагаю, часть приемов можно использовать и при собеседовании опытных аналитиков, но с осторожностью. В этом случае есть хорошие методики типа STAR, которые позволяют относительно достоверно все выяснить.
Итого. Набирайте стажеров, используя подходы,которые обкатали мы. Результат вас может приятно удивить.
P.S. Брать или не брать, that is the question
Стажерские программы имеют массу минусов, вот на мой взгляд главные:
Обучение стажеров требует времени. Если ваш продукт должен будет выйти вчера, то не берите стажеров.
Стажеров кто-то должен учить. Если у вас в аналитике никто сам не шарит, опять же - не берите.
Стажеров нужно уметь продвигать. Если в вашей компании на уровне регламентов зарплаты можно повышать только на 5 процентов в год, то через год ваш стажер будет получать 2x, но в x5 :) Зарплатами дело не ограничивается, должны быть еще соответствующие задачи. Это прям критически важно, самых умных надо продвигать быстро. А не самые умные пусть уходят, вам же лучше.
Но все-таки, почему стоит запускать стажерские программы?
Как я писал вначале, это способ получить в команду лучшие умы. Если у вас нет IT-бренда, то других способов немного.
Проблемы с софт скиллами сотрудника проще всего решить на ранних стадиях карьеры. Напротив, проблемы с тех. скиллами понятно как решать и их проще оценить на собесе.
Наконец, киллер-аргумент :) Мне просто нравится! Развивая других, я развиваюсь и сам.
