Желая устроиться в Google, в подавляющем большинстве случаев вы будете первоначально иметь дело с ее рекрутерами – специальным сословием коммуникабельных людей, обученных находить и отбирать нужных для компании людей по всему миру и, как правило, попутно достаточно неплохо ориентирующихся в предметной технической области, для которой они привлекают народ. Они и проводят первичные интервью-собеседования, чтобы принять предварительное решение на ваш счет и произвести заочный отсев откровенно слабых кандидатов. Для инициации запуска этого процесса типичной является ситуация, когда вы на официальном сайте компании подбираете себе позицию (см. www.google.com/jobs), после чего отправляете на указанный там контактный адрес резюме со своим предложением и данными. В случае если вы достаточно убедительны и интересны, с вами связывается ответственный за эту должность рекрутер. В более редких случаях возможно обращение к вам такого рекрутера и по своей инициативе (как это было когда-то в моем случае), например, в ответ на заинтересовавшую его техническую статью в вашем блоге. Сразу настройтесь на то, что устройство на работу в крупную компанию США (это касается не только Google), как правило, растягивается на 3–8 месяцев – это абсолютно нормальная ситуация.

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

Совершенно верно. В случае положительного ответа рекрутера на ваше резюме вы договариваетесь с ним заранее о точной дате и времени первого телефонного интервью (Phone screening). Тщательно согласуйте общее время с учетом разницы во временных зонах. Здесь нужно четко понимать, что эти два-три (редко доходит до пяти) телефонных собеседования – только предварительная фаза, лишь начало длинного пути.

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

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

Для примера приведу стандартную структуру телефонного интервью (следует после первичного):

1. Знакомство (5 минут).

2. Разогрев – заведомо простые теоретические вопросы, например, зачем нужны шаблоны в C++ (5 минут).

3. Написание кода – решение относительно простых задач (15 минут).

4. Написание кода – решение более сложной задачи, если простая задача была решена. В противном случае разбор и анализ задачи из пункта 3 (20 минут).

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

В итоге мы получаем 35–50 минут – это стандартное по продолжительности для Google интервью.

Возможно, если у рекрутера будут сомнения в собственных силах, он может привлечь к телефонному собеседованию отдельного технического специалиста, о чем заранее предупредит вас. Очень часто просят выполнить какую-нибудь типовую задачу и выслать на указанный e-mail либо решить ее в режиме реального времени, набирая текст вашей программы-решения прямо в Google Docs (рекрутер заранее готовит документ с набором задачек, сбрасывая вам ссылку в начале интервью и «расшаривая» доступ). Использовать поиск и вспомогательные IDE при этом, конечно, строго запрещено, ведущий интервью будет удаленно видеть, как вы набираете ваш код, и обсуждать его с вами в режиме реального времени.

Несмотря на то что Skype запрещен в офисе Google и для голосовых звонков рекомендуется использовать gTalk, в реальности с вами могут связаться как через первое, так и через второе либо даже обычным звонком на контактный телефон (указанный в резюме).

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

Вот лишь некоторые примеры реальных телефонных вопросов на должность SWE:

• Чем процесс отличается от потока?

• Какие отличия у мутекса и семафоров?

• Чем hash table отличается от hash map? (вариант: чем hash table отличается от hashset?)

• Объясните на каком-нибудь примере из повседневной жизни, что такое полиморфизм.

• Как максимально эффективно реализовать рандомизацию массива?

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

Как видно, здесь нет никаких закавык и тонкостей, лишь максимально широкий обзор самых общих моментов.

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

В моем случае трудоустройства я хотел проходить собеседование в Чикаго, потому что в тот момент работал там. Но они не захотели (там не было подходящих позиций), тогда мы сошлись на бостонском офисе Google, после чего мой рекрутер выполнил трансфер моего дела к своему коллеге из Бостона, который в свою очередь подключил к моему сопровождению местного координатора путешествий (travel coordinator). Google, как правило, оплачивает ваш перелет в место собеседования, проживание там, решает возможные визовые вопросы, а также предоставляет обратный билет – все эти вопросы детально обговариваются с координатором компании заранее. Он свяжется с вами самостоятельно после того, как вас пригласили на очное собеседование. Хочу сразу обратить внимание – у него очень большой поток людей (отсюда такое устойчивое реноме «забывчивых» гугловских координаторов), поэтому перепроверяйте перед вылетом все, о чем с ним договаривались, так как проколы случаются (shit happens).

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

Но имейте в виду, что ваша история прохождения интервью сохраняется в недрах Google, даже если вы будете подаваться в другом месте. Обычно если человек в первый раз завалил какую-то конкретную тему и на втором собеседовании он снова создал awkward moment ровно на том же самом месте (теме), то такого претендента перед следующей попыткой могут попросить подучиться дольше. Обычно раньше чем через 18–24 месяца с вами никто общаться не захочет. Про третью и четвертую неудачные попытки с однотипной ошибкой давайте рассуждать не будем, потому что это пахнет уже перманентным баном.

На этот вопрос невозможно дать конкретный ответ, потому что здесь нет никаких нормативов или внутренних стандартов со стороны Google. Лет пять назад все сводилось к 2–3 неделям ожидания, сегодня – доходит до 7 недель и даже больше. Я знаю отдельные случаи, когда респондент так и не получал официального ответа после завершения серии телефонных собеседований, но его рекрутер через несколько недель перезванивал ему на мобильный телефон и, в сущности, в приватном разговоре отказывал (как обычно, причина отказа и допущенные ошибки не обсуждаются).

Но если позволите, выходя за рамки вопроса, я бы предложил более общее решение этой проблемы. Как уже отмечалось, есть два пути попасть на собеседование – через самостоятельную подачу резюме и через обращение к вам с предложением непосредственно по инициативе Google. Второе – достаточно распространенная ситуация для более-менее публичных персон. К примеру, если у вас есть интересный технический блог или вы участвовали в крутой конференции, где вас заметили и оценили, либо ваши проекты на слуху – к вам могут запросто обратиться с подобным предложением. Это ситуация также встречается среди заметных разработчиков Open Source. Еще одна категория активно завлекаемых людей – те, кто имеет опыт работы в Top Players (ведущих компаниях индустрии). Я знаю не понаслышке, как внимательно относятся в Google к тем, кто работал в Microsoft и других крупных IT-компаниях, – высококвалифицированной рабочей силы остро не хватает, и самый «тупой» метод при ее поиске – это «выцепить» нужных сотрудников у конкурентов. Отсюда агрессивная расклейка объявлений о найме на остановках возле кампусов конкурентов и персональный обзвон с интересными предложениями о работе. Есть даже такая специализация у гугловских рекрутеров – работа с пассивными кандидатами, то есть людьми, у которых уже есть хорошая работа и которых так просто оттуда не выкуришь. Таких рекрутеров отдельно учат, как лучше «продать свой товар», чтобы заманить пассивного претендента на собеседование.

