Нужны ли тестовые задания разработчику и что общего между ними и сексом

Делать или не делать? — вот в чём вопрос. Он возникает каждый раз, когда для устройства на работу нужно выполнить тестовое. Особенно если есть другие неизвестные: подходит ли мне проект, компания, зарплата? Хочу ли я вообще эту должность? Никого не вдохновляет идея потратить личное время на неоплачиваемую работу с непредсказуемым результатом. Неизвестно, на что именно обратит внимание проверяющий, поэтому либо вылизываешь всё, либо сильно рискуешь бессмысленно убить от нескольких часов до нескольких недель. Даже успешное тестовое не гарантирует приёма на работу, а ошибочное — не всегда крест на карьере в этой компании. Тогда к чему всё это? В этой статье мы собрали разные мнения разработчиков и попытались выяснить, так ли необходимые тестовые, что будет, если их делать и нет, сколько времени занимает выполнение тестового и насколько это вообще нормально.

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

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

Испытуемые и техлиды сходятся во мнении, что лучший вариант — короткое задание прямо на собеседовании. Лайвкодинг, хоть и вгоняет в стресс, но позволяет быстро «снять маски» с обеих сторон. Работодатель видит, как кандидат мыслит и решает задачи, а кандидат может оценить, насколько приятна и эффективна коммуникация с техлидом в рабочем процессе. Это хороший способ понять, сработаетесь ли вы, буквально за 30 минут.

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

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

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

Но если большие тестовые встречаются на каждом шагу, то про оплату — нет, не слышали. Компании разного уровня удивляют кандидатов масштабными тестовыми, на которые уходит от нескольких часов до двух недель. Иногда требуется изучить дополнительную литературу или непривычный стек. Причём прямая закономерность между крутостью компании и размером тестового не всегда прослеживается. Окей, Гугл, которому нужно отсеять сотни тысяч желающих попасть на интервью. Но откуда у неизвестных никому небольших компаний такое ЧСВ, остаётся необъяснимым.

Для некоторых разработчиков выполнение тестовых в корне неприемлемо. Они считают, что резюме, портфолио и подробных интервью достаточно, и безжалостно реджектят вакансии с тестовыми. По данным SuperJob, так поступает каждый пятый программист. Большинство согласны выполнять тестовое задание, особенно объёмное, только для компаний, куда мечтают попасть.

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

Из-за отсутствия опыта и реализованных проектов джуны соглашаются на объёмные тестовые задания длительностью до нескольких дней. Здесь стоит следить, чтобы срок был гибким и адекватным. У студентов может быть очень насыщенный график, но даже безработному едва ли хватит пары дней, чтобы написать аппку с нуля. Либо тестовое будет выполнено неряшливо, либо кандидат не справится в срок. И то и другое, не устроит работодателя. Так что лучше трезво оценить своё время и понять, есть ли смысл сражаться с масштабным тестовым или посмотреть вакансии дальше.

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

Время мидлов стоит уже дороже, поэтому неоплачиваемое тестовое — попытка работодателя запустить руку в их карман. Особенно если есть подозрения, что тот хочет получить экспертизу хорошего спеца, так сказать, «взгляд со стороны», и использовать в своих целях, а не для найма сотрудника. У мидлов уже есть значимые проекты в портфолио, по которым должен быть понятен уровень компетенций и без домашних заданий.

У этих ребят и уверенность в себе и процент отказа от тестовых гораздо выше. Они знают себе цену и не мотивированы работать бесплатно, зато не прочь поиграть хардскилами в pair programming. Если тестовое необходимо, то работодатель либо идёт лесом, либо запрашивается оплата.

Если оплата не согласована, то смотрите первый вариант. Всё бы ничего, но иногда случаются факапы: компании соглашаются на оплату, но после получения решения притворяются без вести пропавшими.

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

Здесь стоит сделать оговорку. Т.к. понятие middle очень размытое, вариативность в навыках и ЧСВ может быть огромной. Если вы «начинающий мидл» и не можете похвастаться большим портфолио, возможно, выполнение тестового станет логичной возможностью продемонстировать умения, как и в случае с джунами.

Здесь действуют те же правила, что и для уверенных мидлов, только с большим почётом. Senior-разработчик имеет опыт, компетенции и, скорее всего, определённую сферу интересов. Он не ищет работу, его хантят. Захочет ли работодатель сразу отпугнуть сеньора, предложив ему без уважения неуместное тестовое? Шансы есть, но уже ниже.

Бывает, что Senior-разработчика нанимают не для кодинга, а для отлаживания сложных процессов. Может ли тестовое задание в полной мере проверить эти качества? Вряд ли.

Как подметил автор статьи, сеньоры также реджектят собеседования с кодингом. Senior-разработчика нанимают не для программирования, поэтому кодинг на собеседовании заставляет его засомневаться в будущих рабочих задачах. Талантливые разработчики очень далеки от университетских задач и голых средств разработки. Подготовка к такому собеседованию отнимет уйму времени ради вакансии, где уже на собеседовании что-то пошло не так.

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

Все делают это.

Для многих и то и другое, неприемлемо на «первом свидании». Разработчики не хотят выполнять тестовые задания до интервью. Какой смысл тратить личное время, когда ещё ничего не знаешь о компании? Разве что речь не о Гугл. Тем не менее некоторые компании тестовыми проверяют мотивацию работать именно у них и отсеивают кандидатов для экономии времени на личное интервью. Это понятно для компаний с мировым именем, но для ноунеймов такая стратегия приведёт разве что к найму тех, кому отказали все остальные.

