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

Вступление

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

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

Подготовка

Алгоритмы

Я начал с того, что сразу пошел решать leetcode, но быстро понял, что моих знаний хватит только на задачи уровня Easy. Поэтому сначала решил пройти вот этот курс. Он довольно короткий, но после него решение литкода пошло гораздо увереннее.

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

Понимание условий

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

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

• Вы уже видели похожую задачу ранее и автоматически предположили, что от вас хотят тоже самое

• Вам дали пример тест‑кейса, и вы сделали выводы о входных данных на его основе

Любые предположения нужно проговаривать вслух. Обязательно нужно уточнить, могут ли входные параметры быть null, инвалидными, пустыми матрицами, отрицательными или дробными числами.

На сколько я знаю, количество историй, когда собеседуемый неправильно понял условие, сильно отличается от нуля. Полезный прием — сразу составить свой тест‑кейс для задачи и обсудить с интервьюером, какое решение для этого тест‑кейса правильное. Это добавит уверенности в том, что вы все правильно поняли.

Подготовка к решению

После того как с условиями разобрались, переходим к решению. Не стоит сразу писать код. Для начала необходимо убедиться, что интервьюер на 100% понимает, что именно вы будете программировать.

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

Важно проговорить все решения, которые вы можете предложить. Даже если какое‑то из них объективно хуже, его стоит как минимум упомянуть и объяснить почему оно хуже других. Также стоит быть готовым, что вас могут попросить написать не то решение, которое вы сами хотите. Например, скажут, что хотят увидеть как будет выглядеть имплементация решения с использованием поиска в глубину, а не в ширину.

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

Написание кода

После того как вы приступите к написанию своего решения, я бы посоветовал обратить внимание на два момента:

Постарайтесь проговаривать все, что вы пишете. Объявляете переменную — объясните, зачем она нужна. Написали if — объясните, как работает условие. В идеале, интервьюер в каждый момент времени должен понимать, что именно вы делаете. При подготовке к собеседованиям я записывал на видео некоторые решения моих задач и потом слушал со стороны, как я их объясняю. С точки зрения постановки речи и умения излагать свои мысли это было одним из самых полезных упражнений.

Второй момент — следите за качеством кода. Он должен быть максимально приближен к коду в реальных проектах. Не стоит объявлять переменные из одной буквы, делать множественные вложенные if'ы, дублирование и прочие вещи. На литкоде можно часто встретить решения написанные как попало. На реальном собеседовании это оценивают, поэтому стоит уделить этому отдельное внимание.

Проверка решения

Когда код написан, вам нужно будет придумать 1–2 тест кейса и проверить на них свое решение. Для проверки вам нужно будет идти строчка по строчке в своем коде и объяснять интервьюеру, что именно будет происходить в коде.

Когда я готовился к собеседованиям, я пренебрегал этим этапом. Я писал код и сразу нажимал кнопку Submit на литкоде с надеждой на лучшее. После неудачного собеседования в Revolut, я серьезно начал учиться писать тескейсы. На каждой задаче у меня был челедж отправить правильно работающий код с минимального количества попыток.

Также стоит помнить, что на задачи очень строгие тайминги. Easy & Medium — 20 минут, hard — 40 минут (приблизительно). Умение в них укладываться — важный скил, который тоже стоит практиковать.

System design

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

Что я использовал для подготовки

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

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

Если у вас много времени на подготовку, то стоит обратить внимание на Designing Data‑Intensive Applications. С одной стороны, материал там гораздо глубже, чем вам потребуется на собеседовании. Тем не менее, одна из лучших книг, что мне попадались, и хуже от ее прочтения точно не будет.

Как проходит собеседование

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

• Можно ли ставить лайки?

• Нужно ли генерировать ленту, если да, то как?

• Можно ли постить видео

• …

Далее нужно разобраться с нефункциональными требованиями:

• Сколько пользователей должна поддерживать система

• Пользователи из одного региона, или по всему миру

• Как быстро должен открываться интерфейс, генерироваться лента, и т. д.

• …

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

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

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

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

• На нескольких компонентах (по вашему выбору) рекомендуется сделать «deep dive». Например, если есть SQL база — можно рассказать как будет спроектирована схема и какие будут индексы. Если кафка — как будут сконфигурированы топики/партиции и т. д.

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

После того как вы закончите, вас будут челеджить вопросами по вашему дизайну. Могут указать на какой‑нибудь single point of failure (если такие будут), обратить внимание на потенциальные проблемы с масштабируемостью, или предложить новую фичу для вашей системы, и спросить как именно она впишется в ваш дизайн.

Behaviour

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

Как я готовился

Я взял примеры вопросов на Leadership principles из Амазона, а также смотрел треды на литкоде с обсуждением собеседований. Вариантов, что могут спросить крайне много, но обычно одни и те же истории могут подходить к разным вопросам. Достаточно акцентировать внимание на разных моментах, в зависимости от того, что от вас хотят услышать.

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

Собеседования

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

Несколько советов и наблюдений, которые у меня остались по итогам собеседований

Акценты английского

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

Нет прямой обратной связи

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

Задачи на алгоритмических собеседованиях

Суммарно в двух компаниях у меня было 6 алгоритмических собеседований, и на всех меня спрашивали задачи уровня medium/medium‑hard. Из интересного, только две из них я смог найти на литкоде. Также, я часто видел комментарии вроде «компания X любит спрашивать задачи на тему Y». Моему опыту это не соответствует, и какого‑то паттерна в темах задач я не увидел.

Вопросы на behaviour собеседовании

Большинство вопросов сводились к двум темам:

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

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

Так же, на двух Behaviour собеседованиях меня спросили по алгоритмической задаче (на последние 10–15 минут). Не знаю, почему так, но видимо это стандартная практика и не стоит этому удивляться.

System design собеседования

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

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

Итог

В течение недели после собеседований я получил по офферу от обеих компаний. На этом этапе я, возможно, допустил ошибку и не стал торговаться за лучшие условия. Когда я уже переехал, то от других ребят, проделавших похожий путь узнал, что вполне реально получить себе дополнительные 10–50k $ в виде стоков и sign‑on бонуса, даже если ваша текущая зарплата меньше в условные 3–4 раза.

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

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

В карьерном плане для меня работа здесь это определенно шаг вперед. Самая большая разница, это количество доверия ко мне, как к инженеру. Здесь мне не нужно кому‑то доказывать, что я могу сделать какой‑то проект и я для этого достаточно компетентен. В тоже время, интенсивность работы тут выше и work‑life balance несколько хуже, чем тот, к которому я привык.

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