Но для простых смертных есть и третий способ подачи документов, и он самый эффективный. На нем я бы и хотел акцентировать внимание. Это попадание на собеседование через знакомого-реферала (через корпоративную систему рекомендаций). Что это значит? Любой человек, уже работающий в Google, может порекомендовать вас для собеседования. Для этого есть специальная внутренняя процедура, ведь компания совершенно искреннее заинтересована в том, чтобы найти и привлечь к себе высококвалифицированных специалистов. Жизнь доказывает, что, как правило, они роятся «кластерами», подобно пчелам, и, если один из них уже работает в Google, почему бы не перетянуть туда его друзей по старым проектам, компетенцию которых первый гарантирует? Компания рассматривает эту ситуацию как шанс, которым не прочь воспользоваться.

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

Дело в том, что ему это ничего не стоит, разве что полчаса потраченного времени. Он ничем не рискует – в своей заявке на рекрутера он может честно указать о вашем виртуально-шапочном знакомстве, но даже этого будет достаточно, чтобы механизм был запущен. Более того, даже если реферал и знаком с вами давно и лично и написал вам шикарный «репорт», по своему опыту найма в Google я вижу, что такой фидбек может быть воспринят Комитетом по найму как предвзятый, что оставляет давнюю полемику об идеальном реферале открытой.

Впрочем, говоря прямо и откровенно, вашему рефералу может быть совсем не все равно насчет вашей судьбы – не секрет, что большие компании платят (referral bonus) своим сотрудникам за кандидатов, которые были ими порекомендованы и впоследствии успешно наняты. Пару лишних тысяч долларов пассивного дохода за полчаса потерянного времени – не такая плохая прибавка даже для гуглера. В любом случае, даже если кто-то вам и откажет, просто ищите другого. Это удобно и просто делать, проводя «ковровую бомбардировку» сотрудников Google через Linkedin.

Плюсов много, я приведу для примера два. Во-первых, исчезает неопределенность после прохождения вами собеседований. Ваш реферал имеет непосредственный контакт с рекрутером, к которому направил свою заявку, и он всегда может уточнить результаты и сроки рассмотрения, а также детали прохождения вами интервью. Даже при отказе в трудоустройстве большинство претендентов слышат уже знаменитую гугловскую фразу вежливого отказа: «You are not one of us». Но в случае реферала вы сможете узнать все интимные детали с «черного хода», чтобы провести свою личную работу над ошибками (я уже говорил, что второй отказ очень нежелателен?).

Во-вторых, без реферала вам придется как-то обратить на себя внимание еще на стадии отбора резюме, а сделать это не так-то просто, ведь за месяц количество получаемых анкет весьма велико (у каждого конкретного рекрутера оно варьируется от сотни до тысяч). Здесь вы минуете эту самую узкую стадию – если подходящая должность имеется, с вероятностью 80 % вас пригласят на телефонное собеседование. Есть множество других плюсов, если, к примеру, у вас нет профильного высшего образования…

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

С другой стороны, если вам придется делать рабочую визу в США, то одно из условий ее получения – наличие законченного высшего образования по специальности (H1B без высшего образования получить, конечно, можно, но сделать это очень сложно). Впрочем, о визах предлагаю поговорить чуть позже, чтобы не отвлекаться в этой части интервью. Рекрутер также знает о визовых сложностях, и я не думаю, что он костьми ляжет, защищая перед руководством необходимость нанять именно вас, создавая головную боль себе и огромному количеству других сотрудников, которым придется как-то разгребать ваши потенциальные визовые проблемы. Прошу прощения, если кого-то расстраиваю, но это не удел рядового сотрудника без имени и громкого статуса, это точно.

Поэтому, суммируя все, можно сказать, что высшее образование все-таки желательно.

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

Поэтому в этом пункте я хотел бы обязательно предостеречь: не нужно терять дух и психологическое равновесие даже в необычном для любого новичка окружении. Оказавшись в недрах поискового гиганта, не нужно представлять себе сотрудников Google как неких богов во плоти – по моей, возможно, субъективной оценке, их уровень подготовки на деле весьма и весьма разный.

Проиллюстрирую эту мысль на примере. Мне трижды (разные интервьюеры в серии) задавали вопрос о реализации hash map – похоже, это вообще рекорд по степени важности этой темы в глазах Google. При этом любопытно, что у первых двух мое объяснение прошло на ура, тогда как третий ведущий остался недовольным. На мою просьбу объяснить, в чем же моя ошибка, он ответил отказом, лишь посоветовав «почитать про hash map позже и хорошо отдохнувшим».

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

Количество очных интервью обычно колеблется от трех до восьми. В зависимости от конкретного офиса и принятых там правил, эта серия либо растягивается на 2–3 дня (редко), либо упаковывается в один день (чаще всего). Надо отметить, что само по себе такое интервью очень интересно неравнодушному к своей профессии специалисту вне зависимости от конечного результата. Сразу хочу заметить, что времени от окончания интервью до принятия решения может уйти очень много, не нужно принимать это на свой счет.

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

Мое интервью перед устройством в Google состояло из серии 5 интервью по 45 минут. С перерывом на часовой обед на это ушло 6 часов. Перед началом каждого 45-минутного «сеанса допроса» вам предлагают сходить за водой-чаем-кофе или в туалет на 10 минут, советую воспользоваться этими предложениями, чтобы немного развеяться и взбодриться.

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

Это не редкость. Теоретически повторы допускаются для того, чтобы исключить субъективность в оценке кандидата конкретным человеком. Правильная модель поведения – подчеркнуто вежливо уточнить: ваш коллега задавал этот вопрос ранее, следует ли повторить мой ответ еще раз?

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

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

Самая большая часть интервью – это техническое обсуждение выбранной вами предметной области. Очень часто вопросы могут лежать за пределами сферы компетенции рассматриваемой должности, к этому нужно быть готовым. Например, мой хороший знакомый претендовал на должность SRE[12], при этом его спрашивали о специфике некоторых системных вызовов в 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 On Unconscious Bias» для своих рекрутеров, но этого мало. Курсы начинаются с подробного разбора личной истории Эйнштейна, которого, как известно, его школьные учителя считали полным идиотом и даже пытались исключить из колледжа в юности. Другая попытка решения подобных проблем – запуск отдельной экспериментальной программы найма для девушек/женщин, которые желали бы работать в Google, также есть ежегодные «женские» стипендии Фонда имени Аниты Борг и подобные им инициативы (кстати говоря, за последние полтора года количество женщин в Google увеличилось с 8 % до 20 %).

Одно из практических последствий подобных усилий – четкое структурирование интервью и фиксированный список вопросов и задач, которые могут вам предложить. Поэтому в наше время у ведущего подобного собеседования не такой уж большой простор для маневра, и времена, когда он мог запросто попросить вас подсчитать в уме количество люков в Сан-Франциско, остались далеко позади. С другой стороны, именно поэтому так необходима юридическая защита типа упомянутого ранее соглашения о неразглашении (NDA), чтобы сохранять эту зафиксированную схему эффективной и работоспособной. Только обет молчания позволяет им повторяться, но мы пытаемся эксплуатировать эту уязвимость на наших курсах.

