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

  • 1 октября, 16:44
  • 3700
  • 0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


0 комментариев
Сортировка:
Добавить комментарий