А может быть лучше?

Существует три типа технических собеседований:

  • кодирование
  • Системный дизайн
  • поведение

Собеседование по кодированию является самым важным для инженеров-программистов.

Инженеры-программисты начального уровня могут пройти 3-5 раундов собеседований. Каждый раунд интервью длится от 45 минут до 1 часа, и, скорее всего, все они представляют собой собеседования по кодированию. Конечно, мы также смешиваем несколько вопросов о поведении между ними. Но они не будут иметь такого большого веса, поскольку у кандидатов в любом случае не будет много интересных историй, которыми можно было бы поделиться.

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

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

Каменистый путь к тому, чтобы стать интервьюером по программированию

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

Если вы хотите стать интервьюером для собеседований по кодированию, процесс обучения примерно следующий:

  1. Придумайте новую проблему
  2. Проверьте новую проблему на коллегах
  3. Протестируйте новую задачу на кандидатах
  4. Получите диплом сертифицированного интервьюера

Придумать новую задачу на собеседовании - это самый сложный и трудоемкий процесс.

  • Сложность задачи должна быть правильной. Если задача слишком сложная, никто не сможет пройти. Если это будет слишком просто, то все могут пройти. В любом случае трудно отличить хороших кандидатов от плохих.
  • Проблема должна быть творческой. В идеале это должна быть проблема, которую нельзя найти в Интернете напрямую. В противном случае мы будем нанимать людей, которые заранее видели проблемы, вместо умных.
  • Задача должна быть интересной. Для кандидатов участие в собеседовании является огромным обязательством, особенно для тех, у кого уже есть работа и которым необходимо использовать свой отпуск. Мы хотим быть уважительными и благодарными. И мы хотим, чтобы кандидаты повеселились и получили хороший опыт собеседований.
  • Проблема связана с характером работы. В идеале проблема должна возникать из повседневной работы и проверять навыки, необходимые кандидату для успешной работы. Вот почему большинство компаний объединили головоломки, задачи динамического программирования или NP-сложные задачи.

Я лично потратил месяцы и прошел несколько итераций, прежде чем остановился на ряде проблем, которые меня устраивали.

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

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

Известный набор хороших проблем

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

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

  • Могут быть конфликты со стороны разных интервьюеров. Набор задач будет небольшим, так как трудно придумать новые. Если проблема теперь может использоваться несколькими интервьюерами, это будет сложно для координаторов собеседования - для одних и тех же кандидатов мы должны убедиться, что одна и та же проблема не будет задаваться несколько раз разными интервьюерами.
  • Трудно предотвратить утечки. По мере роста компании и увеличения числа интервьюеров, проблемы с кодированием в конечном итоге станут известными. Мы можем потребовать от всех кандидатов подписать соглашение о неразглашении информации (NDA). Но неизбежно проблемы все равно просочились. Представьте себе большую технологическую компанию со 100 тысячами инженеров. Если не принимать во внимание текучесть кадров, предположим, что уровень найма составляет 10%, тогда требуется 1 миллион собеседований, чтобы нанять 100 тысяч инженеров. Даже если бы только 0,1% кандидатов не уважали NDA, все равно было бы 1000 утечек.

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

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

Проблемы кодирования становятся все сложнее

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

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

В 2008 году было опубликовано Cracking the Coding Interview: 150 вопросов и решений для программирования. Это быстро стало библией для кандидатов и, вероятно, интервьюеров. Вскоре после этого интервьюеры научились избегать проблем из этой книги, поскольку все они были хорошо известны.

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

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

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

Некоторые компании тоже пытались бороться с этим. В Google есть внутренний документ под названием «Проблема LeetCode», в котором обсуждается, как не дать людям пройти собеседование в Google через практику LeetCode.

Не только проблемы становятся все сложнее и сложнее, но и требования к полноте и правильности также становятся выше.

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

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

Это очень похоже на бесконечную войну; планка кодирования собеседований становится все выше и выше.

Это честно?

Однажды я брал интервью у опытного инженера из солидного стартапа. У него плохо получалось, и он это знал.

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

Ради этого кандидата он явно сдался. Он жаловался:

«Как вы думаете, это справедливо? У меня десятилетний опыт работы в отрасли, но теперь мне приходится соревноваться с новыми выпускниками по проблемам структуры данных и алгоритмов? »

Он выглядел печальным. И мне стало грустно.

И еще есть этот твит от Макса Хауэлла после провала интервью в Google:

Google: 90% наших инженеров используют написанное вами программное обеспечение (Homebrew), но вы не можете инвертировать двоичное дерево на доске, так что отвали.

Итак, это честно?

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

Есть ли другие альтернативы?

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

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

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

Что дальше

Где мы окажемся через несколько лет?

Сможем ли мы придумать лучший подход к оценке кандидатов? Будет ли это более справедливым, менее трудоемким и менее напряженным для кандидатов?

Или это станет еще более безумным? Потребуются ли в конечном итоге навыки конкурентного программирования, чтобы получить работу в отрасли?

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

Я всегда хочу рассматривать процесс собеседования и поиска работы как игру. Мы все в игре. Правила игры могут предусматривать сверхурочную работу. Но если мы хотим играть, мы должны соблюдать правила.

ИМХО, это по крайней мере то, что мы можем сделать:

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

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

Мир большой и довольно разнообразный. Приведенные выше обсуждения основаны на моем очень ограниченном опыте. И они могут ошибаться в другом контексте.

А какой у вас опыт? Что вам нравится, а что расстраивает? Как думаете, что можно улучшить? Как вы думаете, каким должен быть весь процесс собеседования? Я тоже очень хотел бы получить известие от вас! Спасибо за прочтение.