(Пауза.)

«Реверс инжиниринг» этого достаточно костного механизма для поиска «креативных и неординарных людей» сам по себе забавен. (Смеется.)

Это важная фаза – зондирование ваших личностных предпочтений и общей мотивации. Она особенно часто применяется к нерядовым позициям, тогда как для начинающих «джуниоров» может практически отсутствовать. Здесь оставим за пределами контекста степень ваших профессиональных познаний и возможностей, эта часть собеседования стремится ответить на простой, но важный вопрос: насколько вы действительно готовы вкалывать во благо компании?

На самом деле у вас никогда не спросят об этом напрямую. Во всяком случае это подтверждают все коллеги, с кем мне довелось побеседовать на эту тему. Но, с другой стороны, проверят этот пунктик с вероятностью 80 %. Для этого будут использованы косвенные опросы для выявления так называемых личностных аттракторов (скрытых мотиваций) собеседника.

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

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

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

Часто это превращают в некое подобие игры для респондента, когда он со вкусом, старательно взвешивая свои предпочтения, перечисляет тот минимум, на который он, так уж и быть, согласится. Проблема в манипулятивных симуляторах подобного рода всегда лишь в том, что никто не собирается учитывать эти требованя или предпочтения. Задача совсем другая: опытный интервьюер уже через 20 минут получает на руки путевую карту личностных стимулов, целей и реакций человека. Хочу сразу предупредить, что я не сторонник «оптимизировать» свои ответы под ожидания работодателя (и хочу призвать читателя даже не пытаться делать этого). Отставим моральные принципы в стороне, дело совсем не в этом: не стоит это делать хотя бы потому, что более опытный в этой процедуре ведущий почти всегда заметит любую неискренность. Кроме приведенного стартового задания в процессе рутинного для него разматывания вашего глубоко личного клубка из аттракторов используется множество перекрестных и уточняющих вопросов, ответить на которые на лету и без предварительного продумывания «их логических последствий» просто невозможно. Поэтому, повторюсь, я рекомендую просто расслабиться и быть самим собой, если вы чувствуете, что попали «под отладчик» профессионального психолога.

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

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

Переводя на повседневный язык: вы зациклены на своем саморазвитии и прокачке профессиональных скиллов, считаете престижным просидеть часть своей жизни в роскошных кампусах одной из крупнейших мировых компаний?.. Кхм, простите, а вы уверены, что компании типа Google хоть как-то озабочены вашими личными целями?

Несмотря на нагнетание подчеркнутого человеколюбия к своим сотрудником, нам как рекрутерам часто повторяли важнейшую формулу для отбора – нужен кандидат, у которого «future with Google», а не «future in Google». Google постепенно отходит от формулы потакания раздутым эго своих сотрудников (одна из причин, почему так называемое «правило 20 %» больше не действует), все больше превращаясь в стандартную, ориентированную на прибыль компанию. В любом случае, я вас предупредил: секрет прохождения этой фазы интервью – в правильных приоритетах.

Мы ищем таланты, а не навыки – это дословная формула от Брайана Пауэра, начальника отдела кадров в Google. Член совета директоров Google Лазло Бок, возглавляющий департамент по найму сотрудников, формулирует еще более точно: «Демонстрируйте навыки, а не опыт». Что касается человеческих качеств, от вас ожидают жертвенности в пользу компании, а также трудоголизма на грани фанатичности, поэтому постарайтесь никого не разочаровать своим «разносторонним жизненным бэкграундом» и «обилием самых разных увлечений» во время интервью.

Это значит, что ваши текущие навыки и степень погружения в вопрос имеют второстепенное значение. Точка.

К примеру, даже если вы крупный специалист в C++, есть большая вероятность, что вам придется полностью переучиваться на фирменный язык компании Go, на котором сейчас много пишется в Google. У Go много специфики, о которой вы, возможно, никогда и не слышали, например многомерные методы goroutines всегда выполняются одновременно и независимо друг от друга (для гипотетического стандартного специалиста по C++ поясню, что мы живем в эпоху многопроцессорных систем и параллельных вычислений). Иначе говоря, однозначно придется учиться чему-то новому, и никто даже не знает, что будет на повестке завтра. Темп устаревания текущих знаний сильно связан с общими темпами развития отрасли и особенно велик в инновационных компаниях такого калибра, как Google.

Итак, исторически первой обратила внимание на эту ИT-специфику «агрессивной инновационности» компания Microsoft. Она стала применять различные головоломки и задачи на общую сообразительность для выявления подобного адаптивного потенциала еще в далеком 1990 году. Чтобы отсечь мнимые преимущества так называемого интеллектуального багажа знаний, в такое тестирование часто вводят фактор ограничения по времени или еще чаще – некий элемент абсурдности в условии самой задачи, чтобы максимально затруднить проекцию ваших повседневных знаний/навыков. Конечная цель – тестирование и выявление вашего креативного потенциала, поэтому подобные «странные интервью» – лишь способ определить склонность человека к нестандартному мышлению, а вовсе не показатель некоей эксцентричности руководства компании, как думают некоторые. Это специфика инновационной отрасли в рамках жесткой конкурентной среды, секрет выживания в которой – в перманентном поиске нового, лучшего и еще более эффективного.

Чтобы резюмировать, позволю себе процитировать уже упомянутого Лазло Бока:

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

Развитый EI дает преданность своей компании, приносит драйв и кайф от своей работы (которые компания интерпретирует как позитивную фанатичность). Это причины болезни под названием трудоголизм. Как итог такой фиксации на «великих делах» – искреннее желание преуспеть в карьере в рамках «большой мировой компании».

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

Я постарался подобрать наиболее часто задаваемые вопросы. Не знаю почему, но вопрос Google с блендером стал уже знаменитым из-за его распространенности.

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

• Вот вам бумага и ручка, разработайте подробный план эвакуации Сан-Франциско.

• Сколько примерно воды в океанах?

• Предложите принципиальную конструкцию часов для слепых.

• Сколько мячиков для гольфа может поместиться в стандартном детском автобусе?

• Оцените примерное количество настройщиков пианино во всем мире.

А теперь самые ходовые вопросы, построенные на смеси темы-специализации и некоего дополнительного неожиданного условия (вот распространенные примеры на тему программирования и не только):

• Очень сложно удержать в голове что-то, о чем вы читали много лет назад. Как вы боретесь с этим? Какая у вас система систематизации знаний?

• Какое самое красивое решение из всех, что вы видели? (Вариант: самый красивый фрагмент кода и т. д.). Давайте обсудим то, что вас поразило в нем больше всего.

• Представьте себе страну, где очень почетно иметь мальчика в семье. Поэтому родители рожают детей ровно до тех пор, пока не родится первый мальчик. Каково гендерное соотношение детей в такой стране?

