юирующим запрещено озвучивать какую-либо частную оценку вообще. От себя замечу, что, как правило, это условие выполняется, добавляя интригу в довольно нервный марафон из нескольких собеседований.
Давайте опишем ход такого очного собеседования более конкретно. Сколько их в серии и как они проводятся?
Количество очных интервью обычно колеблется от трех до восьми. В зависимости от конкретного офиса и принятых там правил, эта серия либо растягивается на 2–3 дня (редко), либо упаковывается в один день (чаще всего). Надо отметить, что само по себе такое интервью очень интересно неравнодушному к своей профессии специалисту вне зависимости от конечного результата. Сразу хочу заметить, что времени от окончания интервью до принятия решения может уйти очень много, не нужно принимать это на свой счет.
Итак, во всех случаях, что я знаю, первое интервью начинались в первой половине дня, в моем случае — в десять утра. Это очень плотный марафон из собеседований, когда один «свежий» специалист сменяет другого, когда тот закончил. В середине дня делается обязательный перерыв на обед в фирменной столовой. В хороших случаях применяется хоть какое-то разделение ролей. Например, первый гуглер спрашивает вас о предыдущих проектах, самых интересных задачах, с которыми приходилось столкнуться, второй — только про алгоритмистику, третий задает чисто технические вопросы по Java и фреймворкам, четвертый — «а нарисуйте мне классы для такого-то типового проекта» и т. д. На каждого уходит минут 30–50, соответственно, общее собеседование может сильно растянуться.
Мое интервью перед устройством в Google состояло из серии 5 интервью по 45 минут. С перерывом на часовой обед на это ушло 6 часов. Перед началом каждого 45-минутного «сеанса допроса» вам предлагают сходить за водой-чаем-кофе или в туалет на 10 минут, советую воспользоваться этими предложениями, чтобы немного развеяться и взбодриться.
Иногда интервьюеры ведут журнал вопросов, чтобы избежать повторений. Но это опять же в лучших случаях, чаще всего информацией между собой они не обмениваются и роли никак не распределяют, поэтому часты повторы.
Для чего это делается и как вести себя, если тебя третий раз спрашивают одно и то же, как в случае вашего примера с hash map?
Это не редкость. Теоретически повторы допускаются для того, чтобы исключить субъективность в оценке кандидата конкретным человеком. Правильная модель поведения — подчеркнуто вежливо уточнить: ваш коллега задавал этот вопрос ранее, следует ли повторить мой ответ еще раз?
Наверное, подобные интервью — сильный эмоциональный опыт со всех точек зрения?
Первый раз, конечно, навсегда остается в памяти: раньше вы видели эту великую компанию в обезличенном виде, через призму ее сервисов, сейчас же за чашечкой кофе обсуждаете технологии непосредственно с ее ведущими разработчиками (сами сотрудники называют это чувство «Google experience»). Заблудиться в самой компании будет сложно — с самого утра прибыв в офис (лучше не приходить сильно рано или с опозданием, идеально за 5 минут до назначенного времени), вы сообщаете цель своего визита и регистрируетесь на стойке ресепшен. После чего вам выдают персональный бэдж и вызывают вашего рекрутера, который встречает вас с распростертыми объятиями и сияющим лицом, будто вы знакомы как минимум последних лет сто.
В первый такой визит достаточно типична небольшая экскурсия по огромному кампусу Google, угощение бесплатными напитками и печеньем, равно как и разговоры не о чем, достаточно типичные для двух совершенно незнакомых людей. Все это быстро заканчивается демонстративным поглядыванием рекрутера на свои часы и холодящей дух фразой: «Ну что, будем начинать?»
Из ваших лекций я знаю, что один из типичных акцентов подобных интервью — «низкоуровневые дискуссии обо всем на свете». Можно привести пару примеров из жизни?
Самая большая часть интервью — это техническое обсуждение выбранной вами предметной области. Очень часто вопросы могут лежать за пределами сферы компетенции рассматриваемой должности, к этому нужно быть готовым. Например, мой хороший знакомый претендовал на должность SRE, [1 Эквивалентно нашему «системный администратор»] при этом его спрашивали о специфике некоторых системных вызовов в API Linux и специфике fork() в разновидностях Unix, что требует не только теоретических знаний сисадмина, но и хорошего практического опыта в области системного программирования.
Также привожу для примера похожий вариант, который имел место на моем втором собеседовании на должность программного разработчика (SWE). Как правило, на таких интервью присутствует несколько человек, последовательно выполняя роль ведущего. В моем случае интервью вел лишь один инженер, который после короткого вводного приветствия и стандартных расспросов (что мне нужно от жизни и от Google в частности?) быстро изложил суть первого задания:
Предположим, обычный пользователь набирает в адресной строке своего любимого браузера http://disney.com и тут же получает в ответ страницу. Теперь давайте обсудим как можно более подробно, что происходит в промежутке между нажатием клавиши Enter и полным отображением страницы в браузере.
Ведущий демонстративно посмотрел на наручные часы и предупредил: «Сейчас без четверти два пополудни, у меня есть время до пяти часов вечера, думаю, если поспешим, мы должны уложиться». Отмечу лишь, что в моем случае я окончательно запутался, когда мы дошли до разбора деталей процедуры TCP handshaking, затем также споткнулся на этапе рендеринга страниц движком браузера. «А жалко, — сообщил улыбающийся интервьюер, — я надеялся, что мы успеем еще повторно прогнать все это для случая https». Поэтому будьте готовы к максимальной детализации (и неизбежному при этом выходу за рамки вашей специализации). В описанном случае, обсуждая работу браузера и web с прицелом на позицию веб-разработчика, в итоге мы «провалились» до уровня работы ethernet-фреймов и пограничного протокола маршрутизации BGP.
Другое подобное задание, после которого мы постепенно докатились до обсуждения архитектуры процессора, звучало так:
«Дается кусок программы на Си, работающей со строками (отдельная функция). Требуется объяснить и нарисовать на доске, что на каждом шаге ее выполнения происходит в памяти компьютера.»
Обычный паттерн здесь таков: сначала задается какой-то относительно простой вопрос, например «чем свитч отличается от хаба», после чего начинаются рекурсивные циклы уточнения деталей и постепенное погружение во все более и более низкоуровневые детали, пока вы не упретесь в свой потолок — какой-то вопрос, на который уже не знаете ответа. Этот уровень фиксируется, и после пары косвенных подсказок вас оставляют в покое, давая возможность немного отдышаться на каком-нибудь завуалированном личностном тесте, чтобы начать новый цикл «отладки темы» с какого-то очередного очень общего стартового вопроса. Для подобных глубоководных погружений «в суть вещей», как минимум, нужно знать как «отче наш» семь уровней взаимодействия модели OSI/ISO и четыре уровня сетевой модели ТСР/IР, а также базовые принципы работы процессора.
Я знаю, у вас на тренинге разбирается очень много похожих примеров, но насколько они полезны и близки к реальным интервью?
Да, у нас очень много похожих примеров, и мы стараемся держать их максимально актуальными. Мы тратим на анонимный сбор подобных вопросов очень много времени и сил. Кратко поясним, почему это так важно.
Перед началом очных собеседований у вас возьмут формальную расписку о неразглашении задач и деталей интервью — это соглашение (NDA) сохраняет юридическую силу, как в случае, если впоследствии вы были приняты на работу, так и в противном случае. Почему Google так жестко защищает содержание собеседований? Краткий ответ — потому что структура вопросов и их общий шаблон очень часто повторяются (мы уже кратко касались этого). Если актуальные задачи или вопросы где-то всплывают «в паблик», они отбраковываются, в противном случае воспроизводятся снова и снова. Такое положение дел — фирменная специфика Google. В этом плане вы имеете очень сильное преимущество, если у вас есть инсайдерская информация.
Почему они крутят одни и те же вопросы в большинстве разных интервью, что за этим стоит?
Главная причина в том, что продолжительные исследования доказали, что самый лучший способ бороться с непреднамеренной (или умышленной) предвзятостью интервьюеров к кандидатам (а это отдельная большая проблема для многонациональной и очень разнородной компании типа Google) — максимально структурировать и типизировать спектр задаваемых вопросов и задач. Об этом очень много говорят на корпоративных подготовительных курсах в тот момент, когда гусеница-инженер превращается в бабочку-рекрутера.
К примеру, сейчас примерно 80 % работников Google — это парни, из них 65 % — белые. Но проблема уходит далеко за рамки гендерных или расовых предрассудков.Вот типичная ситуация для лучшего раскрытия темы. Вы предлагаете на собеседовании для решения задач свой любимый язык, в котором вы — дока, пусть это будет Haskell для примера. Гуглер соглашается, хотя может не знать этот язык так же хорошо, как и вы (чаще всего он верит в лучшее). И впоследствии, анализируя решение своей задачи, может не понимать до конца ваших подходов, если вы действительно большой гуру функционального программирования или предложенной проблематики. Это поле для огромного количества недоразумений и личных обид, попранных самооценок и желания реванша. Все ведущие — молодые ребята, и, поверьте, не всем из них приятно осознавать свои ошибки, непонимание или показательную слабость, порой такой поворот интервью становится исключительно вашей проблемой. В Google знают о периодических межличностных аберрациях и подобной «дедовщине», и в компании искренне пытаются бороться с такими ситуациями. Они сделали отличные образовательные курсы «Course