- PVSM.RU - https://www.pvsm.ru -
За свою долгую IT-карьеру я успел побывать по обе стороны собеседований и увидеть весь блеск, нищету, маразм и здравые мысли тестовых заданий, выдаваемых на технических собеседованиях разработчиков ПО.
Если Петя находится в начале карьеры разработчика — то ему делать тестовые задания будет скорей всего интересно и он готов потратить на это личное время. Для разработчиков уровня Senior и выше подобные задания вызывают уже скуку, тем более не оплачиваемую. А так как обычно разработчик обходит не одну компанию, то количество впустую потраченного времени на тестовые задания может составлять уже дни и даже недели!
Бывают ли действительно клевые задачи? Бывают но очень редко, может быть одна на 100. В основном, все стандартно и не интересно — считать откуда-то данные, что-то с ними сделать, записать куда-то данные (файл/база/сокет..). Или реализовать на месте какой-то известный алгоритм. Почему это так? Да потому что, в большинстве случаев нанимателю нужно просто проредить стопку CV на его рабочему столе, об этом я расскажу подробней дальше.
У Васи есть две дюжины вполне подходящих резюме, среди которых надо выбрать достойного кандидата в свою команду. Собеседовать все две дюжины Васе лень, да и незачем, и он решает немного профильтровать очередь и выбрать наиболее достойных. Конечно, Вася знает, что можно пойти путем, как в известном анекдоте:
Но Вася решает пойти по другому распространенному пути — выдать тестовое задание и рассылает его всем кандидатам. И вот далее начинается цирк с конями, который показывает всю абсурдность тестовых заданий.
Один из худших вариантов для обеих сторон, если тимлид по какой-то причине (занят, не хватает компетенций, тупо лень, пошел пообедать) вместо себя на собеседование отправляет одного члена своей команды и по его отзыву принимает решение. Если так происходит, то тимлид, скорей всего, занимает не свое место в компании.
Я встречал как задания на полчаса, так и на неделю, в среднем, большинство нанимателей понимает, что негоже требовать у кандидата времени больше, чем несколько часов.
Тут наниматели пытаются реализовать в постановке задач то, чего они лишены в реальной работе — код с комментариями, покрыт unit-тестами, обязательно с code style, а бывали случаи, когда требовали краткий tutorial по программе. В большинстве же случаев в реальной работе совсем другие требования, гораздо прозаичней.
Можно встретить как стандартные задания на дом, так и такие извращения, как:
Часть кандидатов отваливается просто потому, что им лень работать бесплатно, части не нравится само задание, часть не вкуривает до конца все условия, заботливо Васей прописанные, и делают немного не то. В итоге очередь из претендентов действительно прореживается, но совсем не по тем принципам, которые ожидал Вася. Со временем, Вася видит, что качество выполненного тестового задания и эффективность работы нового разработчика в команде слабо кореллируют и уже для следующих кандадатов не так настаивает на выполнении тестового задания, переходя на следующий уровень оценки разработчика.
В своих розовых мечтах Вася видит, что кандидат с радостью и энтузиазмом начнет работу над тестовым заданием и выдаст свой лучший код ever, покрытый тестами по самое немогу, с грамотной (но не излишне сложной) структурой и щедро сдобренный толковыми комментариями.
Разрыв между тестовым заданием и реальной работой настолько велик, что проецировать результат выполнения небольшого задания на 3 часа на долгую работу разработчика было бы весьма наивно. Очень много остается за кадром (дебаггинг, поиск и устранение ошибок, рефакторинг, архитектура проекта сложнее Hello World, взаимодействие с коллегами), что нивелирует практически к нулю какую-то пользу от таких заданий. Примерно с тем же эффектом можно просто подкинуть монетку и быстро решить, подходит кандидат или нет.
Хорошо известен случай, когда автора пакетного менеджера Homebrew не взяли в Google, лишь по той причине, что на 7-м интервью он не смог на доске написать алгоритм, как инвертировать бинарное дерево. Сколько крутых парней компании теряют от таких невнятных заданий — можно только догадываться.
Находясь на месте Васи, я иногда давал тестовые задания для того, чтобы было что обсудить после его выполнения. Но только, если сам разработчик не против его выполнить. Это хорошо подходит для Junior и Middle-разработчиков, если у них нет кода, который они могут продемонстрировать. Senior'ов и выше небольшим тестовым заданием уже не оценить, тут нужен другой подход.
Учитывая минусы традиционных тестовых заданий, некоторые компании стали применять подход, более приближенный к рабочим условиям. Кандидат получает реальное задание из текущего списка задач (backlog) компании, которое может выполняться от одного дня до пары недель и оплачивается по договорной ставке. Таким образом, кандидат получает возможность поработать в режиме trial с новой командой и при этом заработать деньги за потраченное время. Это позволяет оценить кандидата более точно в условиях, приближенных к боевым, но, к сожалению, это могут позволить себе немногие компании.
Дотошный читатель спросит — «ОК, автор, если не тестовое задание, то как еще можно отобрать нужного сеньора?». А это уже тема для отдельной статьи, следите за обновлениями!
Автор: JordanoBruno
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sobesedovanie/331480
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/469099/?utm_source=habrahabr&utm_medium=rss&utm_campaign=469099
Нажмите здесь для печати.