Введение:

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

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

С чего все начинается:

Вы, наверное, все знаете эту ситуацию. Ваш разговор с отделом кадров проходит гладко, кажется, что вы понимаете культуру компании, и настроение хорошее. Следующим этапом обычно является проверка вашего знания английского языка (только для кандидатов, не являющихся носителями языка), поэтому, немного заикаясь, вы уверяете рекрутера, что ваше хобби — рыбалка и быстрые машины, и, конечно же, что вы всегда хотели стать инженером-программистом. . После этого следует техническое собеседование — вы не боитесь этой части, ведь вы в индустрии несколько лет. Вы отвечаете на все технические вопросы. В какой-то момент рекрутер останавливается, чтобы поболтать о некоторых интересных технологиях будущего и о том, как выглядит повседневная работа. До этого момента вроде бы все идет хорошо, и, скорее всего, вам предложат работу. Потом сказочная атмосфера уходит и возникает вопрос…. «Не могли бы вы выполнить дополнительное задание, которое подготовила наша команда? Это небольшая вещь, и, закончив ее, вы позволите нам лучше узнать вас».

Захватывающая задача:

Как заверил рекрутер, задача рассчитана на два-три часа — «если ты хороший специалист». И, конечно же, вы хороший программист, не так ли? Вы не уверены, стоит ли продолжать, но каким-то образом соглашаетесь. Вскоре вы получите электронное письмо со списком вещей, которые необходимо решить. В большинстве случаев это CRUD, как интересно — кто бы мог этого ожидать? Со временем вы узнаете, что это какой-то новый JS-фреймворк вроде React или Angular, и он требует создания базового сервера узлов — ведь уважающий себя фронтенд-разработчик может написать базовый API. Что ж, вместо того, чтобы давать глазам отдохнуть после ежедневной напряженной работы, вам не терпится создать графический интерфейс для расположения точек загрузки электромобилей, статистики грузов судов в морском порту или создать стену с постами, фотографиями, тегами и нравится. Если вам не повезло, вас просто попросили создать Instagram или другой клон Tinder. (это примеры из жизни).

…ты что, шутишь?:

Когда начать? Если это рекрутинговая задача, велика вероятность, что вам нужно будет написать подробные тесты (вскоре обнаружится, что у компании в большинстве случаев нет времени на тестирование). Ну, они требуют, чтобы вы писали тесты только для фронтенда или распространяли их и на кусок API? Вам разрешено использовать библиотеки для написания макетов CSS или нет? Вероятно, вы не хотите прослыть лентяями, использующими чужой код, но, с другой стороны, если что-то готово «из коробки» и хорошо заточено под решение, кто-то может подумать, что вы пытаетесь заново изобрести код. колесо. Рекрутер часто мало или вообще не дает информации о решениях задач, поэтому вам посоветуют «просто выкладываться по полной».

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

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

Другой способ:

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

Есть возможности для улучшения:

Что тогда делать программисту? Отказ от работы над задачей говорит рекрутеру об одном — задача, вероятно, слишком сложна для вас и вы нервничаете из-за того, что делитесь своим кодом, или, что еще хуже, вам наплевать на эту должность. На мой взгляд, есть только один случай, когда вы должны поставить код. Задача вам интересна и вы думаете, что узнаете из нее что-то новое. (или у вас нет альтернативы). После отказа рекрутер иногда просит показать приватный код, но давайте будем честными. Никто не обязан быть супер-пупер страстным программистом, развивающим свой стартап в нерабочее время.

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

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

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

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

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

Следите за командой JIT, человеческим фактором ИТ

https://www.linkedin.com/company/jit-team
https://www.instagram.com/jit.team/
https://www.facebook. com/jit.team.poland/
https://dribbble.com/jitteam