Трудоустройство в Google: структура Hiring Committee

В текущем 2012 году одна из крупнейших мировых компьютерных компаний Google заявила о желании нанять рекордное в своей истории количество нового персонала. Статистика утверждает, что в среднем компания получает в год около миллиона анкет от соискателей, и на данный момент (на конец лета 2012) у неё открыто около 800 свободных позиций, для которых идет активный подбор кандидатов по всему миру. Google привлекает практически всех: сисадминов, дизайнеров, тестировщиков и проектировщиков ПО и баз данных и особенно программистов (носители «родных» для компании языков C/C++/C# и Python здесь особенно в почете). Традиционно в этом потоке «свежей крови» весьма ощутимую долю новобранцев составляют выходцы из Восточной Европы и Беларуси, многие из которых славятся советской математической школой (которая в большей мере сохранена именно в белорусских вузах) и высоким качеством компьютерного образования, подтверждаемого неоднократными победами на международных профильных турнирах. Если вы когда-нибудь подумывали попробовать свои силы в Google – именно сейчас настал наиболее благоприятный для этого момент. В первой статьи из серии мы обсудим устройство Google Hiring Committee, а также систему оценки интервьюируемых. Сразу подчеркиваю: в настоящий момент я не имею никакого отношения к Google и предоставляемая мною информация носит неофициальный и, возможно, отчасти субъективный характер. Данный материал преподносится в виде блоговых записок в нескольких частях, без какой-либо системы или жесткой структуры, поэтому не может претендовать на законченное руководство к действию и уж тем более на истину в последней инстанции.

Точка приложения

Среди ИТ-рекрутеров хорошо известен парадокс, часто называемый «Парадокс питона» (The Python Paradox): давайте попробуем спроецировать его на ситуацию с программистами. Для этого условно выделим в реальной жизни две полярно мотивированные группы программистов. Первая категория – это те, кто учится, чтобы получить в итоге хорошо оплачиваемую и престижную работу, и для этого они автоматически выбирают мэйнстрим в своей отрасли, ибо это значительно повышает их шансы на выгодное трудоустройство. Вторая группа – те, кто рассматривает свою работу не с позиции выгоды, но с точки зрения самовыражения или чистого творчества, при этом не боятся учиться новому или проводить самые смелые эксперименты в поисках своего идеала. Чаще всего в итоге последние выбирают свои повседневные рабочие инструменты/методики по критерию «самое лучшее», что зачастую далеко не синоним «самого выгодного», как это делают их коллеги-карьеристы из первой категории. «Парадокс питона» гласит, что учитывая вышеописанную логику и делая ставку на вторую категорию специалистов «не от мира сего», компания получает в своё распоряжение гораздо более качественный и перспективный кадровый состав. Google очень активно учитывает этот принцип при найме своих специалистов – в следующей части статьи я ещё коснусь того, как резко заинтересовались мною интервьюеры, когда я стал рассказывать о своих наработках в функциональном (Haskell и Yesod) и аспектно-ориентированном программировании, а также когда провел разбор базовой проблематики и мифологии объектно-ориентированной парадигмы. Я специально так заостряю на этом внимание – я пытаюсь подчеркнуть холодную рациональность, стоящую за подобным эксцентричным и странным с точки зрения внешнего наблюдателя поведением компании, когда предпочтение чаще всего получают именно те, кого принято называть гиками. С другой стороны, хотелось бы развеять некоторые откровенные мифы, когда эту специфику чрезмерно гипертрофируют, часто рисуя интервью в Google как сплошной набор невероятных шарад и головоломок. Смею утверждать, что популярная пресса вносит определенную лепту в культивирование этого ложного образа. В качестве наглядного примера: если изучить один из западных бестселлеров на эту тему – книгу Вильяма Паундстоуна – может сложиться впечатление, что интервью в Google полностью состоят из шокирующих головоломок и крайне нестандартных и запутанных заданий. Чтобы пояснить, о чем идет речь, приведу типичный образчик, который, по мнению автора упомянутой книги, – один из самых популярных вопросов на собеседовании этой компании: Оцените количество пользователей Facebook, которые находились в этой социальной сети вчера в интервале с 11 до 12 часов (иногда как вариант, уточняется город, из которого они были). По своему опыту, а также опираясь на огромную эмпирическую базу своего консультанта Джона, могу категорично утверждать, что процент подобных вопросов не превышает 1-6% от всех заданий. Более того, раз уж мы коснулись этой отчасти мифической темы, хотелось бы дополнить её инсайдерской информацией от Джона. По его словам, эта практика тестирования логическими задачами и шарадами была явным образом запрещена на уровне Google Hiring Committee примерно с 2005-2006 годов, который стал активно бороться с подобными модными в своё время вопросами рекрутеров «на местах». Чтобы быть до конца понятым, о каком комитете идет речь, а также попутно для пользы дела пояснить общий алгоритм принятия решений в исследуемой нами компании, остановимся на методике оценки кандидатов и внутренней структуре комиссий по найму в Google.

Устройство системы отбора

Итак, давайте начнем разбираться с самого начала – кто берёт интервью? У технического подразделения Google Engineering нет вообще ни одного штатного менеджера по найму! Но, тем не менее, эта большая работа вполне успешно выполняется. Ответственен за это так называемый технический рекрутер (должность может звучать, например, так: Sr. Technical Recruiter). В подавляющем большинстве случаев он же работает в компании и на некоей штатной технической должности, например, SRE (близкий аналог администратора). По последней причине таких рекрутеров часто именуют инженерами – верны оба определения, не следует здесь путаться. Подобное совмещение ролей повально используется в Google, позволяя проводить по-настоящему глубокие и качественные технические собеседования. Далее каждый такой рядовой рекрутер/инженер по результатам своего собеседования выставляет потенциальному кандидату свою личную оценку, которая лежит в диапазоне от 1 до 4 баллов, при этом эта оценка складывается из следующих составляющих (для примера я взял наиболее близкую мне должность SWE – программист): • Аналитические способности (analytical abilities); • Навыки программирования (coding & design skills); • Опыт работы (professional experience); • Общение (communications skills). По каждому из этих пунктов выставляется максимум один балл (могут ставиться дробные оценки, но не меньше единицы), после чего оценка суммируется (теоретический максимум – 4 балла). Эта оценка, как конечный результат прохождения собеседования, должна сохраняться в тайне как от других интервьюеров, так и от самого участника интервью. Затем она представляется на специальном заполненном бланке в комитет по найму (Google Hiring Committee). У этой структуры есть множество подкомиссией, каждая из которых специализируется на отдельной специальности (например, для администраторов это Site Reliability Hiring Committee). Именно в них централизованно стекаются все данные от всех собеседований множества отдельных рекрутеров низшего звена. Я видел подобный бланк у Джона: кроме оценки и всех её составляющих в него включается краткий отчет о прошедшем собеседовании – в моём случае рапорт начинался с фразы: «Кандидат очень нервничал, поэтому первые 10 минут я успокаивал его, всячески подбадривал и пытался ввести его в рабочий режим, говоря на нейтральные темы, а также обсуждая его биографию». Джон не захотел показывать остальные бланки из тех, что у него были, улыбаясь при этом сквозь зубы: «Там везде одно и тоже, поверь мне». Отмечу, что в последнее время такие отчеты чаще всего предоставляются по электронной почте. Я часто подчеркиваю, что не нужно бояться какой-то личной неприязни со стороны отдельных интервьюеров или единичных провальных интервью в своей серии – вам всегда дадут шанс показать себя с разными людьми и в разных ситуациях, после чего все данные постепенно стекутся в ваш комитет найма. Каждому рекрутеру в Google дается 3 дня на составление подробного отчета (обычно это 2-3 страницы текста), при этом инструкция требует воздерживаться от своих личных оценок (типа «я считаю, что этого кандидата нужно обязательно взять»), вместо этого рекомендуется предоставлять максимальное количество фактов в виде списка. Этот комитет – своего рода локально-региональный рекрутинговый штаб, который определяет текущие потребности данного подразделения компании в определенных людях, формулирует критерии под свою рабочую специфику, подбирает наиболее подходящий под должность и особенности каждого кандидата состав интервьюеров, планирует весь процесс, а затем совместно анализирует и принимает судьбоносные решения по каждой отдельной кандидатуре, и чаще всего делается это коллективно и в режиме обсуждения. Всё устроено так, что люди, которые будут принимать решение, обычно не имеют личного контакта с теми, чью судьбу они будут вершить. Кроме того, каждый член такого комитета принимает своё решение заранее, до очередного сбора всех участников группы. Для этого он: • изучает резюме кандидата; • последовательно изучает все доклады рекрутеров из всей серии собеседований для данной кандидатуры (которые предварительно стекаются к нему по e-mail); • принимает своё предварительное решение, после чего составляет мини-доклад, который отправляет на общий e-mail своего комитета. Так же, как и армия рекрутеров-инженеров, комитет – это динамическая структура, которая работает по совместительству. Например, упомянутый мною SRE Hiring Committee собирается на свои совещания два раза в неделю, курируя процедуры найма параллельно со своей основной повседневной работой в Google.

8 из 10 программистов не в состоянии писать код

Теперь, абстрагируясь от устройства всей этой системы, давайте подведем промежуточные итоги и выделим коридор результатов, необходимых для получения положительного решения относительно кандидата: • средний бал должен быть обязательно выше 3, иначе, скорее всего, у испытуемого мизерные шансы. Диапазон оценки между 2,9 и 3,2 – это так называемые «пограничные кандидаты», их судьба будет решаться на дополнительных собеседованиях; • каким бы парадоксальным это ни казалось, но слишком высокая оценка, вплотную близкая к максимальной (>3,7), – это также причина для отказа (не буду растекаться мыслью, более подробно об этом я буду писать дальше); • наличие сильной неравномерности в серии оценок, а также сразу несколько диаметрально-полярных оценок собеседований (очевидная волатильность результатов) – повод отклонить кандидатуру; • низкие показатели составляющей «communications skills» особенно опасны: вне зависимости от всех остальных оценок, они могут привести к отрицательному результату. В силу многонационального коллектива и большого количества эмигрантов этой составляющей уделяют особое внимание; • некоторые, возможно, «странные» для кого-то моменты сдачи экзаменов, которые я процитировал выше, являются прямым следствием главного регулирующего процесс отбора правила: «лучше пропустить и не взять стоящего кандидата, чем ошибочно подписать контракт с неподходящим». При большом наплыве кандидатов ошибки в первой части условия являются вполне поправимыми и компенсируются количеством потока, в отличие от ошибок во второй части. Важная деталь – молодым в Google дают множество поблажек. Можно воспринимать это как явную дискриминацию по возрасту, но факт остаётся фактом: ошибки, которые запросто прощают «интернам» сразу после университета, никогда не простят опытному разработчику со стажем. Главное правило «возрастной дискриминации от Google»: чем больше у вас возраст, чем выше у вас заявленный опыт – чем жестче уровень требований к вам. Итак, рассмотрев устройство фильтрующего механизма, мы готовы попытаться учесть его особенности. В связи с этим к читателям сразу вопрос на засыпку: по вашему мнению, какая из четырех названных компонентов суммарной оценки наиболее провальная согласно сухим отчетам статистики? Не знаю, угадали ли вы, но, согласно данным Джона, бесспорно, лидирует вторая составляющая – «Навыки программирования» (coding skills). Это то, что заваливают 8 из 10 проходящих интервью людей. Вторая опасная отметка для нашего специалиста – это “communications skills”. Вот на этих двух «больных местах» мы далее и остановимся поподробнее.

Вещи, о которых лучше подумать заранее

Писали ли вы когда-нибудь программы на клочке бумаги? Есть ли у вас навык быстрого составления алгоритма в стрессовой ситуации, когда за тем, как вы пишите программу, внимательно наблюдает несколько человек? Кодировали ли вы, комментируя вслух на чужом для себя языке ход свой мысли? Как насчет опыта олимпиадного программирования и скоростного поиска решений для весьма нестандартных задач? В Google всё это неизбежно: во время интервью вам почти наверняка придётся писать фрагменты программ, функций или классов на настенной доске (white board) или листочках бумаги, а на стадии телефонного интервью будьте готовы к тому, что могут попросить черкануть на Google Docs пару строк кода, иллюстрирующих какую-нибудь концепцию на удобном для вас языке программирования. Поэтому прямо сейчас возьмите листок бумаги и попробуйте написать небольшую программу без помощи уже привычных подсказок/автодополнений со стороны IDE, например, без столь любимой многими IntelliSense в Visual Studio. Есть N коробок. Все они открыты. Некий человек последовательно проходит и закрывает каждую вторую коробку. Затем снова проходит по уже каждой третьей коробке, и если она открыта – опять закрывает, если же закрыта - открывает. Потом повторяет цикл по каждой четвёртой и так до N. Итоговый вопрос: сколько коробок останутся открытыми после окончания прохода? Большинство программистов считает, что это относительно простое задание, поэтому охотно берутся за решение и получают быстрый ответ, но мало кто решает его правильно. После математического подсчета интервьюеры часто просят также смоделировать эту задачу и в программном виде (конечно, результаты прогона по конкретным значениям должны совпасть с математической формулой первого ответа). На своей работе мы предоставляем работодателю уже готовый, отлаженный и заранее продуманный код – сколько исправлений и модификаций кода отделяет его первоначальные схематичные наброски от конечной финальной версии? Но на интервью просто не будет времени и возможности набросать черновой вариант и постепенно его доработать: вы пишете код «на лету» и сразу его поясняете – это и будет ваша окончательная версия решения, которую будут оценивать без всякого снисхождения на полевые условия. Подобный режим – это когнитивный диссонанс по отношению к стандартному и неспешному офисному программированию, где мы обычно тщательно продумываем и оптимизируем каждый элемент своего решения в тиши кабинета, пребывая в спокойном сосредоточении тет-а-тет с кодом, любезно подсвеченным в любимой IDE. Обращаю внимание, как утверждает статистика, при подобном «спортивно-полевом программировании» наиболее распространенный тип ошибки – off-by-one error (OBOE). Если место собеседования территориально далеко от вас, лучше прилететь на пару дней раньше, чтобы успеть с дороги выспаться и акклиматизироваться (хотя в этом случае вам, скорее всего, придется оплачивать это пребывание из собственного кармана). Впереди предстоит несколько дней интеллектуального марафона и естественная усталость от дороги: это не лучший фон для демонстрации ваших пиковых результатов. Следующий момент – это активное использование рекрутерами из Google адаптивных методик. В самом простом случае это значит, что, чем лучше вы будете отвечать, тем более сложные вопросы вы будете получать в продолжение интервью. Джон объясняет, что именно поэтому очень важна равномерность и последовательность знаний – это не лотерея, и здесь не может быть «любимых вопросов», на которых вы рассчитываете выехать. Если вы ответили на какой-то вопрос очень сильно, планка сразу поднимается, и дальше вы должны защищать уровень уже более высокого балла. Именно поэтому не стоит писать в своём резюме излишне амбициозных фактов, доказать которые впоследствии вы будете не в состоянии. *** Пока остановимся на этом эпизоде нашей необъятной темы, чтобы продолжить наш разговор уже в следующей части. В следующей раз мы расшифруем оба кадровых девиза компании Google, непривычных для homo soveticus: «Работать на компанию, а не решать свои проблемы» и «Мы ищем таланты, а не навыки», а также попробуем привести больше реальных ситуаций и задач, которые задавались на реальных интервью в 2011-2012 годах.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.