• Объясните вашу методику тестирования для элеватора (распространенные варианты: для карандаша, полосы прокрутки (scroll bar) и т. д.).

• Используя пару из трехминутных и семиминутных песочных часов, нужно отмерить интервал точно в 9 минут, расскажите как это сделать. (В моем случае был похожий вопрос, который мне запомнился: есть готовая функция, генерирующая случайные числа в диапазоне от 1 до 5, требуется написать, используя лишь ее, новый генератор для диапазона 1–7).

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

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

Очень многие заметили специфику интервью в Google: почти на каждое сильное утверждение с вашей стороны ведущий наверняка потребует объяснений (можно также назвать это словом «обоснование»). Это особенно касается сферы собственных вкусов при выборе инструментов и технологий. Если, скажем, вы заявляете, что программируете только на PHP (или только на любом другом языке) и вообще любите этот язык до глубины души, сразу приготовьтесь к тому, что с вас потребуют аргументации.

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

Для наглядности приведу более конкретный пример подобного диалога из опыта собственного собеседования. Когда я рассказывал в Google про свои навыки и упомянул принципы SOLID, которые хорошо знаю и активно применяю, тут же получил встречный вопрос: «Почему именно SOLID, а не почти аналогичный GRASP? Каковы аргументы выбора в пользу SOLID?»

Это, конечно, интересный вопрос, потому что все, что касается наших спонтанных предпочтений, не всегда поддается ясному и четкому объяснению и вербализации, тем более опасно, когда подобные провокационные вопросы подкидывают вам неожиданно и в исключительно ответственный момент. Второй личный момент, за который меня основательно зацепили: «В вашем резюме написано, что вы большой любитель FreeBSD, давайте обсудим этот вопрос, почему именно FreeBSD, а, скажем, не Ubuntu?» Подобно тому, как в боксе часто используется клинч в качестве уловки, чтобы выиграть время, если участник состязания не держит удар, в подобных «аварийных ситуациях» также возникает соблазн отмахнуться голословным, поверхностным, односложным или просто банальным ответом с улыбкой, жаждущей снисхождения (применительно к предыдущему вопросу – репликой на уровне «FreeBSD мне нравится просто потому, что в ней есть система портов»).

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

Сначала были достаточно глобальные и обзорные вопросы с легким оттенком провокационности, например[13]:

• Почему вы выбрали язык, реализация которого не поддерживает многопоточность?

• Почему в мире PHP нет событийно-ориентированных фреймворков?

• До какой степени PHP 5 действительно поддерживает ООП?

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

• Что значит «Variable variables» в мире PHP?

• Знаете ли вы иврит? Что значат периодические сообщения PHP об ошибке T_PAAMAYIM_NEKUDOTAYIM?

• Расскажите нам побольше про PHP, например про переменные и функции, которые здесь могут существовать в двух отдельных пространствах имен. Если я правильно понимаю, вы можете использовать как функцию fix(), так и переменную $fix. Пожалуйста, поясните, в чем преимущества такого подхода PHP?

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

• Поддерживает ли PHP стандартный тип integers, больший, чем 32 бита? Есть ли в PHP тип unsigned integers?

• Как в PHP можно получить «тело» http-запроса, отличного от типа POST? Например, сделайте это нативными для PHP средствами для запросов, выполненных методом PUT.

• Поддерживает ли PHP методику duck typing? (Кстати говоря, наверное, в связи с популярностью Python в Google я заметил повышенное внимание к вопросам, связанным с латентной типизацией, я получил несколько вопросов от разных людей именно на эту тему.)

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

<?php

$result = mysql_query("select * from test_table");

echo "<p><ol>";

while ($row=mysql_fetch_assoc($test_result))

echo "<li>{$row[test_row]}</li>";

echo "</ol></p>";

?>

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

Никто на вас не давит и не язвит над вашими персональными вкусами, отношение всегда уважительное и терпеливое (я не заметил, чтобы хоть раз кто-то перебил или остановил мои объяснения, даже когда я явно отклонялся от темы). Здесь важно просто уметь отстаивать свою точку зрения и самому не делать взаимоисключающих утверждений. Иначе говоря, никто не против того, чтобы программировать именно на PHP, важно просто суметь объяснить, что это ваша сознательная позиция, что так делать действительно лучше и эффективнее. Ваш сознательный выбор и аргументированные предпочтения даже в мелочах, таким образом, подчеркивают ваш профессионализм и выдают опыт.

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

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

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

Двигаясь по темам в резюме, которыми я занимался, мы довольно монотонно и поверхностно прошли по ООП и различным паттернам программирования, пока не дошли до моего любимого аспектно-ориентированного программирования (АОП). Здесь сразу стало очевидно, что настрой ведущего и его коллег поменялся, он попросил рассказывать все максимально подробно, потому что «это интересная тема». Отвечая на многочисленные встречные вопросы насчет причин моего интереса к функциональному программированию, АОП и событийно-ориентированному программированию (СОП), нас постепенно вынесло на другую логичную тему – недостатки методологии объектно-ориентированного программирования как таковой, которая в наше время стала своего рода безальтернативным мейнстримом в индустрии программной разработки.

Я прошелся по калейдоскопу из мнений ряда крупных фигур в мире программирования, в частности перечислил аргументы хорошо известных ярых противников ООП: Дейкстры, Ричарда Столлмана и Никлауса Вирта, по памяти процитировал причины разочарования в объектах Степанова (создателя STL) и общей проблематике рефакторинга как неизбежного диалектического следствия любой разработки, центрированной на ООП-стиле. Также рассказал про интересную критику ООП от Джоэля Спольского, о его похождениях в Microsoft и тамошних «архитектурных астронавтах», замучивших навязыванием этой методологии другим.

Просто в качестве любопытного наблюдения: тема «порочных практик» Microsoft вызвала дополнительное оживление у гуглеров, и мы остановились на этом отдельно. В ходе обсуждения я поделился мнением своего хорошего знакомого о том, как своеобразно соблюдаются «coding guidelines» в Microsoft, где некоторые методы могут содержать тело из кода в сотню экранов, а сам файл с их исходником – весить больше мегабайта.

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

Как я уже отмечал и как признался один известный актер: «Самая лучшая импровизация – это заранее подготовленная импровизация». Отнеситесь к этому банальному утверждению серьезно, и вы сможете удивить в хорошем смысле не только своего потенциального работодателя, но и самого себя, относительно легко создав нужную и контролируемую атмосферу на важном для вас собеседовании.

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

Как правило, в качестве интервьюеров от Google выступают молодые люди. Если 3 года назад это были сотрудники в возрасте около 30–37 лет, то сейчас планка опустилась ниже – сейчас интервью часто ведут парни в возрасте 26–30 лет. Google, безусловно, стремительно молодеет.

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

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

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

Почти всегда встречаются минимальные 1–3 вопроса на смекалку и креативность – иногда не имеющие отношения к профессиональной специализации, но чаще всего завуалированные под них. Легенды о большом количестве подобных вопросов, мягко говоря, преувеличены.

