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

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

Как бы вы ни старались, почти невозможно создать достойный код с нулевой двусмысленностью, не создавая инструкции, которые читаются как юридические сводки. Добавьте к этому «экзаменационное давление» и старое доброе: «Я не читаю инструкций, я прыгаю вперед ногами», и у вас есть рецепт неправильного толкования и непонимания. Мы считаем, что испытания кода должны быть вознаграждены для кандидата. Если кто-то собирается пожертвовать 2+ часами своего времени, чтобы принять ваш вызов, по крайней мере, они должны получить взамен результаты. И когда мы говорим о результатах, мы имеем в виду не оценку, а тщательную оценку кода; построчный анализ с итоговыми точками, состоящими из конструктивной обратной связи, указывающей на хорошие и не очень хорошие элементы их решения. Проблема в том, что без какого-либо механизма, чтобы ответить рецензенту, это немного похоже на возвращение в школу. Мы чувствовали, что естественная эволюция этого процесса заключается в том, чтобы позволить кандидату обосновать свои решения и иметь возможность объяснить сделанный(е) выбор(ы), отвечая на комментарии рецензента.

В Geektastic мы пытаемся сделать испытание кода «реальным», насколько это возможно, позволяя ограничениям измерять и сравнивать кандидатов. Это означает создание задач, соответствующих компании, в которую претендуют кандидаты, создание функций продукта или решение проблем, с которыми они могут столкнуться, когда получат должность. Мы понимаем, что 2-часовой вызов кода с ограниченным временем создает нереальную ситуацию, добавляет напряжения, которого обычно нет в течение обычного рабочего дня. Конечно, бизнес требует от инженеров выполнения поставленных задач, обязательства, принятые командой во время планирования спринта, неизбежно предъявляют требования к отдельным участникам, но ничто не сравнится с тиканьем часов (даже мысль об этом возвращает меня в холодные экзаменационные комнаты, к учителям, шагающим в ногу со временем). и вниз, глядя на аналоговые часы на стене, которые, казалось, шли в двойном темпе). Даже в открытых задачах, где элемент времени удален, у вас все еще есть обезьяна на плече, побуждающая вас делать то, что вы не могли бы делать, если бы вы расслабленно сидели за своим столом со своей командой.

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

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

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

Первоначально опубликовано на geektastic.com.