Сложная проблема

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

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

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

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

Среди техник собеседования по кодированию незаслуженную популярность приобрела ужасная «сессия у доски». Мы все были там, либо в качестве интервьюеров, либо в качестве интервьюируемых. Сонный сотрудник только что позавтракал, удобно просматривая решение какой-то абстрактной и часто бессмысленной головоломки. Этот человек потребует, чтобы какой-нибудь неудачливый кандидат разработал и закодировал решение на месте, написав маркером (обычно почти исчерпанным) на доске. На самом деле, кандидат будет отчаянно пытаться вспомнить аналогичную головоломку и внести небольшие изменения в уже существующее решение; или они просто извергают то, что они подготовили в ожидании вопросов, которые какой-то хитрый сторонний охотник за головами (если компания использует их) просочился к ним.

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

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

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

Введите автоматические тесты кодирования

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

Как человек, который собирал бессмысленные золотые значки Codility (которые присуждаются тем, кто находит «идеальные» решения предполагаемых «проблем»), я однажды был восхищен безжалостной справедливостью этой практики найма. Я думал, что не будет никакой предвзятости, неосознанной или какой-то другой: меньше шансов, что на первом этапе тебя уволят из-за пола, цвета кожи или неумения лгать. Отсеиваются только те, кто не умеет программировать. Ура!

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

Прежде всего, вопросы предвзяты в пользу только что закончивших вузов. У тех, у кого 20-летний опыт работы и долгая карьера успешных проектов, скорее всего, также будет трое детей, один из которых с серьезной инвалидностью, и пожилая мать, которую нужно возить туда-сюда между домом и химиотерапевтическим отделением. Они отлично справляются со своей работой и при необходимости делают это с 9 до 8, но у них мало свободного времени для решения головоломок.

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

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

По моему опыту, ни одна хорошая функция не была написана и протестирована всего за 30 минут. Что подводит нас к следующему пункту: Codility и подобные платформы не могут и не измеряют различные «-или» кода, которые высоко ценятся или должны высоко цениться в реальном мире программирования вне хакатона. . Никто не хочет поддерживать код, который кто-то написал после пятого Red Bull. Не случайно кандидаты, принадлежащие к субкультуре мачо-программистов, получают 100/100 баллов в автоматическом тестировании на время, срезая все возможные углы и называя переменные foo и bar.

Codility наказывает кандидатов за отправку первого пришедшего им в голову решения O(n²). И все же, по моему опыту, хорошо написанное O(n²) решение небольшой проблемы может быть лучше для моей команды и компании, чем какое-то искаженное O(n log n) решение, написанное за 30 минут каким-то придурком, занимающимся программированием. Есть вероятность, что решение O(n²) будет заменено идеальным решением O(n) по мере возникновения коммерческой необходимости. В этот момент вы будете благодарны, что решение было неэффективным, но, по крайней мере, ясным и понятным.

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

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

Вот идея получше: как насчет того, чтобы перестать лениться и отказаться от автоматических тестов кода?

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

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

А как насчет опытных разработчиков программного обеспечения? Что ж, это зависит от обстоятельств, но помимо вопросов об их прошлых проектах, есть целевые и объективные тесты для оценки их квалификации в том или ином наборе технологий. Если кто-то утверждает, что является профессионалом в C++, почему бы не попросить его реализовать потокобезопасный контейнер (не на доске, потому что это глупо и оскорбительно, а в качестве домашнего теста)? Я могу пообещать вам, что кандидат предоставит бесчисленное количество возможностей для того, чтобы задавать интересные вопросы, начиная с гарантий безопасности исключений и правил аннулирования итераторов, которые, конечно же, нарушаются, как всегда. Вы также можете спросить кандидата, для какой цели может служить этот конкретный контейнер в практическом повседневном C++, а не в соревновательном программировании, алгоритмических головоломках in vitro или кодовом гольфе.

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