Фронтенд-инженер из лондонского Facebook рассказывает, как попасть в FAANG

Как готовиться к собеседованиям, чтобы устроиться в компанию уровня FAANG? Вместе с Олегом Громовым, фронтенд-инженером из лондонского офиса Facebook, составили план подготовки по мотивам вебинара — опираясь на его личный опыт.

Обсуждаем:

FAANG — аббревиатура Facebook, Amazon, Apple, Netflix, Google, название, насколько я знаю, появилось 3–5 лет назад. Это были компании с наибольшей капитализацией в IT. Они — как планка, до которой все пытаются дотянуться: если дорос до FAANG, то выше только звёзды. Многие инженеры хотят туда попасть: большие зарплаты, хорошие условия, возможности для развития — это лучшее, что бывает в мире среди корпораций.

Кто-то включает Microsoft, Uber, Airbnb, кто-то пытается перенести термин на российские крупные tech-компании: Яндекс, Mail.ru, Авито, ABBYY. На мой взгляд, в FAANG они не входят, само понятие — только про перечисленные выше tech-гиганты.

Но есть фаанговский стиль собеседования, и это — другая история. Стиль переняли многие компании, которые на FAANG не похожи ни размером, ни прибыльностью. В собеседование входят4 и больше секций, которые включают: алгоритмическое интервью, system design, behavioral-интервью. Подготовившись к такому собеседованию, вы можете устроиться и в компании помимо FAANG: формат становится знакомым. Предлагаю использовать этот широкий подход, будем говорить о компаниях, которые собеседуют по фаанговской структуре.

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

Минусы зависят от того, какой вы человек и чего вам хочется от жизни. Основной: не стоит устраиваться в FAANG, если вам не нравится быть винтиком в механизме, причём механизме сильно регламентированном.

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

Кому-то это подойдёт: например, молодым людям, которые закончили университет. Они где-то поработали год, попали в это великолепие и наслаждаются процессом и результатом. Но тем, у кого уже лет 15 опыта за плечами — хочется больше ответственности, хочется использовать свой опыт не для маленькой задачки внутри компании. Им в FAANG’е может быть не очень. Это надо иметь в виду и подбирать место для себя и своих сильных сторон: не надеяться, что в Facebook ты автоматически становишься самым счастливым человеком в мире. Это не так.

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

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

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

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

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

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

Всё это подайте в выгодном свете, но не выдумывайте, говорите правду: покажите адекватные достижения, идеально, если количественно — все большие компании это оценят. Например, технические достижения опишите так: время прохода тестов в Continuous Integration-среде сократилось на 30%, увеличилась прибыль или конверсия — тоже на % . Расскажите про командные достижения: где вы помогли наладить процесс, кого и как нанимали.

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

Хороший совет —писать резюме на одной, максимум — 1,5 страницах. Времени у интервьюеров мало, и хорошо, если вся информация считывается ими сразу.Когда резюме должно из общей кучи попасть к человеку, который решает, с кем провести звонок, рекомендация — почти гарантированный путь к успеху.Она выделяет резюме среди других, иначе из нескольких десятков тысяч откликов вас могут просто статистически не заметить. Поэтому если есть знакомые — обращайтесь к ним. Как правило, люди легко реферят резюме: за удачную рекомендацию получают бонусы внутри компании. Рекомендации — это не какая-то запретная тема и не табу. И в Яндекс, и в Facebook, и даже в Toptal я попал через рекомендацию.

После того, как резюме одобрили, перед 4-этапным интервью обычно есть ещё скрининг.

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

Если компания находится в другом городе, как правило, вы созваниваетесь: рассказываете немного про себя, про пожелания, амбиции, сильные-слабые стороны. Разговор ведёт обычно рекрутер. Если вы не молчали все 30 минут, а нормально себя презентовали — назначают технический скрининг.

На техническом скрининге происходит примерно то же, что дальше на алгоритмической секции, но времени даётся меньше: 40–60 минут, 1–2 задачи: как правило, онлайн.

К этому формату нужно привыкнуть. Есть whiteboard-интервью: стоишь рядом с доской, рисуешь схемы, пытаешься писать на ней код — не очень удобно, многие жалуются. А онлайн в некотором смысле ещё хуже (кому-то, может, лучше). Сидишь за компьютером — человека не видишь, и говоришь — не только пишешь код. Не хочу никого обижать, но в этот момент часто возникает проблема, особенно у русскоговорящих разработчиков. В нашей культуре не принято хвастаться и болтать, мы «берём и делаем».

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

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

Следующие этапы зависят от компании. Я не собеседовался в Google, Amazon или Apple. Насколько мне известно, у всех них достаточно характерные процессы, следующие шаблону, но детали отличаются. Например, у Amazon есть Leadership Principles — набор правил, который рекомендуют выучить, потому что про них на собеседовании тоже будет разговор. В Facebook такого нет.

Алгоритмических секций несколько: обычно две-три. В докороновирусную эпоху вас привозят в офис, где всё происходит, встречают, сажают в переговорку, дают кофе. Вы решаете алгоритмические задачи: те самые, что видите на Leetcode. Кто-то советовал уровень Hard — это, кстати, необязательно. Сложные задачи встречаются, наверное, на Machine Learning или нагруженных бэкендах — я лично ни одного харда вообще не встречал. Обычно это уровень Medium: достаточно сложные, с ними надо уметь обращаться. Но если никогда не решали — наверное, есть шанс это сделать, есть просто потренировались и умеете думать.

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

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

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