Google стремится уходить от стандартной модели опросов, где есть очевидный и стандартный ответ, тяготея к модели, где требуется самостоятельно найти решение нестандартной задачи в режиме реального времени. Часто при этом просят проговаривать вслух динамику поиска вами решения (общий ход мысли), и поскольку большинство программистов – все-таки выраженные интроверты, это может серьезно помешать сосредоточиться на действительном решении самой задачи.

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

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

Вот для примера: у нас были три сильных программиста, которые набрали максимальное количество баллов по нашей системе тестирования, и я даже пошутил: «Что вам от нас надо, парни?»

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

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

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

Это нормальная ситуация. Если у них есть сомнения или колебания, они будут продолжать зондировать вас до тех пор, пока не будут уверены в своем решении, либо скорее откажут вам сразу. Это известное правило для Google – при малейших сомнениях лучше ошибиться и не взять настоящего профессионала, чем ошибиться и нанять «неправильного человека». Обратная найму процедура увольнения – сложный и долгий процесс, поэтому здесь реализован избыточный подход отбора с некоторым элементом перестраховки.

В отношении приведенного вами примера со Стивом Егги – если речь идет о некоей ключевой позиции и дорогом VIP-кандидате под нее, о котором складывается противоречивое мнение, процедура найма может быть действительно очень жесткой и долговременной.

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

Давайте перечислим типичные вопросы, которые обычно задаются по каждому крупному проекту, в котором вы участвовали (отметили в своем резюме):

• Чему вы научились, работая над ним? (Центральный вопрос, очень популярен.)

• Что было наиболее интересным для вас? (Другой вариант: работа над чем доставляла вам наибольшее удовольствие?)

• Что было наиболее сложным? Чему вы научились на этом примере? Какие уроки усвоили?

• Какая ошибка (баг) вам больше всего запомнилась в этом проекте? (Варианты: решение, ситуация, история и т. д.)

• В чем заключалась ваша стратегия поведения при возникновении личностных конфликтов в коллективе?

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

Например, вот типичные неудачные ответы на предложение назвать свои самые слабые места: «Я перфекционист», «Я трудоголик» и т. д. Все это дежурные и уклончивые ответы, не несущие вообще никакой смысловой нагрузки (cop out answers), такие ответы – яркая демонстрация неспособности говорить по существу. На подобные косвенные вопросы, по которым и оценивается ваша личность, всегда важно отвечать максимально честно и прямо, например: «я часто отвлекаюсь на работе», «у меня не хватает самоконтроля, чтобы выполнять все в срок» и т. д.

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

Для иллюстрации последнего не удержусь и процитирую одного из менеджеров Амазона, который ясно формулирует эту идею другими словами:

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

Лично я считаю, что для подобного типа поведенческих вопросов идеально подходит шаблон SAR (Situation, Action, Response). Например, когда у вас спрашивают: «Что было самым сложным в вашем последнем проекте?», вы, следуя SAR, сначала описываете возникшую проблемную ситуацию, затем раскрываете суть вашего решения и в заключение описываете конечный результат всех предпринятых вами действий. Иногда в особенно сложных случаях уместно расширить вариант ответа до шаблонов STAR (Situation, Task, Action, Response) или SOARA (Situation, Objective, Action, Results, Aftermath). Это требует предварительных навыков и тренировок, но как результат вы научитесь говорить последовательно, ясно и убедительно.

Среди ИT-рекрутеров хорошо известен парадокс, часто называемый парадоксом питона (The Python Paradox). Давайте попробуем спроецировать его на ситуацию с программистами, чтобы нагляднее ответить на этот вопрос. Для этого условно выделим в реальной жизни две полярно мотивированные группы программистов.

Первая категория – это те, кто учится, чтобы получить в итоге хорошо оплачиваемую и престижную работу, и для этого они автоматически выбирают мейнстрим в своей отрасли, ибо это значительно повышает их шансы на выгодное трудоустройство. Вторая группа – те, кто рассматривает свою работу не с позиции материальной выгоды, но с точки зрения самовыражения или чистого творчества, при этом не боится учиться новому или проводить смелые эксперименты в поисках своего идеала, будучи полностью сосредоточенными на своей текущей задаче. В последнем случае парни полностью отвязаны от жесткой рыночной конъюнктуры, тогда как в первом зациклены на потенциальном вознаграждении. Поэтому в итоге вторые выбирают свои рабочие инструменты/методики по критерию «самое лучшее», что зачастую далеко не «самое выгодное или популярное», как это делают их коллеги-карьеристы из первой категории (универсалы-приспособленцы).

Итак, парадокс питона гласит, что, учитывая описанную логику и делая ставку на вторую категорию специалистов «не от мира сего», компания получает в свое распоряжение гораздо более качественный и перспективный кадровый состав, более того, уже есть многочисленные практические доказательства и самые неожиданные экспериментальные подтверждения этого. Безусловно, Google лелеет этот принцип при найме специалистов – ранее я уже упоминал, как резко заинтересовались мною интервьюеры, когда я стал рассказывать о своих наработках в функциональном (Haskell и Yesod) и аспектно-ориентированном программировании, а также когда провел разбор проблематики и мифологии объектно-ориентированного программирования.

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

В качестве наглядного примера: если изучить один из недавних западных бестселлеров на эту тему – книгу Вильяма Паундстоуна (William Poundstone) Are You Smart Enough to Work at Google? Trick Questions, Zen-like Riddles, Insanely Difficult Puzzles, and Other Devious Interviewing Techniques, – может сложиться впечатление, что интервью в Google полностью состоят из шокирующих головоломок, крайне нестандартных и запутанных заданий. Чтобы сразу пояснить, о чем идет речь, приведу типичный образчик оттуда, который, по мнению автора упомянутой книги, один из самых популярных вопросов на собеседовании Google:

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

Кроме того, опираясь на собственный опыт работы в Google, могу выдать инсайдерскую информацию из первых рук – эта практика была явным образом запрещена на уровне Google Hiring Committee примерно с 2005–2006 годов, когда стали активно бороться с подобными модными в то время «фейерверками креативности» со стороны рекрутеров на местах.

Итак, давайте начнем разбираться с самого начала – кто берет интервью? У технического подразделения Google engineering даже сейчас нет вообще ни одного рядового менеджера по найму! Но эта большая работа вполне успешно выполняется. Как же так?

Ответствен за это так называемый технический рекрутер (должность может звучать, например, так: Sr. Technical Recruiter). В подавляющем большинстве случаев он же работает в компании на штатной технической должности, например SRE. По последней причине таких рекрутеров часто именуют инженерами – верны оба определения, не следует здесь путаться. Подобное совмещение повально используется в Google, позволяя проводить по-настоящему глубокие и качественные технические собеседования. Такой инженер, согласившийся на подобную дополнительную работу, проходит специальные внутренние курсы, после чего начинает получать назначения на интервью (тесно связанные с его специализацией и направлением, которое он ведет по основной должности). Это обычно 1–2 собеседования в неделю, чтобы не слишком мешать его основной работе.

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

