Простые и длинные задачи лучше отсеивают кандидатов, чем короткие и сложные

Автор оригинала: Charles Treichler
  • Перевод
tl;dr: Вопросы и задачи на собеседованиях по программированию кажутся излишне сложными. Иногда так и есть, что добавляет стресса. Это не единственный довод против них. Наши данные показывают, что более сложные задачи на самом деле хуже предсказывают конечный результат, чем более простые.

Тяжело программировать под давлением времени. Тем более на собеседовании. Задание, которое в нормальных условиях кажется простым, каким-то образом вызывает огромные проблемы в ярком свете комнаты для интервью. Гормоны стресса затуманивают мозг (к сожалению, ни драка, ни бегство не станут эффективным ответом на кодерскую проблему). Возникает ощущение, что вопросы словно специально разработаны с извращённой сложностью. Думаю, эти чувства возникают не на пустом месте.

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

Более простые вопросы


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

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

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

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

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

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

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

Более простые вопросы также снижают уровень стресса, что является важным преимуществом. Стресс заставляет кандидатов недооценивать свои возможности. Когда кандидат чувствует себя более комфортно, то проявляет максимальный потенциал, что делает собеседование более предсказуемым. Мне кажется, интервьюеры склонны недооценивать влияние стресса на кандидатов, в то же время переоценивая свои собственные способности. Когда вы задаёте задачу, легко забыть, сколько кода в реальности можно написать за 30-60 минут. Чтобы противостоять этой предвзятости, мы в Triplebyte приняли правило: интервьюеры должны дать на решение задачи в 3 раза больше времени, чем то время, за которое могут решить задачу сами, по их мнению. Обычно это соответствует более-менее правильной оценке.

Более длинные задачи


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

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

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

Вывод


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

Надеюсь, интервьюеры сделают выводы. Они могут не только повысить точность отбора, но и упростить свою работу. Гораздо легче придумать простые, многоступенчатые проблемы, чем извращённо сложные короткие вопросы.

Итак, вот наш совет. Если вы действительно хотите сделать собеседования более точными, то нужно начать задавать более простые задачи по программированию. Это не означает понижение планки. Это просто означает улучшение сигнала, чтобы более эффективно отсеять кандидатов и нанять самых талантливых.
  • +19
  • 10,3k
  • 7
Поддержать автора
Поделиться публикацией

Комментарии 7

    +2
    А в чем проблема начать тестирование с простых вопросов и наращивать сложность в процессе?
      +4
      Я прошу человека рассказать о себе и сделать реальное code review нескольких примеров реально где-то используемого кода. И хорошего и плохого.
      Вообще не понимаю, почему люди не дают code review на собеседовании — это и реальная рабочая задача и возможность кандидату рассказать о своих сильных сторонах, как бы сделал он. И кода полно — правильный ответ невозможно зазубрить. Но бывает, что человек просто молчит и видит в коде фигу. Ну и смысл о гномиках дальше разговаривать?
        0
        Как можно в коде видеть фигу? Я действительно не понимаю, что это за реакция такая, это же код.)
          0

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

          +2

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

            +1
            Для этого и есть первая часть, где прошу рассказать о себе — видно по прошлому опыту человек инициативный или надо постоянно пинать, чтобы что-то делал. Если человек не может внятно сказать, чем занимался последние 5 лет или вспоминает свой лучший проект из далекого детства, то, да, и на новом месте ничего он делать не собирается
          0
          Не знаю как при найме разработчиков, но когда собеседуется менеджер лучший тест на соображалку — о процентах. Вы даже не представляете количество людей, которые не в состоянии чётко ответить на вопрос сколько будет 2,5% от 200. Даже с бумажкой, вариантами ответов и наводящими вопросами.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое