Отъявленный программист: лайфхакинг из первых рук - Игорь Савчук

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

Это второй (после самих собеседований) уровень анализа результатов собеседований (так называемая стадия Executive Review).

Как работает этой второй после собеседований уровень отбора?

Такие же обычные инженеры-рекрутеры, не участвующие в очных собеседованиях, раз в неделю получают запрос на рассмотрение 5–8 новых кандидатов. В свободное от основной работы время им нужно изучить для каждой полученной кандидатуры:

• резюме;

• все отзывы с его собеседований (которые были составлены и отправлены на предыдущем уровне; обычно от 3 до 8 отзывов в зависимости от количества собеседующих);

• отзыв реферала (если таковой есть).

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

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

• Умеет ли кандидат писать быстрый и точный код?

• Насколько быстро и легко кандидат решает задачи из области своей заявленной компетенции? (Подтверждение опыта.) 

• Способность быстро находить ошибки, в том числе в своем коде. Адекватность реакции на подсказки и помощь. 

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

• Отдельные случаи во время интервью (как правило, все нестандартные и интересные ситуации документируются отдельно).

• Коммуникативные способности и легкость в общении. Соответствие принципам компании и «гугловость».

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

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

Повторюсь, что, так же как и армия рядовых рекрутеров-инженеров, рекрутеры из комиссии — это динамическая и открытая структура, которая работает по совместительству. Например, упомянутый мною SRE hiring committee собирается на совещания два раза в неделю, курируя процедуру найма (фактически для своих собственных нужд) параллельно со своей основной работой в компании.

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

Приведу набор эмпирических фактов.

• Средний балл должен быть обязательно выше 3, иначе, скорее всего, у испытуемого маленькие шансы. Диапазон оценки между 2,9 и 3,2 — это так называемые пограничные кандидаты, вероятно, их судьба будет решаться на дополнительных собеседованиях.

• Каким бы парадоксальным это ни казалось, но слишком высокая оценка, вплотную близкая к максимальной (>3,7), — это также причина для отказа (не буду повторяться, я уже говорил о выбраковке самых лучших).

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

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

Дополнительно я бы хотел упомянуть здесь о двух интересных деталях. Если статистический анализ выявляет, что кто-то из рекрутеров постоянно «заваливает кандидатов», это также будет учтено внутри комиссии, автоматически понижая вес его мнения.

Вторая крайне важная деталь — молодым в Google дают множество поблажек. Можно воспринимать это как дискриминацию по возрасту, но факт остается фактом: ошибки, которые запросто прощают «интернам» сразу после университета, никогда не простят опытному разработчику со стажем. И наоборот — чем выше ваш возраст, чем выше у вас заявленный опыт — тем более жесткие требования будут предъявляться к вам. Получая молодого специалиста (до 26 лет), компания еще имеет время сформировать его как специалиста, говоря о людях после 35 лет — Google намерена нанимать только состоявшегося и матерого специалиста, и никак иначе. Именно поэтому уровень задач, отношение и сложность вопросов к этим двум возрастным группам заметно различаются.

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

Не знаю, совпадет ли ответ с вашими ожиданиями, но согласно моим данным, бесспорно лидирует составляющая «Навыки программирования» (coding skills). Это то, что заваливают 7 из 10 проходящих интервью человек. Вторая опасная отметка для иностранного специалиста — «communications skills».

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

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

В Google все это неизбежно: во время интервью вам почти наверняка придется писать фрагменты программ, функций или классов на настенной доске (white board), а на стадии телефонного интервью будьте готовы к тому, что вас могут попросить черкануть пару строк кода на Google Docs, иллюстрирующих какую-нибудь концепцию на удобном для вас языке программирования. Вам придется программировать после долгого перелета и смены часовых поясов. Поэтому прямо сейчас возьмите листок бумаги и попробуйте написать небольшую программу без помощи уже привычных подсказок/автодополнений со стороны IDE (например, без столь любимой многими IntelliSense в Visual Studio) — исключительно по памяти.

Есть N коробок. Все они открыты. Некий человек последовательно проходит и закрывает каждую вторую коробку. Затем снова проходит по уже каждой третьей коробке и, если она открыта, — опять закрывает, если же закрыта — открывает. Потом повторяет цикл по каждой четвертой, и так до N. Итоговый вопрос: сколько коробок останутся открытыми после окончания прохода?

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