• Юридическая часть – запрещенные вопросы и темы (то, за что потом на Google могут подать в суд и выиграть).

• Shadowing – пассивное присутствие на реальных интервью, проводимых опытными ведущими. После этого проводятся обсуждение и разбор всех приемов, примененных в прошедшем интервью.

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

• Корпоративный стандарт – кого ищет компания? Попытка описать образ «правильного» гуглера-новобранца. И самое главное – по каким косвенным чертам его легко заметить и выделить в общей массе? Тестирование на «гугловость».

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

Каждый такой рекрутер/инженер по результатам своего личного собеседования с кандидатом пишет персональный отзыв по заданному образцу, это примерно 1–2 страницы формата А4. Здесь больше перечисляются конкретные факты («не смог оценить алгоритм такой-то на сложность, даже после серии подсказок решение не было найдено»), любые личные оценки не приветствуются, хотя и встречаются («отличный общительный парень, с которым я был бы не прочь работать в одной команде»). И как кульминация такого «репорта» – выставляет потенциальному кандидату свою комплексную оценку в диапазоне от 1 до 4 баллов. При этом рейтинг складывается из следующих составляющих (для примера я взял близкую мне должность SWE – разработчик ПО):

• аналитические способности (analytical abilities);

• навыки программирования (coding & design skills);

• опыт работы (professional experience);

• общение (communications skills).

По каждому из этих пунктов выставляется максимум 1 балл (могут ставиться дробные оценки меньше единицы, например 0,5), после чего оценка суммируется (очевидно, теоретический максимум – 4 балла).

Эта оценка как конечный результат прохождения собеседования должна сохраняться в тайне как от других интервьюеров, так и от самого участника интервью. После чего она представляется на специальном бланке в комиссию по найму (Google Hiring Committee). У этой комиссии есть множество подкомиссий, каждая из которых специализируется на отдельной специальности (например, для администраторов это Site Reliability hiring committee). В нее централизованно стекаются все данные со всех собеседований множества отдельных рекрутеров низшего звена, затем они распределяются по соответствующим подкомиссиям.

(Улыбаясь.) Там примерно одно и то же, поверьте мне на слово. В последнее время такие отчеты чаще всего предоставляются по электронной почте, а затем хранятся для последующего контроля и повторных интервью.

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

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

Это второй (после самих собеседований) уровень анализа результатов собеседований (так называемая стадия 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) – исключительно по памяти.

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

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

Подобный режим – это когнитивный диссонанс по отношению к стандартному и неспешному офисному программированию, где мы обычно тщательно продумываем и оптимизируем каждый элемент своего решения в тиши кабинета, пребывая в спокойном сосредоточении тет-а-тет с кодом, так любезно подсвеченным в любимой IDE. Также обращаю внимание: как утверждает статистика, при подобном «спортивном программировании» наиболее распространенный тип ошибки – off-by-one error (OBOE).[14]

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

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

Второй аспект частых ошибок – лингвистический.

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

Например, как правильно произносится слово «procedure»? Обратите внимание на правильность ударения. Очень часто обсуждается тема сложности алгоритма, его асимптотическая оценка и нотация «большое-О», в связи с этим как бы вы произнесли вслух формулу O(log(n))?

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

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

Это еще один распространенный паттерн собеседования. Я называю его «составной допрос» (это когда некий теоретический вводный вопрос красиво компонуется с продолжением – практической задачей на его основе). Например, начав обсуждать теорию «Big O notation», после плавно съезжают к обсуждению алгоритма TLS Handshake, который имеет, мягко говоря, много предварительных вычислений. Для интервьюера этот прием – хорошая возможность оценить, насколько у вас большой зазор в понимании между сухой академической теорией и конкретными реализациями на ее основе. Большая проблема и одновременно узкое место нашего современного образования – то, что эти две важные составляющие подчас никак не связаны между собой.

Нужно хорошо знать хеши, устройство деревьев и графов, главные алгоритмы поиска и сортировок, стандартные структуры данных, основы математики (особенно системы счислений, теорию чисел, основы теории вероятностей и комбинаторику). Кроме того, спецификации основных сетевых протоколов и RFC, работу процессора и памяти, детали TCP/IP и все уровни модели OSI.

Для программистов дополнительно – принципы ООП и основные паттерны, теорию работы компиляторов, а также базовые вещи. Пример последнего – очень частый вопрос о расчете времени и эффективности выполнения (Big O notation). Для администраторов – основные API-вызовы операционных систем, то есть вызовы типа fork(), иметь хорошее практическое знание Perl. Кроме того, нужно иметь хотя бы один любимый язык, которым вы владеете очень сильно, вместо десяти языков, на которых решили пару стандартных задач в свободное от работы время (и на основании этого самодовольно поставили птичку в своем резюме напротив их наименований).

Как бы ни страшно звучало все перечисленное, требуется знать лишь основы, но знать их нужно уверенно[15]. Также я хочу коснуться важного момента: требуется понимать то, что было прочитано в различных книгах и интернет-источниках, а не просто механически повторять ранее выученное. К примеру, вот проверочный вопрос из реальной практики собеседований на тему паттернов программирования, который поставил в тупик моего подопечного.

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

Приведу еще три вопроса-примера в этом же стиле для самоконтроля.

struct foo {

char a;

char* b;

};

#include <cstdlib>

#include <iostream>

using namespace std;

int main (int argc, char** argv){

cout<<argv[argc-1]<<endl

<<argc[argv-1]<<endl;

return EXIT_SUCCESS;

}

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

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

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

Как правило, ведущие рекомендуют самим участникам заранее выбрать наиболее комфортный для себя язык программирования для прохождения всех заданий интервью. Но, конечно, экзотика при этом не всегда приемлема, ведь проводящий интервью также должен владеть этим языком. Здесь нужно иметь в виду, что в самой компании Google основными (стандартными для большинства проектов) являются языки C++/С#, Java и Python – в своем выборе лучше отталкиваться именно от них. И еще: интервью не место для импровизаций, постарайтесь выбрать действительно наиболее знакомый для себя язык программирования. Поверьте мне на слово, это очень важно, даже если он не входит в эту тройку.

Этот выбор субъективен для каждого. Я бы, наоборот, сделал ставку на С++. Да, он сложнее чем Python, но дает большее понимание того, что именно делает компьютер, когда исполняет твой код. К примеру, за время собеседований я видел много молодых программистов, которые не понимали, как работают указатели, ну а указатель на указатель для таких ребят был просто какой-то трещиной в их вселенной. Потому я считаю, что подобные вещи, характерные именно для С++, стоит разобрать как можно раньше в своей карьере. Как минимум советую сделать это до интервью в Google. (Смеется.)