Более логичной видится цепочка: ознакомление с резюме, портфолио, личное интервью. В большинстве случаев на техническом интервью можно понять, подходит человек или нет. Тогда необходимость в тестовом отпадёт. Если она всё же есть, кандидат уже сформирует своё представление и будет мотивирован выполнять ДЗ.

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

И ещё раз о размере, который имеет значение.

Опыт иных разработчиков вообще опровергает тот факт, что тестовое имеет хоть какой-то смысл. Автор статьи заметил, что «ни одного случая найма с тестовым заданием не было успешным ни для какой стороны — ни для меня, ни для работодателя», и как ни парадоксально, выполнение тестовых отвлекает от основной задачи — устройства на работу.

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

Глубже юридические тонкости разобраны в статье. Здесь же автор привёл весьма обстоятельный пример, как нанять кандидата и обойтись без тестового, и расписал всё по шагам. Спойлер: для этого придуман испытательный срок. Однако есть противоречивые мнения насчёт такого подхода.

Кроме преследования по закону, до которого дойдёт вряд ли, есть и другие причины, почему тестовые невыгодны нанимающей стороне. Большинство работодателей раздают их без раздумья и вряд ли трекают собственные времязатраты и реальную необходимость привычного инструмента.

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

Напомню, что сам факт наличия тестового уже сильно ограничивает выбор работодателя: на 20% тех, кто никогда не делает тестовые, плюс на львиную долю людей, которые не захотят сделать конкретное тестовое или не будут иметь времени/возможности сделать его в конкретный момент.

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

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

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

Тестовое задание часто никак не связано с реальными задачами, поэтому его выполнение не гарантирует, что кандидат подходит на 100%. Если это не так, работодателю снова придётся запускать процесс найма. Также в любых тестовых есть вероятность «ложноотрицательного результата». Если разработчик ошибся в тестовом, это не значит, что он не сможет хорошо справиться с работой. Вспомним, как Гугл зареджектил Макса Хауэлла, а теперь его софтом пользуются все гугловские инженеры.

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

Это вряд ли повсеместная проблема, но среди соискателей обязательно найдутся весёлые и находчивые, которые захотят поиздеваться над работодателем. Возьмут тестовое и начнут кормить завтраками, отнимая время у рекрутера.

Так ли нужны тестовые? Как мы выяснили выше, нет. И наиболее продвинутые работодатели уже понимают это и пересматривают систему найма в сторону более бережного отношения к личному времени кандидата.

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

1. Лайвкодинг. Сразу видно, как кандидат соображает и ведёт себя в «естественной среде обитания». Можно давать подсказки и видеть, как разработчик исправляет ошибки. Ведь прав не тот, кто не ошибается, а тот, кто может гибко и бесконфликтно перестроиться. Лайвкодинг может пугать разработчиков-интровертов, зато сильно экономит время и даёт работодателю участвовать в процессе. Увеличивается шанс не упустить хорошего кандидата, даже если тот допустил ошибку.

2. Собеседование с техлидом. Просто дайте кандидату время побеседовать с техлидом — и они найдут общий язык. Опытный разработчик знает, что спросить, и быстро выявит сильные и слабые стороны кандидата, а также составит представление, насколько комфортно им будет работать в команде. Час беседы с техлидом заменяет объёмное тестовое и закрывает большинство вопросов по компетенциям.

3. Небольшая задача на собеседовании. Правила те же: задача должна быть максимально приближена к реальным, вместо того чтобы проверять эрудицию кандидата или сдувать пыль с университетских знаний. Интересен тут не столько верный ответ, сколько логика решения. Даже если кандидат допустит ошибку, в обсуждении её можно обнаружить и предложить варианты исправления. Работодатель же сможет оценить, насколько логика мышления кандидата подходит проекту и команде.

4. Open Source проекты в портфолио. Вместо того чтобы разбирать коды, специально созданные для тестового, почему бы не разобрать реальные коды, которые пишет разработчик? При необходимости можно задать вопросы и обсудить спорные моменты. Почему выбран этот инструмент и такая архитектура, что можно улучшить? Если кандидату уже доводилось решать задачи, аналогичные задачам нанимателя, стоит обсудить их и наглядно увидеть, какие конкретно решения он принимал в реальных проектах.

5. Код ревью. Оценка кода другого разработчика хорошо показывает аналитические навыки, способность кандидата замечать ошибки и предлагать решения. По тому, как специалист проводит код ревью, будет видно, на что обращает внимание он сам и умеет генерить нетривиальные идеи.

Позвольте завершить статью ультимативным выводом.

Вывод: (софизм) тестовое задание объёмом более дня с основной целью (поступления на работу) выполнять невыгодно.

Чтобы подытожить всё вышесказанное, разработчиков стоит разделить условно на 3 группы:

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

У вас наверняка есть свой опыт и личное мнение о тестовых. Без них исследование будет неполным, так что не держите при себе — оставляйте в комментариях.

Ну а мы, несмотря на все события происходящие в мире, делающие наше общее будущее туманным, продолжаем делать Telegram-бота Get Me It для анонимного и быстрого налаживания контакта между вами и работой мечты. Настраивайте фильтры в боте и получайте самые релевантные предложения под ваши запросы.

Следуйте за белым кроликом, кликнув по ссылке.😉