Почему сеньорам надо посылать к чёрту тестовые задания: 6 веских причин

С недавних пор IT-отрасль массово ополчилась против whiteboard-собеседований, когда перед кандидатом ставят маркерную доску или дают лист бумаги и просят написать код на них. Такие собеседования сопряжены с огромным стрессом — собственно, это признают представители индустрии. Кроме того, применяющие подобный подход компании нередко отсеивают действительно талантливых кандидатов; например, известен случай, когда Google отказала Максу Хауэллу, создателю Homebrew, который не смог выполнить задание вовремя.

Альтернативой такому лайвкодингу считают coding assignments — то есть тестовые задания. Многие расценивают их как универсальное средство оценки любых программистских навыков.

Преимущества тестовых вроде бы очевидны:

• Их делают дома, что фактически исключает стресс, связанный с whiteboard-собеседованиями и лайвкодинг-сессиями, когда кандидат пишет код в присутствии потенциального работодателя.
• Выполнение рассчитано на более продолжительный срок (обычно на неделю), что позволяет протестировать кандидата на владение значительно большим количеством навыков, чем привычные for-loops, зазубренные методы оптимизации и размышления вслух.
• Не надо никуда ехать. Кандидату можно не брать на работе отгул, а потенциальному работодателю — его оплачивать.

Кандидаты, особенно некоторые сеньоры, буквально мечтают об удалённых тестовых заданиях от понравившихся им компаний. Ещё бы — ведь они охватывают все этапы разработки ПО: UI, бизнес-логику, управление базами данных, взаимодействие и тестирование. Кроме того, на их выполнение предоставляется почти бесконечное количество времени.

Мотивация в таких случаях запредельная: есть ли шанс ещё нагляднее продемонстрировать сразу все свои умения? И разве можно потерпеть неудачу при столь благоприятном раскладе?

Не спешите: ловушка где-то рядом. Давайте последовательно рассмотрим все недостатки тестовых заданий.

Причина №1

Несогласованная коммуникация

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

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

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

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

Причина №2

Требования, состоящие из одной строчки

В большинстве случаев тестовые задания — это одна строчка. Например: «Разработайте самую эффективную систему управления воздушным движением». Всё остальное находится в зоне ответственности кандидата. И хотя требования могут быть длиннее — 5–6 строчек, — этого часто также бывает недостаточно. Они кажутся довольно несуразными и заставляют кандидата полностью погружаться в них. А после того, как вы сдаёте выполненное задание, вас очень часто ждёт отказ.

«Без требований или дизайна программирование — это искусство добавлять баги в пустой текстовый файл», — говорит Луи Сригли.

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

Причина №3

Ожидание 100% соответствия

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

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

Причина №4

Бесконечный диапазон предположений

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

Если вы выберете подход, направленный на достижение цели, то будете недостаточно функциональны, и наоборот. Никаких вопросов, никаких преждевременных ожиданий, никаких вторых шансов. Просто отказ!

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

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

Причина №5

Размер имеет значение

Речь не об объёме задания, а о спектре необходимых для его выполнения навыков. Требование заключается в том, чтобы разработать миниатюрную систему, а не отдельный компонент. Это означает, что вы должны спроектировать и разработать UI, модели, сервисы (сетевые взаимодействия / файловую систему / управление базами данных) и всё остальное.

Помните треугольник «содержание — сроки — стоимость»? Если вы увеличите одну из сторон, то несомненно вдруг появятся и две оставшиеся. Однако никто не платит вам за выполнение тестового задания по программированию, и никто кроме вас не пострадает, если вы сорвёте сроки.

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

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

Формально выполнение задания не должно занимать более 2–4 часов вашего времени, но редко когда получается завершить его даже за выходные, если ранее вы не сталкивались с чем-то подобным в своей деятельности.

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

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

Причина №6

Коммуникация после отказа

Это самый важный вопрос.

Коммуникация после получения отказа позволяет понять: действительно ли вам не хватило определённых навыков или потенциальный работодатель просто тратил ваше время и эмоции?

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

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

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

Что в итоге?

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

Что делать компаниям?

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

Предварительная оценка потенциальных сотрудников на основании их профиля на GitHub и портфолио позволит сократить объём кода, необходимого для выявления подходящих кандидатов, или вовсе избавиться от подобного тестирования.

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

Так что перестаньте превращать людей в машины для написания кода.

Что делать сеньорам?

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

Исключением может быть тестирование, которое на самом деле займёт 4–6 часов вашего времени.

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

В общем, перестаньте тратить своё время на те компании, которые не уважают труд кандидатов. Уважайте себя.