Поймите меня правильно, мне очень нравится Python, но современный программист просто обязан знать несколько мейнстримовых языков. Поэтому считаю, что в вашем случае переход в изучении основного для себя языка в последовательности Python → C\C++\Java\C# станет для новичка настоящим адом, в то время как естественный апгрейд уровня абстракции C\C++ → Java\C#\Python\Perl будет вызывать приятное чувство типа «о, как тут все просто и понятно». Иными словами, десертом полезней заедать, предварительно отведав первое и второе, а не наоборот (хотя дети будут против такой последовательности и с ними придется долго спорить!).

Есть много способов, например, я уже говорил об институте рефералов. Хороший и неравнодушный к вам реферал – очень важное подспорье. Но не будем повторяться, поэтому предлагаю умышленно расширять базу своей компетенции. Что это значит? Очень часто, когда человек показал средние результаты интервью и в чем-то недотягивает на свою первоначальную позицию, но его потенциал всем очевиден, ему могут предложить альтернативные позиции, перенаправив его заявку к другому рекрутеру (с согласия кандидата).

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

Каждому решать самому, как по мне – стоит.

Нужно иметь в виду, что в Google можно поменять проект по своему желанию, причем сделать это крайне радикально, к примеру вместо С++ начать вдруг писать на HTML/JS/CSS. Далее, можно из программиста переделаться в HR или продуктового менеджера (что многие и делают после достижения болезненного для немалого числа программистов возрастного порога в 35–40 лет). Можно переехать в другой офис и страну, подав заявку на подходящие вакансии у соседей, – нет проблем. Вариантов очень много, если речь идет о таком международном гиганте, как Google. Кстати, там существует собственная внутренняя сеть Moma, в которой находятся сведения по всем проектам, их требованиям и вакансиям. Также в ней хранятся цели и задачи каждого сотрудника компании по отдельности, подкрепляющиеся их отчетами и прочей справочной информацией как о людях, так и о проектах. Выбирать новые позиции легко и приятно.

Главное – попасть внутрь, после чего все возможности для маневра открыты. Ради этого многие используют гораздо более сложные схемы, чем описанная мною двухходовка.

Например, устраиваются в фирмы типа Infosys – это большая фирма-«бодишопер», завозящая на американский рынок вагоны дешевых сотрудников по H1B, которые затем работают на рабских условиях (например, по контрактам на внутренний аутсорс, которые заключает Infosys). Из уже изначально невысокой зарплаты Infosys будет забирать еще и свою долю. Хитрость такого «заезда» в том, что потом можно сделать трансфер H1B-визы в другую компанию (это достаточно простая процедура). Очень многие из подобных беглецов изначально метят именно в Google, для которой претендент в качестве президента США имеет гораздо больше проходных шансов на трудоустройство, чем бедолага, живущий за тридевять земель. В таком подходе есть множество других плюсов, которые я не буду перечислять здесь.

Говоря кратко, это большая проблема. Для многих виза становится даже большей проблемой, чем само трудоустройство в Google, если речь идет о США. Но давайте попробуем последовательно разобраться, что там к чему.

На данный момент[16] ситуация такова, что даже наличие оффера и острое желание могущественной компании типа Google взять вас к себе на борт не гарантирует получение рабочей визы. H1B – это сложный вариант, как ни крути. Сейчас на этот тип визы существует квота в 65 000 человек в год, а количество желающих ее получить растет с непропорционально большой скоростью. По сути, вам придется участвовать в лотерее за место в квоте. Например, в 2013 году было подано 120 000 заявок, а в текущем году – уже 170 000. Соответственно, шанс «выиграть визу» в 2013-м был равен 50 %, а в 2014-м – 33 %. Если в этой динамике ничего не изменится, то в 2015 году этот шанс будет составлять 20 %.

Весь топ компаний, получающих H1B-визы, создающих это столпотворение и давку, занимают индийские «бодишоперы». Общий вал заявок формируется преимущественно ими. Крупные работодатели, такие как Google, Facebook и Microsoft, очень недовольны данной ситуацией и пытаются лоббировать закон, который поднимет размер квоты для рабочих виз. Правительство США согласно с ними, Обама уже два года обещает провести так называемую иммиграционную реформу, но пока безуспешно. Есть мнение, что до следующих выборов ничего не изменится. На данный момент новые правила H1B – пока открытый вопрос.

Впрочем, большие компании, в том числе Google, решают этот больной вопрос с помощью следующего маневра – те, кто не получил визу (большинство), отправляются в их офисы в Канаде или Европе. Там они работают год, а потом приезжают в Штаты по визе L1. Вид на жительство можно делать и с L1, так что тут все нормально. Единственное «но» – с H1B работу поменять можно, а с L1 – нельзя. Но есть и обратная сторона – супруг(а) держателя визы L1 может работать наравне с ним, а супруг(а) держателя H1B – нет.

Следующий этап после попадания в Google для «нуглера»[17] – закрепиться в стране. Нужно сразу подаваться на гринкард (GC), что Google делает достаточно эффективно[18]. По моим оценкам, шанс получить GC при желании и настойчивости (требуются периодический контроль и напоминания юристам, обычно заваленным работой, в которой вы можете просто потеряться) стремится к 90 %. Если фирма не спешит, если весь процесс пустить на самотек, то реально получить ВНЖ примерно за 3 года. Если активно контролировать этот процесс, можно успеть сделать все за 2 года.

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

Что касается сравнения, то я работал в цюрихском отделении Google, равно как и в американских отделениях. Если просуммировать свои субъективные впечатления, то в Калифорнии режим работы намного насыщеннее, чем в том же Цюрихе. Трудоголический менталитет американцев, центральные большие проекты, большое количество местных звезд программирования, на которых можно равняться, а также высокая концентрация выпускников лучших ИT-университетов мира – все это создает определенный климат в американской части Google. По моим ощущениям, Америка дает намного больше (знаний, денег и навыков), но и больше отбирает (времени и сил).

В Кремниевой долине царит дух непрерывной работы, в частности офисы Google открыты круглосуточно. Как говорил мой тамошний босс, если вы приходите на работу в 8:00, а уходите в 17:00 – вы не работник HighTech-компании. Можно сказать, что американская часть Google подходит более молодым и амбициозным. В Европе нет такого рвения и напряженности, проекты более простые и монотонные, а жизнь в целом более зарегулированная в пользу обывателя (благодаря тамошним жестким национальным законодательствам). Также я слышал, что европейские отделения Google ценят многие выходцы из Восточной Европы и России, которым оттуда до родных краев лету всего 2–4 часа.

Больше, но ненамного. Например, в некоторых других ИT-компаниях возможно резкое увеличение зарплаты сразу на 50 %, быстрый карьерный рост, если вы показываете неординарные результаты. В Google такого бешеного темпа роста зарплат и стремительного продвижения по карьерной лестнице ожидать не стоит. Единомоментное увеличение зарплаты на 10 % здесь считается приличным. Плюсы – у Google есть развитая система бонусов для успешных работников, отличный соцпакет. Несмотря на то что в компании нет жесткого графика работы, есть нормы часов, установленные бессрочным трудовым контрактом. Сверхурочные часы компания не оплачивает. Для Google важно не то, сколько времени вы провели на работе, а каких конечных результатов добились.

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

