Просмотров: 3319

Вся правда о собеседованиях в Google: за пределами NDA. Часть 7


7. Важные дополнительные факторы, которые стоит учесть заранее

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

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

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

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

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

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

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

Вся правда о собеседованиях в Google: за пределами NDA работа в Гугл интервью собеседования

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

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

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

Примечание

Off-by-one error (OBOE) — распространенный тип логической ошибки в программировании, который чаще всего сводится к недостаточному тестированию граничных условий (значений) программы или функции.

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

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

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

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

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

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

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

Вся правда о собеседованиях в Google: за пределами NDA работа в Гугл интервью собеседования

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

Покончив с наиболее типичными ошибками, хочется уточнить ещё один паттерн. Я слышал, как вы обсуждали со своими курсантами «составной допрос» — что это значит?

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

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

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

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

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

Как бы не страшно звучало всё вышеперечисленное — требуется знать лишь основы, но знать их нужно уверенно .

Примечание

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

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

Давайте поговорим подробнее об singleton. Является ли singleton паттерном или антипаттерном? Классическая реализация singleton приводит к невозможности использования модульного тестирования, почему вы тогда относите его к паттернам?

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

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

Какой физический размер этой Си-структуры ниже в памяти на 32-битовой системе? На 64-битовой? От чего зависит её размер?
struct foo {
char a;
char* b;
};

Следующий пример — объясните, почему нижеприведенный код работает.

#include
#include
using namespace std;
int main (int argc, char** argv){
cout< < return EXIT_SUCCESS;
}

Третий типичный вопрос на общую сообразительность а-ля Google:

Может ли функция возвращать итоговое значение чаще, чем была вызвана?

Хорошо, предположим, мы прошли все испытания и собеседования, отмерянные нам судьбой, и вот мы в ожидании окончательного вердикта. Я знаю, иногда вместо «апрува» присылают некий «Request for evidence». Что это такое и как это влияет на вероятность одобрения?

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

Вся правда о собеседованиях в Google: за пределами NDA работа в Гугл интервью собеседования

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

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

Кстати, что насчет выбора языков для кодирования в рамках собеседования, как на стадии телефонного интервью, так и на очном собеседовании?

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

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

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

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

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

Иными словами, десертом полезней заедать, предварительно отведав первое и второе, а не наоборот (хотя дети будут против такой последовательности, и с ними придётся долго спорить!).

Какой вы можете дать практичный и доступный всем нашим читателям совет, чтобы повысить свой шанс получить оффер?

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

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

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

Хм, это может привести к тому, что человек попадет на нелюбимую для себя позицию, стоит ли Гугл таких жертв?

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

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

Вся правда о собеседованиях в Google: за пределами NDA работа в Гугл интервью собеседования

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

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

Например, какие?

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

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

~

Читать ещё в этой серии: следующая часть, оглавление.

Ключевые слова для тех, кто работает сугубо на алгоритмах: работа в гугл и как устроиться на работу в Google. Руководство и помощь по поиску работы в ИТ США, а также найм и рекрутинг в ИТ, прохождение там собеседований и интервью, поиск вакансий и работы в США. Какие алгоритмы нужно знать, а также, какие вопросы задают на собеседованиях в западных ИТ-компаниях? Как проходит типичное интервью при поиске работников. Рассказ о своем опыте работы и трудоустройстве в Гугл, впечатления и отзывы о работе в Google, эмиграция в США. Как принимают на работу в американских ИТ-компаниях, как проходит интервью и собеседования. Какие вопросы задают при найме в Гугл, как устроено интервью и отбор людей и сотрудников в компанию. Какие есть вакансии, а также работа в google для любых программистов. Критерии отбора и найма, всё, что нужно знать: как попасть на работу (устроиться) в Гугл?

twitter.com facebook.com vkontakte.ru odnoklassniki.ru mail.ru ya.ru pikabu.ru blogger.com liveinternet.ru livejournal.ru google.com bobrdobr.ru yandex.ru del.icio.us

Подписка на обновления блога → через RSS, на e-mail, через Twitter
Теги: , , , , , , ,
Эта запись опубликована: Среда, 20 апреля 2016 в рубрике МненияИнтервью.

Оставьте комментарий!

Не регистрировать/аноним

Используйте нормальные имена. Ваш комментарий будет опубликован после проверки.

Зарегистрировать/комментатор

Для регистрации укажите свой действующий email и пароль. Связка email-пароль позволяет вам комментировать и редактировать данные в вашем персональном аккаунте, такие как адрес сайта, ник и т.п. (Письмо с активацией придет в ящик, указанный при регистрации)

(обязательно)


⇑ Наверх
⇓ Вниз