[Личный опыт] Фронтенд-инженер из лондонского Facebook: как попасть в FAANG?

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

    Обсуждаем:

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



    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 в качестве маркетолога или проджект-менеджера.

    Плюсы:

    • развитие.
      Если вы очень любите свою работу, если вам хочется челленджей и сложных проектов, хочется развиваться и общаться с большим количеством людей, в том числе с лучшими специалистами.
      Первое, что понял, когда попал в Яндекс: «все вокруг умные, а я нет». Это типичная история, то же самое происходит, когда устраиваешься в Google, Facebook: в крупных компаниях очень питательная среда для роста. Особенно для людей, заинтересованных не в построении бизнеса, а в развитии себя как специалиста.
    • Стабильность, хорошая зарплата.
      Ещё разработчикам дают RSU — restricted stock unit, особый вид денежного вознаграждения. Обычно люди их тут же конвертируют в деньги за вычетом налогов. Так что RSU — своего рода прибавка к зарплате. Те деньги, которые я получал RSU-шками в Яндексе — откладывал, а потом пожил на них полгода в Штатах без работы.
    • Статус.
      Можно сказать: я работаю в Гугле! И это звучит круто.

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

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

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

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

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

    Если ищете позиции с релокейтом, подписывайтесь на наш бот @g_jobbot. А IT-рекрутер в g‐mate поможет упаковать резюме так, чтобы заинтересовать интервьюеров. Бот просто и быстро настраивается: сфера, зарплата, локация «релокейт». Подходящие вам варианты будут приходить в Телеграм.



    Резюме


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

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

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

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

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

    Хороший совет — писать резюме на одной, максимум — 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. Выбор языка — достаточно свободен. Когда собеседовался в другую компанию, писал на С# — хотя до этого никогда его не использовал. Но так как он объектно-ориентированный и похож на Java, то я просто уточнял в процессе: вот так можно? А так?

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

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

    Где готовиться


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

    • Leetcode — бесплатен для подборок задач в открытом доступе. Там есть платные подборки, есть премиум аккаунт, где можно найти то, что за месяц до вас спрашивали на собеседованиях в FAANG.
    • HackerRank
    • Codility
    • Interviewing.io
    • Codewars
    • AlgoExpert


    Архитектурная секция: system design


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

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

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

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

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

    Где готовиться




    Что важно и в процессе всего собеседования, и на behavioral-части


    Soft skills


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

    — Расскажите о себе?
    — Ну, я программист.
    — А чем вы занимаетесь?
    — Делаю сайт.

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

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

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


    Я рассказываю про парсер HTML, написанный в самолёте по пути на офсайт.

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

    Английский язык


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

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

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

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

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

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


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

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

    Итоги


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

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

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

    Что почитать дополнительно:



    Все полезные ссылки мы собрали вместе со слушателями вебинара. Если у вас есть дополнения — присылайте, добавим в список :)

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

    Комментарии 28

      +6
      Когда я вижу такие статьи, то я чувствую себя старым.

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

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

      А так за статью плюс, конечно.
        +1
        Да, это точно старость.
          0

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

            0

            У меня тоже было такое ощущение, которое в статье мы описали как "все вокруг умнее" — оно больше про работу в корпорациях, но и на собеседовании проявляется достаточно чётко. Вокруг и правда много людей умнее или опытнее — и "годы учёбы", которые вы упоминаете, тоже не помешают. Но если вы начинаете не с нуля, у вас есть релевантный опыт и желание подготовиться к собеседованию (а не к "крутости компании", это важно!), всё получится.

              +2

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


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


              В одном из проектов код бывшего сотрудника одной из FAANG был… Ну так себе. Не сказать, что плохой, на очень среднем уровне, который сможет показать любой выпускник курсов «Освой технологию NNN за три дня и начни зашибать деньгу!».


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

                0

                Вы поднимаете очень интересную тему.


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


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

                  0

                  Кто-то писал, что в таких компаниях наверняка скрупулезно ведётся и анализируется статистика, кого взяли, по каким параметрам, как показал себя в работе. Просто она не публикуется, так как это конкурентное преимущество.


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


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

                    0

                    Можно поискать в интернете — много кто делился тем, как устроен найм в гуглах и прочих амазонах. В основном это engineering managers, которые видят. Может быть на канале Etsy Engineering что-то есть, не помню.

                    0

                    Вот ещё попалась интересная статья на тему:
                    https://www.overcomingbias.com/2020/11/what-makes-prestige.html


                    Удивительно совпадает с тем, что еще едва ли не 10 лет рассказывал один русскоязычный сотрудник гугла.


                    В обсуждении на HN пишут, что тоже сталкивались с выходцами из Google/Facebook, пишущими плохой код.

                  +1

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


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

                    0

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

                  +2

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

                  0
                  Статья огонь, огромное спасибо!
                    0

                    Пожалуйста, рад, что вам понравилось. Можете ещё вебинар посмотреть — он получился достаточно живым.

                    0

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


                    Попадались подобные задачи и долго искали вариант, который был бы известен обоим. Пару раз так Хабр проектировал :)

                      +1
                      Как раз от вас они ожидают, что вы будете задавать правильные вопросы интервьюеру, чтобы получить некоторое описание, юзкейсы и т.п.
                        0

                        Это достаточно канонические примеры. Считается, что если вы интересуетесь высоконагруженным вебом, то знаете, что интересного в архитектуре Твитера или Инстаграма — оптимизация БД для чтения или записи, синхронизация и шардирование, кэеширование и так далее, а также всякие приколы из разряда "как разослать уведомление о посте в ленте Канье Уэста всем его подписчикам, которых десятки миллионов".


                        Конечно, обычный разработчик не сможет фактически написать всю систему с нуля за адекватное время (да и не нужно это), но пройтись по всей архитектуре, определить узкие места и trade-offs, и рассказать в итоге о том, что знаете вы — это обязательно. И этого может оказаться достаточно.

                          0

                          В том-то и дело, что я интересовался архитектурой сервисов, которыми я пользуюсь, о которых у меня возникала мысль "а как они с такими нагрузками справляются, если у меня тысяча уведомлений больше минуты рассылается". Фейсбук (или ВК) — я хотя бы имею (или имел) представлении об юзкейсах и порядке аудитории, что те же уведомления там есть в принципе. Твитер и Инстаграмм для меня какие-то нишевые сервисы, которые чуть ли не генерацией статических файлов можно сделать: публикует кто-то пост или фотку — генерируем страницу его поста/фотки и перегенерируем страницу его ленты. Даже база нужна постольку поскольку для этой функцинальности. Но вот от вас узнал и задумался, что наверное какие-то уведомления там таки есть и раз есть подписчики, то наверное у них есть сводка изменений в лентах у тех, на кого подписаны и, желательно, не просто email слать, а в онлайн режиме автоматически и полуавтоматически перезагружать основной экран или типа того

                            0

                            В Твитере, как минимум, есть не одна лента, а миллионы — и какой-никакой, но real-time в обновлении. Ведь если я подписан на вас, то ваш твит должен и в вашей ленте, и в моей, и у остальных подписчиков.


                            Вот, например, неплохое видео: https://www.youtube.com/watch?v=J5auCY4ajK8

                              +1

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


                              Спасибо, посмотрю перед сном.

                        0
                        Читаешь и жалеешь, что плохо знаешь анлийский.
                        Учите анлгийский — не прогадаете. А еще за одно — китайский.
                        Ну и автомат калашникова — на всякий пожарный случай.
                          0

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

                          +4

                          И всё-таки главный вопрос для сотрудника FAANG. В повседневной работе сортировки и алгоритмы на графах с нуля часто пишете?

                            0

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

                              0

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

                                0

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


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

                            +1
                            Как там с ворк-лайф балансом? После переезда в Испанию я кайфую уже больше года от осознания, насколько нет необходимости «умирать за большое бабло». В шесть часов встал и ушел, в пятницу в пять, в июле-августе тоже в пять.
                              0

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


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

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

                            Самое читаемое