Желающим в первую очередь хорошо зарабатывать я бы хотел повторить давно очевидную вещь: общая зависимость зарплаты рядового сотрудника от стажа работы в компании весьма слаба. Максимальный доход в долгосрочной перспективе получают вовсе не лояльные сотрудники, но совсем наоборот – те, кто часто меняет работу. Частая смена мест работы в постоянном поиске прибавок и более выигрышных позиций (так называемый сайдшифтинг) – самая выигрышная стратегия, если деньги для вас главное. ИT-компаний в США море, таким образом, методом настойчивого перебора можно найти тех, кто даст столько, сколько надо (нужно учитывать, что многим компаниям нужны специфические скиллы, за которые они готовы платить «top dollar»).

Итак, сначала идут фильтрация и отбор анкет кандидатов (Recruiter Screen), затем в случае успеха назначается серия телефонных интервью (Phone Screen), возможно, с участием технического специалиста. Если вы проходите и этот предварительный этап, вас приглашают на очное интервью в офис компании (On site interview), полностью оплачивая и организуя ваш визит-путешествие. Как правило, само интервью – это затяжной марафон продолжительностью в день, когда вас интервьюирует последовательно от трех до восьми человек (как правило, технические специалисты), причем каждый задает свой список вопросов и задач. Затем каждый гуглер пишет свой персональный отчет по стандартной форме, в конце которого присваивает вам определенный рейтинг (Interview Feedback).

Все эти отчеты постепенно стекаются в комитет по найму (Hiring Committee), где после завершения сбора отзывов на кандидата еще раз суммируются и коллективно обсуждаются рекрутерами комитета (Executive Review). Если вердикт в вашу пользу, готовится заключение от Compensation Committee, где озвучиваются конкретные цифры зарплаты, которые могут быть вам предложены, исходя из ваших результатов и бэкграунда. После этого цикла согласований каждый утвержденный снизу оффер попадает на стол высокопоставленному HR-сотруднику Google, который выносит окончательный вердикт на ваш счет (Final Executive Review), еще раз внимательно просматривая всю историю отзывов о вас и взвешивая значимость аргументов «за». Обычно около 70–80 % предложенных кандидатур утверждаются.

На данные три уровня принятия решения уходит довольно много времени, поэтому нужно запастись терпением. В заключение ваш первоначальный рекрутер связывается с вами и сообщает, что вы «не можете быть частью этой команды», либо делает предложение о работе (Job Offer), перечисляя все детали и условия работы в компании, чтобы вы могли принять окончательное решение.

Напоминаю, что двумя ключевыми условиями успешного прохождения интервью являются ваша профессиональная подготовка (достаточно среднего алгоритмического уровня и хорошего умения кодировать) и опыт правильного поведения на интервью (дается оценка комфортности общения с кандидатом и его соответствие стандартам инновационной компании – «гугловость»).

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

Реалистично оценивая шансы и правильно расставляя балансы, следует, конечно, отталкиваться от статистики. Уже упомянутый мною ранее HR-босс Google Бок недавно привел интересные свежие цифры. По его словам, в последний год они получили чуть больше 3 миллионов резюме. Из них были реально наняты 7000 сотрудников (тот же год). То есть величина найма составляет примерно 0,2 %, что означает конкурс приблизительно 428,5 человека на место. Для сравнения: это намного больше, чем в Гарварде или Стэнфорде.

С другой стороны, глядя на все с обывательской точки зрения и ежемесячно готовя людей для подобных собеседований, я вижу, что работает принцип «кому очень надо, тот рано или поздно устроится». Мне эта статистика не кажется удручающей, потому что я вижу, что мои знакомые туда как-то устроились (а некоторые успели даже уволиться, найдя место получше или разочаровавшись), я также сам прошел этот путь и не вижу в нем ничего сверхъестественного. К тому же, если глянуть на темпы найма, то хорошо виден разгон – с каждым годом Google нанимает все больше людей, разгоняясь при этом довольно динамично. Дефицит специалистов на рынке очевиден каждому, значительная часть из этих присланных 3 миллионов анкет – это пустышки или анкеты откровенных новичков, склонных к авантюризму.

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

Честно говоря, считаю все, что я посоветовал в этом ответе, отчасти бессмысленным (загадочно улыбается).

На самом деле люди, с которыми я работаю, делятся на две противоположные категории. Самооценка одних останавливает и всячески тормозит их, в конечном счете они не сделают даже, как им кажется, одной жалкой попытки (вне зависимости от их объективного уровня подготовки). Другие, что бы я ни бухтел здесь о шансах в 0,2 %, рассуждают про себя примерно так: «О’кей, настало время поразмять мозги, покажу-ка я этим засранцам из Google, как это делается» (опять же, вне зависимости от их реальных способностей). Чаще всего именно эта последняя категория (на пару с госпожой удачей) все и решает. Все остальные просто трезво оценивают свои шансы.

(Перебивает.) Хотите совет не только по Google?

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

(Присаживается и продолжает серьезно.)На самом деле в любом проекте имеет смысл оценивать лишь проходные минимумы. У вас есть английский, у вас есть какой-то опыт, вы уверенно пишете код? – тогда нужно действовать, по возможности не спотыкаясь о свои же дурные мысли. Мяч круглый, игра длится 45 минут – это факты, все остальное – только ваши домыслы и ожидания.

Трудитесь, развивайтесь, верьте в себя. Область видимости локальных переменных в вашей жизни ограниченна, вы не можете принять правильное решение в принципе. Поэтому расслабьтесь, у инкапсуляции есть свои плюсы. Лучше сделайте свою часть работы на максимуме, а дальше, как советует инсталлятор Windows, «откиньтесь на спинку кресла и дождитесь результата».

Вот лишь несколько случайно отобранных вопросов.

• Что лучше использовать при реализации хэш-таблиц: дихотомии или сортировки?

• Почему для сортировки маленьких объемов данных используют алгоритм сортировки вставкой?

• Почему алгоритм сортировки слиянием быстрее других видов сортировки для больших объемов данных?

• Когда и где выгодно использовать связанный список, а когда – обычный динамический массив?

• Пожалуйста, проведите оценочный подсчет примерного количества переключений контекста процессов (context-switch) в течение одной секунды в современной ОС, работающей на процессоре с частотой 2 ГГц.

• В чем принципиальное отличие реализации Сuckoo hashing от стандартных хэш-таблиц?

• Что такое «Cache Hit Rate»?

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

Очень много заданий построить максимально удобную и продуманную структуру данных (либо структуру классов) к какой-то конкретной задаче/ситуации.

Много качественных вопросов (заданий) можно найти в секции «Алгоритмы» известного программистского сайта TopCoder. Все участники этого сайта, имеющие рейтинг «красного цвета», буквально завалены в своих инбоксах предложениями о работе от ведущих ИT-компаний мира.

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