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

Однажды ко мне подошел мой начальник и попросил провести техническое собеседование. Поскольку я не был к этому готов, я пожал плечами. Он сказал: «Не беспокойтесь. Просто погуглите несколько вопросов, связанных с C++ и ООП (наш технический стек в то время)».

Я все еще колебался. На это он сказал: «Расслабьтесь. Мы провели около 20+ интервью, просто погуглив. Наша формула 10–10–100. 10 баллов за вопрос, 10 вопросов для теста, чтобы в сумме получилось 100. Двоичный код в шестнадцатеричном, мы называем это 84 ».

Это чем-то напомнило мне «1984» Джорджа Оруэлла.

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

Когда я проснулась. Я был ошеломлен. Нет единообразия при приеме на работу в продуктовую компанию из списка Fortune 500?

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

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

Это требует вечного вопроса: если это не стандартизировано, как вы обеспечиваете нейтральность? И если он стандартизирован, как обеспечить его сохранность без документации?

Неоднозначность вопросов на собеседовании убивает как кандидатов, так и интервьюеров:

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

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

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

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

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

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

Не поймите меня неправильноg: есть роли, где подходит формат STAR. Когда программисты являются техническими евангелистами, они вполне логичны. В остальном кандидаты больше заняты угадыванием вопросов, а не подготовкой к ответам.

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

Результатом стала Моя последняя электронная книга об интервью с ведущими разработчиками (скидка 50% для первых 100 пользователей Medium), в которую я включил 26 ЗВЕЗДНЫХ и 15 не-ЗВЕЗДНЫХ вопросы с соответствующими ответами и углубленным анализом.

STAR точно соответствует высоким ролям, связанным с клиентами или заинтересованными сторонами. Примером может служить архитектор AWS — роль, которая является наиболее популярным источником этой методологии.

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

  • Просто задайте 1 фиксированный вопрос — избавьте кандидатов от двусмысленности.
  • Сосредоточьтесь на ответе, чтобы оценить и сравнить кандидатов

Единственный вопрос на собеседовании, который подходит большинству технологических фирм:

Ранее я написал популярную статью для СМИ на аналогичную тему:



Единственный вопрос для собеседования по программированию, к которому нужно подготовиться
Несмотря на то, что я провел 500 собеседований, все сводилось к одномуbestprogramming.pub



Это было написано с точки зрения кандидата. Если вы дочитаете статью до конца, то поймете, что все ее содержание остается в силе.

Однако на этот раз мы обсуждаем с точки зрения интервьюера.

Единственный вопрос на собеседовании, который вам нужно задать кандидату:

Опишите свой лучший проект/работу по программированию.

Обратите внимание, что:

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

Дьявол кроется в деталях:

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

Допустим, вы поставили этому вопросу 100 баллов, идеальная разбивка вопроса должна быть такой:

Выбор проекта/задачи: 10 баллов

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

Описание проблемы: 20 баллов

Это даже важнее, чем сама задача, потому что она обеспечивает перспективу, а перспектива — это все.

Назначьте 10 баллов за каждый вопрос:

  • Описал ли кандидат входы и выходы?
  • Объяснил ли кандидат ценность, которую бенефициар/конечный пользователь получит от функции/задачи? Например, если лучшим проектом кандидата была функция входа в систему, описал ли он, для кого она была сделана и в какой степени она соответствовала своей цели? (например, установите флажок, чтобы запомнить логин на 2 недели, чтобы не применять пароль)

Сложность задачи: 50 баллов

Это мясо. Смог ли кандидат обосновать сложность задачи? Обратите внимание, что он не обязательно должен быть универсально сложным, как лунный модуль НАСА. Однако, учитывая статус кандидата на момент решения задачи, это должно быть достаточно сложно.

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

  • Предварительные условия: какие тренинги/учебники/курсы программирования он уже прошел перед этой задачей.
  • Исходные данные. Какие исходные данные он получил в отношении спецификаций.
  • Оценка и проектирование. В чем заключалась сложность: анализ, внедрение, тестирование или что-то еще? Была ли оценка усилий? Был ли этап проектирования? (попросите чертеж, если это необходимо)
  • Время + усилия: что он сделал, чтобы преодолеть это, и сколько времени это заняло? (запросите заявление API / кода, если это необходимо)
  • Самооценка: что он сделал, чтобы проверить и оценить свою работу?

Итог: 20 баллов

Это для оценки:

  • Чему кандидат научился из задачи и опыта
  • Был ли у него шанс применить полученные знания когда-нибудь после этого? Ответ на этот вопрос не должен отличать недеятелей. Но вы должны, по крайней мере, ожидать, что у кандидата есть некоторое представление о том, как использовать полученные знания в будущем. Вы можете составить таблицу баллов, которая выглядит следующим образом, и гарантировать, что конкретные мыслители + конкретные действия получат полные 20 баллов.
Concrete Idea: 10 points
Poor Idea: 5 points
Concrete Implementation: 10 points
Poor Implementation: 5 points

Общая:

Это составляет 100 баллов.

Последнее замечание:

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

Заключение:

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

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

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

Еще до того, как вы встретитесь с ним/ней на собеседовании.