Всем привет, меня зовут Сергей, я руковожу группой серверных программистов студии Whalekit и активно занимаюсь наймом в эту группу. Сервер пишем на Java — соответственно, нанимаем мы тоже джавистов.
В 2016 году мы выдавали кандидатам тестовое задание, успешным кандидатам назначалось техническое собеседование.
В 2018 мы добавили 45-минутный «мотивирующий на выполнение тестового задания» этап, чтобы кандидаты лучше понимали, соответствует ли вакансия их ожиданиям.
В 2021 мы полностью отказались от тестовых заданий.
Но обо всем по порядку.
Получать выполненные тестовые задания здорово: можно оценить технические навыки и сформировать обширное представление об опыте кандидата, релевантном вакансии. Если, конечно, тестовое релевантно вакансии.
В студии Whalekit мы делаем мобильные игры с богатой метой (апгрейд оружия и персонажей, кланы, прокачка базы, списки лидеров, подбор оппонента по elo-рейтингу). Добрая половина работы серверных программистов — это написание новых и доработка существующих сервисов хранения. Мы храним профиль игрока в MongoDB и обновляем под распределенным локом на redis. В сервисе хранения наград используем постгрес с изоляцией транзакций repeatable read. Есть сервисы, которые просто хранят состояние в redis, а есть такие, логика которых реализована на lua для атомарного исполнения внутри redis.
Наше тестовое выглядит так:
Написать и покрыть тестами класс, считающий лайки, которые ставят игроки друг другу, и сохраняющий их количество в базу данных (интерфейс ниже). Базу данных выбрать самостоятельно с учетом того, что система должна работать под большой нагрузкой и масштабироваться горизонтально. Реализовать на Java.
interface LikeService {
void like(String playerId);
long getLikes(String playerId);
}В выполненных заданиях мы смотрели, в основном, на корректность конкурентного обновления счетчика, обработку ошибок, качество тестов и сам подход к написанию тестов. Так удается сформировать достаточное представление об опыте кандидата в написании такого рода сервисов хранения, очень релевантного целому классу наших задач.
Но и проблем с тестовыми множество. Начнем с того, что, поскольку время на выполнение задания не фиксируется, наниматель не может нормировать результат по времени. Более того, не все выполняют задание самостоятельно.
Бывает и так, что кандидат тратит много времени и сил на тестовое, но не получает преимущества. В сложной архитектуре больше шансов допустить ошибку.
Например, простым в реализации решением будет выбор MongoDB в качестве базы данных. Горизонтальное масштабирование в MongoDB есть из коробки: достаточно использовать playerId в качестве ключа шардирования. Атомарность обновления счетчика также можно переложить на встроенный функционал базы данных — скажем, используя команду updateOne и оператор $inc. Для тестов можно выбрать любой привычный подход — модульные тесты с моками на MongoDB-драйвере, функциональные тесты на реальной MongoDB, запускаемой в Testcontainers, и т. д.
На этом можно остановиться, а идеи по дальнейшим оптимизациям оставить для обсуждения на предстоящем собеседовании. Но кандидат не хочет останавливаться — и решает добавить в свой класс in-memory батчинг лайков, а в базу данных батчи записывать отдельным потоком по таймеру. Тут-то и возникает множество сложностей и ошибок. Потеря консистентности чтения, так как у разных экземпляров сервиса собственные батчи. Ошибки синхронизации наполняющих батч потоков и потока, записывающего данные в БД. Снижение надежности из-за возможной потери целого батча при падении сервиса или просто из-за таймаута при попытке записи в БД. Обилие такого рода проблем скорее добавляет минусов при просмотре тестового задания, чем плюсов за старания.
Главная же и всеобъемлющая проблема в том, что, чем опытнее и востребованнее на рынке кандидат, тем меньше он хочет тратить время и силы на тестовое, понимая, что выполнение тестового — довольно неблагодарное занятие.
В попытке снизить «неблагодарность тестового» мы добавили дополнительный этап собеседования между созвоном с рекрутером и выдачей тестового задания. На этом мотивирующем собеседовании мы сначала расспрашиваем о том, что для кандидата важно на новой работе, а потом подробно рассказываем, как это реализовано у нас. Большинство кандидатов задают вопросы про команду и процессы, стек технологий, состав сервисов, нагрузку и размер БД, какие крупные задачи есть в работе, что запланировано на ближайшие полгода.
Это неплохо работало до 2021. После отсева кандидатов, чьи ожидания не совпали с ответами, отказов выполнять тестовое было меньше 10%.
Однако с пандемией востребованность джавистов сильно возросла. Возросла и важность быстрого принятия решения о найме. Получая тестовые задания, кандидаты уже имеют на руках несколько хороших офферов. Многие крупные компании пошли по пути сокращения процедуры найма до офферов за один день.
Так, двигаясь в ногу со временем, мы отказались от тестовых.
Конечно, не хотелось отказываться от полноценного впечатления о квалификации, которое кандидат мог продемонстрировать в тестовом задании. Поэтому мы переформулировали ключевые моменты, на которые смотрели в тестовом, в открытые вопросы.
Вместо тестового я теперь голосом обсуждаю с кандидатом его опыт написания тестов, опыт горизонтального масштабирования сервисов и БД. Озвучиваю проблему гонки read-modify-write, если непонятно, могу показать пример кода. Спрашиваю возможные пути решения как с точки зрения практического опыта, так и с точки зрения кругозора.
Отказавшись от тестового, мы существенно сократили время принятия решения по найму. Если раньше от первого разговора с рекрутером до выставления оффера, с учетом времени на выполнение тестового задания, проходило в среднем 2-3 недели, то теперь мы вполне укладываемся в неделю. Помимо разговора с рекрутером и презентации оффера, технический этап собеседования выродился в два часовых разговора, которые в особом случае можно превратить в один двухчасовой.
Быстрые офферы — в духе времени. Отказавшись от старых методов, вы получаете возможность конкурировать в найме. А собеседование становится более неформальным: все любят рассказывать про свой опыт.
Избавьтесь от тестового, пока не поздно!
А вы готовы выполнять тестовое, и в каком случае? Как вам офферы за один день? На что вы обращаете внимание при найме в свою команду?