Тестовые задания на собеседовании разработчика — есть ли в них смысл

За свою долгую ИТ-карьеру я успел побывать по обе стороны собеседований и увидеть весь блеск, нищету, маразм и здравые мысли тестовых заданий, выдаваемых на технических собеседованиях разработчиков ПО.

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

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

Бывают ли действительно клёвые задачи? Бывают, но очень редко, может быть, одна на сто. В основном всё стандартно и неинтересно — считать откуда-то данные, что-то с ними сделать, записать куда-то данные (файл, база, сокет).

Или реализовать на месте какой-то известный алгоритм. Почему это так? Да потому что в большинстве случаев нанимателю нужно просто проредить стопку CV на его рабочему столе, об этом я расскажу подробнее дальше.

У Васи есть две дюжины вполне подходящих резюме, среди которых надо выбрать достойного кандидата в свою команду. Собеседовать все две дюжины Васе лень, да и незачем, и он решает немного профильтровать очередь и выбрать наиболее достойных. Конечно, Вася знает, что можно пойти путём, как в известном анекдоте «А зачем нам неудачники».

Но Вася решает пойти по другому распространённому пути — выдать тестовое задание. Он рассылает его всем кандидатам. И вот далее начинается цирк с конями, который показывает всю абсурдность тестовых заданий.

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

Я встречал как задания на полчаса, так и на неделю, в среднем большинство нанимателей понимает, что негоже требовать от кандидата времени больше, чем несколько часов.

Тут наниматели пытаются реализовать в постановке задач то, чего они лишены в реальной работе — код с комментариями, покрыт unit-тестами, обязательно с code style, а бывали случаи, когда требовали краткий tutorial по программе. В большинстве же случаев в реальной работе совсем другие требования, гораздо прозаичней.

Можно встретить как стандартные задания на дом, так и такие извращения, как:

Часть кандидатов отваливается просто потому, что им лень работать бесплатно, части не нравится само задание, часть не вкуривает до конца все условия, заботливо Васей прописанные, и делает немного не то. В итоге очередь из претендентов действительно прореживается, но совсем не по тем принципам, которые ожидал Вася.

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

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

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

Очень много остаётся за кадром (дебаггинг, поиск и устранение ошибок, рефакторинг, архитектура проекта сложнее Hello World, взаимодействие с коллегами), что нивелирует практически к нулю какую-то пользу от таких заданий.

Примерно с тем же эффектом можно просто подкинуть монетку и быстро решить, подходит кандидат или нет.

Хорошо известен случай, когда автора пакетного менеджера Homebrew не взяли в Google лишь по той причине, что на седьмом интервью он не смог на доске написать алгоритм, как инвертировать бинарное дерево. Сколько крутых парней компании теряют от таких невнятных заданий — можно только догадываться.

Находясь на месте Васи, я иногда давал тестовые задания для того, чтобы было что обсудить после его выполнения. Но только, если сам разработчик не против его выполнить. Это хорошо подходит для Junior- и Middle-разработчиков, если у них нет кода, который они могут продемонстрировать. Senior и выше небольшим тестовым заданием уже не оценить, тут нужен другой подход.

Учитывая минусы традиционных тестовых заданий, некоторые компании стали применять подход, более приближённый к рабочим условиям. Кандидат получает реальное задание из текущего списка задач (backlog) компании, которое может выполняться от одного дня до пары недель и оплачивается по договорной ставке.

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

Дотошный читатель спросит: «Ок, автор, если не тестовое задание, то как ещё можно отобрать нужного сеньора?». А это уже тема для отдельной статьи, следите за обновлениями!