Если прорешать 50 или 100 задач разных уровней в разных категориях, шансы пройти алгоритмическое собеседование сильно возрастут, между 0 и 100 решённых задач разница огромная. Но с устройством может по-прежнему не повезти. Советую на это смотреть философски, отказ может случиться в любом случае, это не всегда зависит от нас, как от кандидатов.

Кодинг обычно совмещён с алгоритмической секцией. Причём есть небольшая разница между бэкендом и фронтендом в Facebook. Те же алгоритмы на деревьях, графах или связанные с циклами, с массивами — но с фронтенд-спецификой. Как правило, всё на JavaScript.

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

А дальше бывает system design-интервью и behavioral: я сталкивался только с такими этапами.

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

Архитектурные секции — то же самое, что system design-интервью. Думаю, они есть на собеседованиях всегда, а их количество зависит от уровня, на который претендуешь. В Facebook была одна, во второй компании, куда собеседовался параллельно — 1 или 2.

Секция открытая, проблема не ставится так же, как в задачах на алгоритм. Одновременно важны и soft skills: умение поговорить, вывести и принять решение, спроектировать конкретную систему. Когда говорят про System Design, обычно идёт речь про дизайн чего-то высоконагруженного: надо сделать Твиттер или Инстаграм. Разумеется, за 40 минут нельзя спроектировать полноценный Твиттер.

Бывают и специфические задания: сделать форму ввода с автокомплитом. В случае с фронтендом может быть что-то типа: спроектируйте фронтенд для Яндекс.Карт: как вы структурируйте код, какие будут компоненты, какая подчиненность компонентов друг другу. Можно говорить про доставку контента для пользователей, CDN.

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

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

Если сравнивать с product design, думаю, в system design акцент на технические требования, умение оперировать стандартными понятиями: какая будет нагрузка, какой скорости нужны жесткие диски, чтобы система работала. Product design, видимо, больше про умение вас как инженера договориться с продукт-оунером, дизайнером, приоритезировать идеи, возможно, провести эксперименты. Это скорее про бизнесовую составляющую и организацию работы. У меня не было product design, допускаю, что поговорите о продукте, ценностях, проблемах — о том, что обычно является областью ответственности продакт-менеджеров.

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

— Расскажите о себе?

— Ну, я программист.

— А чем вы занимаетесь?

— Делаю сайт.

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

Поэтому надо уметь рассказать чётко и быстро самые классные аспекты бэкграунда и опыта. Чтобы потренироваться, можно записывать себя на телефон, лучше с видео. Потом послушать и повторить через несколько дней. Если есть желание разговориться, этот способ — отличный.

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

Ещё один совет: как правило, интервьюер ничего о вас не знает. Часто он смотрит резюме перед интервью за 3 минуты, ему бросаются в глаза какие-нибудь 4 термина, имя человека в лучшем случае. То есть вы как кандидат можете акцентировать внимание на отдельных аспектах своей истории, чтобы выглядеть максимально выгодно.

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

Если проходите собеседование в иностранной компании, диктофонный рассказ о себе и проектах стоит записывать на английском. Если вы самый крутой в мире программист, но не умеете говорить — интервью не пройдёте никогда, это точно.

Предполагаю, что можно встретить русского инженера, который предложит, по старинке, общаться на русском. Но всё равно в какой-то момент незнание языка может останавливать. В Facebook много русскоязычных людей, но по ним не очевидно, кто говорит по-русски. Иногда правила компании запрещают проводить интервью не на английском языке. Тогда общение на русском может быть максимум в неформальной части.

Я учил английский на протяжении 10 лет, и всегда думал, что у меня сносный уровень, особенно технического языка: читал мануалы, как все. Но в 2016 году поехал в Нью-Йорк и понял, что не понимаю ничего. Просто не слышу, что мне говорят — это меня шокировало. Затрудняюсь сказать, какой в тот момент был уровень, наверное, В1, upper-intermediate. Но я практически не понимал носителей и терялся в насыщенном разговоре.

Я вывел для себя критерии, по которым можно понять, что уровень подходит для прохождения интервью.

У спикеров обычно очень внятный язык, без сильного сленга и проглатываемых звуков. Для собеседования сертификаты не нужны, но понадобятся для переезда в Великобританию. Уровень формальный, В1 или В2 — если учить с нуля, на каких-нибудь курсах можно дорасти до него за год.

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

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

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

Из-за пандемии процесс собеседований меняется, формат работы тоже. Есть предположение, что ремоут скоро появится по всему миру. Сейчас компании стараются нанимать в текущих локациях, например, в США — со всей страны как минимум. Тяжело делать прогнозы, начнут ли нанимать людей из России, которые хотят остаться в России. Прямо сейчас рассчитывать на ремоут не стоит — может, в течение нескольких лет.

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

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

У нас в g-mate минимум 30–50% готовы рассматривать ремоут, а релокейт среди локаций на второй месте по популярности. За время пандемии и в России, и за рубежом наём ускорился в 3 раза. Регистрируйтесь в боте, чтобы получать лучшие вакансии в tech прямо в Телеграм.