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

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

Cо стороны соискателя (aka разработчик Петя)

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

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

Cо стороны нанимателя (aka тимлид Вася)

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


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

Собеседующий

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

Время выполнения и объем задания

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

Качество кода и оформления

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

Формат задания

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

• написать решение на доске(этим обычно грешат западные компании)
• написать решение в notepad на ноуте компании
• написать решение удаленно в режиме pair programming

Что Вася видит на выходе?

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

Что бы хотел видеть Вася?

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

Что дают тестовые задания в реальности?

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

Хорош нагонять, автор, наверное в крутых конторах меньше бреда с заданиями

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

Что, тестовые задания совсем не нужны?

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

Могут ли тестовые задания действительно приносить пользу обоим сторонам?

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

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