Упражнения по программированию - это не та работа, которую мы делаем каждый день

Упражнения по кодированию - одна из тех практик, которые настолько укоренились в нашей индустрии, что мы бездумно воспроизводим их, забывая, зачем они вообще нужны. Нередко можно увидеть компании, требующие от кандидатов выполнения задач, которые занимают 6–8 часов, даже не задавая вопросов.

Я считаю, что это вредно как для кандидатов, так и для нанимающих компаний.

Это не должно длиться так долго

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

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

Этика требования от людей тратить так много свободного времени на работу над заданием по кодированию без какой-либо оплаты кажется мне весьма сомнительной.

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

Так что нет, извините, я не буду тратить целый день на выходные, работая над задачей кодирования для работы, которую я, возможно, даже не получу!

Кодекс - это только одна часть работы

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

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

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

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

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

Знакомство с проблемой и технологиями

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

Для иллюстрации: сильный кандидат с многолетним опытом работы в Scala, подающий заявку на работу в Haskell, может написать что-то вроде sequenceA (map f xs), поскольку более слабый кандидат с большим знанием самого Haskell напишет более короткое traverse f xs. Здесь мы будем выбирать, насколько кандидат знаком с базовой библиотекой в ​​Haskell, что в большинстве случаев не имеет значения. Например, может быть важнее посмотреть, насколько они понимают функциональное программирование.

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

Уже есть код

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

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

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

… И код, которого нет

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

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

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

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

Если вам нравятся истории, подобные этой, подумайте о членстве в Medium и / или подписке.