Как стать автором
Обновить
Dodo Engineering
О том, как разработчики строят IT в Dodo

Наш первый обед вместе: почему и как мы проводим тестовый день

Время на прочтение5 мин
Количество просмотров30K
Привет, Хабр! Пару месяцев назад мои коллеги рассказывали про расширение команды в 5 раз: от 50 тогда до 250 разработчиков к концу 2020 года. Как вы могли догадаться, сейчас мы уделяем много внимания найму. При этом, мы не готовы «брать количеством», нанимая всех подряд, мол «потом разберёмся». Нам важно, чтобы человек действительно стал частью нашей команды на годы вперёд. Именно этот мотив привёл нас когда-то к новому формату собеседований – тестовому дню. Про него и пойдёт речь под катом.



Серия статей про собеседования:
1. Наш первый обед вместе: почему и как мы проводим тестовый день.
2. Я прочитал 80 резюме, у меня есть вопросы.
3. Собеседование в Додо Пиццу.
4. Уходя уходи: почему не стоит принимать контроффер.
5. Спасибо за собеседование, мы ответим о нашем решении… сейчас.

Спойлер с цифрами.
За 1,5 года мы наняли более 40 человек и от нас ушло всего 4 разработчика: один ушёл запускать свой бизнес, а остальные переехали в Европу.

Интро


Чтобы мы с кандидатом могли хорошо узнать друг друга, существует весьма длинный пайплайн найма:

  • собеседование HR,
  • техническое собеседование,
  • собеседование с CTO.

Последнее, кстати, весьма важно: Саша мастер разговоров по душам, умеет выводить на откровенный разговор даже самых суровых и замкнутых гиков.

Помимо всего этого, мы проводим с кандидатами тестовый день. Казалось бы, зачем ещё день? Что мы хотим узнать о кандидате и что хотим ему показать? Да и кто вообще на это согласится?!

Тестовый день в Додо


Начать проводить тестовые дни было непростым решением. Команда HR была не в восторге от ещё большего удлинения пайплайна найма: «Хорошие специалисты не будут столько ходить к нам, у них уже есть несколько офферов на руках!» – говорили они. Однако, было и другое мнение. Тестовый день – уникальная возможность для потенциального сотрудника узнать о реальных условиях в компании, не устраиваясь туда на работу. Например:

  • Узнать о реальных условиях труда. Какие рабочие места, мебель, компьютеры. Есть ли окна в помещениях, где сидят IT-шники (ведь часто их сажают в помещения без окон: «всё равно целый день в свои мониторы смотрят»).
  • Узнать с кем придётся работать. Тимлид, который проводит собеседование – это здорово, но работать тебе придётся в команде. И посмотреть, из кого она состоит, до принятия оффера – это точно не лишнее. Представьте, что вы будете работать в паре с одним из разработчиков и у вас будет возможность подсмотреть за другими парами и понять, сможете ли вы работать бок о бок с этими людьми.

    «Бок о бок» в буквальном смысле. Мы активно практикуем парное программирование. Работать в паре гораздо эффективнее, особенно это касается недавно пришедших к нам разработчиков. И тестовый день даёт уникальную возможность провести «тест-драйв» парной работы лично.
  • Узнать чем реально придётся заниматься. Все эти списки cutting edge technologies, которые указывают в вакансиях – это здорово, у нас самих он длиннее косы Рапунцель. Но он редко имеет отношение к текущим задачам, на которые вас и будут брать. Хорошо бы самому взглянуть на бэклог, на код продукта и заплакать понять, что придётся делать и хочется ли этим заниматься.
  • Узнать об инструментах, которые придётся использовать. Узнать на практике о правилах кодирования и как они соблюдаются. Например, у нас принято работать в Rider, а не Visual Studio. Это может быть настолько непривычно, что станет критичным при принятии решения о выходе к нам. Подобные нюансы есть почти везде (как правило, в силу исторических причин) и узнавать о них лучше до подписания трудового договора.
  • Узнать как проходит реальный рабочий день в команде. В любой приличной команде у вас будут, как минимум, ежедневные стендапы. Важно увидеть, как они проходят, чтобы понять, как общаются между собой члены команды, какая в ней атмосфера. В Додо мы идём несколько дальше и приглашаем кандидата на общие публичные активности текущего дня: devForum, planning или review. У нас что-то происходит каждый день, поэтому есть возможность шире взглянуть на взаимодействие потенциальных коллег между собой.

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

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

Безусловно, тестовый день это и возможности для компании взглянуть на кандидата в деле:

  • Мы хотим надёжно распознавать «мастеров собеседований». Лучший способ сделать это – посмотреть на человека в процессе реальной работы. Насколько быстро он начинает ориентироваться в новом коде? Чтение кода – это, по некоторым оценкам, до 70% времени разработчика. Заодно смотрим, какие решения он предлагает по задаче, как пишет код, следует ли принятым стандартам.
  • Мы хотим понять, насколько человек активен, способен сам выступать инициатором решения. Безусловно, сразу начать предлагать решения по незнакомому коду сложно. Но в больших системах, как Dodo IS, ты будешь сталкиваться с незнакомым кодом и после года работы. Если человек на тестовом дне сидит с видом «ну давай, покажи мне, как это делать» – это плохой знак.
  • Мы хотим узнать, насколько человек «комфортен» в работе. Это особенно важно при парной работе: не будет ли потенциальный коллега «вырывать клавиатуру» у партнёра? Сможет ли спокойно убеждать его в правильности своих решений или объяснять его ошибки? Парная работа – это очень тесное взаимодействие интеллектов и новый сотрудник не должен быть «токсичным» в таком взаимодействии.

Исходя из написанного выше, «тестовый день» никак не может быть меньше 5 часов. Ещё мы стараемся брать кандидата на обед, это даёт ему возможность посмотреть на потенциальных коллег в неформальном общении. И нам взглянуть на кандидата за пределами офиса.

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

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

Результаты


И действительно, за 1,5 года мы наняли более 40 человек и от нас ушло всего 4 разработчика: один ушёл запускать свой бизнес, а остальные переехали в Европу.

Популярные вопросы про тестовый день


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

  • Оплачивается ли тестовый день? Нет.
  • Как быть, если я в другом городе? Если вакансия подразумевает работу в офисе, нужно приехать в этот офис на тестовый день. Что логично. В противном случае, не получится узнать ничего из списка выше.
  • Ходить на обед обязательно? Нет. Можно принести своё — так даже лучше, если планируете всегда есть своё. Сможете узнать, подходит ли наша кухня для ваших обедов.
  • Что взять с собой? Зимой стоит взять сменку – будет удобнее. Больше ничего.

Хотите попробовать тестовый день? Приходите – проведём!
Теги:
Хабы:
Всего голосов 44: ↑33 и ↓11+22
Комментарии118

Публикации

Информация

Сайт
dodoengineering.ru
Дата регистрации
Дата основания
Численность
201–500 человек
Местоположение
Россия