Карьера в FAANG

Как Твиттер сократил 80% работников и выжил? Интернет полон мнений на эту тему, которые в основном расположены на шкале от "Твиттер живет на инерции и постепенно разваливается", до "80% сотрудников (и программных систем) не делали ничего полезного". В этом посте я предлагаю выпрыгнуть с этой линейной шкалы в плоскость и посмотреть на этот вопрос с другого угла. В среде инженеров часто встречается именно вторая крайность. Это естественно, многие из нас проходили System Design собеседование, где надо спроектировать Твиттер. Мы все хорошо знаем, что это можно сделать за час (хе-хе). В дополнение к этому, многие видели всевозможные ролики из тиктока, в которых сотрудники Твиттера хвалятся своим бездельем. Ну что ж, поговорим о Твиттере. В первую очередь я хочу обратить внимание читателя на то, что Твиттер не просто сократил сотрудников. Еще до сокращения, Твиттер полностью изменил бизнес-модель. Он был публичной компанией, живущей на инвестициях в рост пользовательской базы, и обещающей инвесторам монетизировать большую пользовательскую базу с помощью рекламных продуктов. После реорганизации Твиттер стал приватной компанией, планирующей монетизироваться напрямую через подписочную модель. Мы видим, что это не просто слова. Компания действительно ушла с публичного рынка. Компания действительно разорвала отношения с важными рекламодателями, но зато ввела платную подписку для пользователей. С высоты 11 лет опыта работы в публичных технологических рекламных гигантах, я оцениваю работу, которая обеспечивает публичность и рекламность в как минимум 90% от всей работы. Так что Твиттер по моей оценке даже недожал, возможно, как раз из за необходимости поддерживать или чистить легаси софт. Во-первых, публичные компании требуют огромного пласта аналитики. Код продуктов пронизывает инструментарий для сбора и организации данных. Для их хранения, организации, анализа создаются внутренние технологические продукты, и целые организации инженеров, их разрабатывающие. Создаются целые организации инженеров по аналитике этих данных. Большие организации финансистов, которые обеспечивают уже не продукты компании, а публичный образ компании для инвесторов, основанный на данных. Создаются организации PR-щиков для создания публичного образа для обычных людей, так как этот образ тоже отражается на биржевых показателях. Помимо финансистов есть еще рекламодатели. Рекламодатели, особенно большие, -- это тоже огромные публичные компании. Все проблемы, описанные выше, применимы и к ним. Чтобы с ними работать, необходимо соблюдать все эти требования. Если рекламодателю не нравится контент, рядом с которым ты показал их рекламное обьявление -- он быстро придет к тебе с угрозой перенаправить свой девятизначный рекламный бюджет. Если вы подумали -- фи, что там эти девять знаков для Твиттера, то не обольщайтесь. Такой недовольный будет не один. Большие компании имеют схожие запросы к площадке, поэтому и уходить они будут все сразу. В твиттере были целые организации инженеров, разрабатывающих софт для детекции неприемлемого контента, а также организации ручных модераторов контента, организации тренингов модераторов, организации учета инцидентов, организации для коммуникации состояния сети рекламным партнерам. Сделать компанию приватной и одновременно сменить стратегию монетизации с рекламы на подписки -- это смелые шаги, и мы еще увидим, к чему они приведут. Как бы то ни было, именно эти шаги и позволяют отрезать 80% персонала, и оставить только инженеров, непосредственно разрабатывающих основную программную систему Твиттера. Дело даже близко не в бесполезных сотрудниках, коих обычно единицы процентов.

Через 30 минут стрим! Ссылка https://youtube.com/live/BszF1gPsgow?feature=share

Почему люки круглые? Многие слышали, что в FAANG компаниях раньше задавали этот и подобные вопросы на собеседованиях. А потом отказались. Многие даже читали, почему отказались. Это написано на сайте: мол, провели исследование, поняли, что не эффективно, перестали. Если читатель хочет работать в FAANG, я надеюсь, что его не удовлетворил такой ответ в виде корпоративной отписки. Где детали? Что не так с люками? Почему процесс собеседования нужно было менять? Поговорим о люках. Эта история получена мной по неофициальных разговорах с коллегами из Гугла, которые были очевидцами. Не является официальной позицией компании. Я уже писал, что собеседование -- это симуляция работы. Казалось бы, вопрос про люки вполне подходит под эту задачу. На первый взгляд ничего не понятно, а на второй есть десяток гипотез, в которых надо сориентироваться. Все прямо как на работе. Так что это, в принципе, совсем не плохой вопрос, он эмулирует типичный рабочий вопрос о дизайне системы и проблем солвинг. Почему же от него избавились? На поверхности ответ тривиален: нашли вопросы еще лучше. Но чем современная кодинг-сисдиз-бихейв триада лучше люков? Во-первых, все три типа секций включают разговоры о программных системах. Как писать код, как проектировать, какие системы кандидат создавал ранее. Дизайн люков -- все еще дизайн, но не программных систем. Новый процесс убивает двух зайцев одним ударом: проверяет и навыки дизайна в принципе, и дизайна программных систем в частности. Во-вторых, вопросы про люки и теннисные шарики в автобусе ограничены. Их буквально все выучили наизусть. Раньше эти вопросы спрашивали на топ позиции в банки и консалтинг фирмы, где тоже нужны умные люди с проблем солвинг скиллами. Но потом появился интернет, а в техе умных людей стало требоваться на три порядка больше. Поэтому выросла целая индустрия книг, статей, видео, с разбором этих вопросов. И теперь все уже наизусть знают, как на них отвечать. В итоге, вопросы потеряли эффективность. В отличии от них, литкод и дизайн систем секции бесконечно вариабельны, и никогда не будет возможно выучить все комбинации всех задач со всем фоллоуапами. Новый процесс лишен этого недостатка. В-третьих, вопросы про люки слишком сложные. Нет, даже не для кандидата, а для собеседующего. На масштабе найма Big Tech, собеседовать должны в том числе и Junior/Middle инженеры. У большинства из них нет квалификации извлечь нужные сигналы из ответа о люках. Эти вопросы работали, когда собеседовали кандидатов только очень старшие "мэтры". С подключением к интервью всех сотрудников, стала необходима конкретизация вопросов, чтобы сотрудники могли просто записывать факты, а сигналы извлекали из логов уже Hiring комитеты. Оказалось, что Junior/Middle инженеры часто не могут записать очень нюансные факты хода мысли кандидата. С программными системами все гораздо проще, так как даже если собеседующий и не понимает сигналов, он точно уже эксперт в домене и легко может записывать понятные ему факты, из которых уже эффективно извлекаются сигналы комитетом. Так что нет, вопрос про люки -- вполне хорош, в принципе. Его заменили не потому, что он неэффективен сам по себе, а потому, что стал неэффективен после длительного использования в век интернета. А также потому, что нашли более эффективный и масштабируемый пул вопросов.

Нет никаких Архетипов стафф инженера. По сети циркулирует популярная "книга про Стафф инженера", которая описывает разные "архетипы". Очень много людей в tech индустрии её читали, им понравилось, и они ретранслируют эту идею. Я называю её "книгой про карго культы". Почему? Дело в том, что нет никаких "архетипов". Есть определение Staff позиции, и оно примерно одинаково во всем Big Tech. Все очень просто: инженер подходит под это определение, и ему предлагают Staff позицию. Окей, в разных ситуациях разные нужды, и потому Staff инженеры часто имеют разные ежедневные задачи. Разные текущие дела можно перечислить в книге и назвать их "архетипами". Так что книга сама по себе ок, там нет откровенных глупостей. Так почему она про карго культы? Потому, что огромное количество читателей решает, что чтобы стать Стафф инженером, надо воспроизвести какой-то архетип, не понимая, что не архетип делает вас Стаффом, а сначала вы Стафф, а потом уже ваша ежедневная работа может стать похожей на архетип. Не надо думать: "щас я буду техлид/архитектор/фиксер/кто там еще, и так мне дадут Staff". В FAANG целая куча Middle техлидов, архитекторов и фиксеров. Не нужно, как попугаи, следовать карго культам архетипов. Это никак не поможет приблизиться в желанной роли.

Senior Staff позиция в FAANG. В прошлый раз я рассказывал про Staff позицию, на которой от сотрудника ожидается задавать успешную стратегию организации. Сегодня поговорим о занятиях людей на следующей после Staff позиции. Senior Staff позиция в FAANG описывается одним словом -- scale (масштаб). Сотрудник на этой позиции задает стратегию, способную привести к масштабному импакту. Как определяется "масштабность"? Очень просто -- импакт на порядок больше, чем у типичного Staff инженера. Вы придумали новый формат рекламы и он начал зарабатывать десятки миллионов в год? Добро пожаловать на Staff позицию. Вы отмасштабировали его до миллиарда -- это уже уровень Senior Staff. Вы разработали новую БД с лучшими характеристиками, что ускорило разработку важной системы? Вам стоит предложить Staff позицию. Вы смигрировали всю организацию на 10к человек на эту БД? Senior Staff оффер уже на вашем столе. Повышение до Senior Staff позиции в Google считается проще, чем до Staff позиции. Это объясняется тем, что если у сотрудника уже такой склад ума, что он может задавать успешную стратегию, рано или поздно одна из стратегий приведет к масштабному импакту. Не всегда это получается с первого раза, иногда приходится попробовать несколько "стратегий", но чаще всего уже имеющийся навык приводит к успеху в течении нескольких лет. Не стоит думать, что существуют проекты с "масштабным" импактом. Такое бывает исключительно редко. Подавляющее большинство Senior Staff людей добилось масштаба не одним проектом, а серией проектов, которые постепенно увеличивали импакт, как снежный ком. На моем опыте был случай, когда за заработанный миллиард в год в рекламной платформе Гугла одному коллеге предложили Staff позицию, а другому Senior Staff. Читатель может подумать -- как это так, один и тот же импакт считается масштабным и немасштабным одновременно? Но оба этих случая были справедливы. В одном случае автору проекта повезло заработать миллиард одним запуском в одном месте, улучшив существующий продукт. В другом же случае автор сделал более пяти запусков, включая запуск нового продукта с новой технологией, и улучшение нескольких старых продуктов той же технологией. Несмотря на одинаковый финансовый результат, "импакт" на рекламную платформу второго инженера был значительно масштабней, так как своей технологией он поменял мышление многих команд, а не только сиюминутно заработал денег. Найм на Senior Staff позицию извне -- редкое дело. Проверка соответствия на Senior Staff отличается от проверки на Staff. Если Staff сотрудник должен уметь предложить стратегию и выиграть "битву", то Senior Staff должен уметь выигрывать "войну", консистентно выигрывая серию "битв" и накапливая превосходство на некотором "фронте" импакта. Кандидату необходимо cкоммуницировать, как он смог добиться масштабного импакта, запустив серию связанных проектов, каждый из которых приумножил импакт предыдущих. Специально уточню, что наборы несвязанных проектов с большим импактом не показывают готовность к Senior Staff позиции. Проекты обязательно должны быть связаны в серию и дополнять друг друга. #level

Кто такой Engineering Manager (EM) в FAANG? В предыдущих постах я разобрал, кто такие SWE и PM. В этом после я продолжаю эту серию и рассказываю, кто такой EM. Многие привыкли, что "менеджер" и "руководитель" -- это синонимы. Руководитель говорит команде, что делать. Однако я рассказывал, что уже Middle инженер может самостоятельно решать любые конкретные задачи, Senior инженер достигать бизнес-целей, а Staff инженер задавать успешную стратегию для команды. Что же остается менеджеру? Давайте разбираться. Engineering Manager в FAANG -- это инженер, компетентный в построении команды. Он не занимается программными системами, и даже продуктами. Он строит команду, которая строит программные системы и продукты. Если он работает с людьми, то почему же он -- инженер? В сущности, команда -- это такая же система, как и софт, только работающая на углеводах вместо "сырых" электромагнитных полей, на которых работают компьютеры. У команды есть некий рабочий процесс, в ней есть разные "компоненты", предоставляющие разный "функционал" и имеющие разные "проблемы". Задача менеджера -- динамически перестраивать команду, оптимизируя ее эффективность под текущие (и будущие) цели. Отсюда сразу понятно, почему подавляющее большинство EM в FAANG -- бывшие SWE. По большому счету, научиться достигать целей с помощью людей мало чем отличается от умения достигать целей с помощью программных систем. Людей можно воспринимать как еще один фреймворк, который нужно изучить. Очень сложный фреймворк, но так же и очень мощный. В FAANG команды не создаются под задачи. Как минимум, команды создается под бизнес-цель. По этой причине Engineering Manager роль начинается с Senior позиции. Менеджер должен уметь достигать бизнес целей, именно под конкретные цели он строит команду. Талантливый менеджер может пойти дальше, и построит команду, которая имеет возможности сверх поставленных целей, и сама задает новую стратегию для огранизации. Построение команды, которая не просто достигает поставленных целей, но и успешно задает стратегию, показывает что менеджер удовлетворяет требованиям на Staff позиции, после чего менеджера повышают в уровне. Очень важно не пропустить, что это не сам менеджер должен задать новую стратегию, а именно построенная им команда. Есть такой феномен как IC Manager. В Google они называются TLM (Technical Lead Manager). Его компетенции оцениваются по правилам где-то между SWE и EM. Лично я ни разу не видел, чтобы эта модель хорошо работала: она банально вызывает конкуренцию между TLM и SWE одного уровня. И Senior TLM и Senior SWE должны задавать успешную стратегию для повышения до Staff позиции, при этом у TLM есть формальная власть над SWE (как минимум TLM представляет SWE на performance review). В результате SWE просто не может задавать свой курс, и не имеет шанса на повышение. Это корректируется дополнительными политиками, вроде того, что если у Senior TLM появился Staff SWE, то и TLM почти наверняка будет повышен. Это частично работает, но все равно часто вызывает напряжение, так как оба не уверены в добросовестности другого. Начиная с сильного Staff SWE я советую всегда искать команды с EM, а не TLM, а для Senior SWE искать команды с как минимум Staff TLM.

Что такое FAANG? В дискуссии с читателями я осознал, что я пишу про "FAANG", но не все понимают, что я под этим имею ввиду. Рассказываю. На поверхности это простой вопрос с простым ответом: Facebook, Amazon, Apple, Netflix, Google. Но этот ответ не говорит нам ничего интересного, не раскрывает сути вещей. Почему сюда включены эти компании? Изначально термин FAANG придумали финансисты, включив сюда быстро растущие в капитализации интернет-компании. Этот ответ может быть интересен этим финансистам на тот момент времени. Но во-первых, времена меняются и сегодня быстрорастущие компании другие, а во-вторых, этот ответ тоже не интересен, так как не раскрывает ничего про то, чем их работа отличается от других. В-третих, лично я не включаю Netflix в FAANG, зато включаю Microsoft. Итак, о чем же я веду этот канал? Тут важно заметить, что есть бесконечное количество определений FAANG и каждый волен определять как вздумается. Тут я излагаю свой подход, которого я придерживаюсь в канале. Другие подходы имеют такое же право на жизнь, но в этом канале я их не придерживаюсь. В этом канале под FAANG я понимаю компании, ставящие перед собой задачу решить максимально широкий круг проблем с помощью компьютеров. Именно поэтому Netflix, OpenAI, GitLab, CockroachDB -- это не "FAANG" в моем понимании. Это все крутые компании, но они фокусируются на одной единственной задаче, инвестируя все в то, чтобы делать ее хорошо. "FAANG" компании поступают наоборот -- берутся делать вообще все подряд. Любая идея, которая предлагает использовать компьютеры для решения проблемы будет рассмотрена и часто испытана. Почему я выбрал для этого канала такое определение? Потому, что из него непосредственно следуют особенности работы и развития инженерной карьеры в таких компаниях. А именно, не компания говорит сотруднику, что ему делать, а наоборот, сотрудник должен говорить компании, что ей делать. Если вы придете работать в Netflix, вам скажут -- садитесь улучшайте UX приложения для просмотра сериалов (UI, latency, рекомендации, закладки, лайки, etc). Да, не всегда понятно, как еще можно понизить latency или выжать еще 1% точности рекомендаций. Но зато понятно, над чем именно надо работать. Придя же в Google, новый сотрудник видит совершенно другую картину. Ваш директор (в основном) не решает, что вам делать, а наоборот ждет, что вы придете и ему скажете, что его организация должна делать. И это решает каждый сотрудник, включая Junior уровня (может не всех, но такая опция есть для тех, кто умеет). Соответственно и карьерный рост в основном состоит из успехов идей сотрудника, а не функциональных знаний о языках/фреймворках/инструментах и не от скорости решения задач. Знания и скорость помогают тестировать больше идей, но без успешных идей роста не будет. Это очень большой сдвиг в мышлении на работе, из за чего многим тяжело быть успешными в таких компаниях. С другой стороны, тем, кому комфортно так работать, часто тяжело добиться успеха в сфокусированных компаниях, и работа в них часто ощущается скучной. Это определение позволяет понять, в чем особенности работы, которые сотрудники ощущают каждый рабочий день. На мой взгляд это гораздо более практически полезный критерий, чем капитализация, субъективный престиж компании или разнообразие печенек в офисе. Какие еще компании, которые подходят под это определение, предлагайте в комментариях?

Что такое собеседование? На первый взгляд, это странный вопрос. Как это что, кандидат приходин в офис (последнее время все чаще на звонок), ему задают вопросы, если в офисе, угощают чаем, и слушают ответы. Но это все поверхностные детали, а не суть процесса. Над сутью мало кто задумывается. Очень распространен миф, что собеседование -- это что-то вроде экзамена. И действительно, по некоторым признакам выглядит похоже, особенно если не вдаваться в детали. Но нет, это не экзамен: - Экзамен односторонен (собеседование двусторонне) - На экзамене есть правильный ответ (на собеседовании нет) - На экзамене проверяются знания (на собеседовании, в основном, подход к работе) Так как собеседование -- вообще не экзамен, подход к нему как к экзамену обречен на провал, ну или уж по крайней мере на существенно сниженный результат. Окей, что же такое это ваше собеседование? Собеседование -- это дистилляция симуляции работы. В этом месте многие сотрудники FAANG+ компаний возразят, мол какая еще симуляция работы, на работе мы ни разу не обращали бинарное дерево! Действительно, не обращали. Именно поэтому я и сказал "дистилляция". В собеседование компания выделяет все действительно важные аспекты рабочего процесса, игнорируя неважные (по мнению лидеров этой компании). В примере с Leetcode-собеседованием для SWE эти важные части такие: 1. Умение объяснять вычислительной машине, что вы хотите, чтобы она вычислила (в простонародье -- кодить) 2. Умение, столкнувшись со сложной задачей, ее решать (заметьте, не решить, а решать -- двигаться в сторону решения, даже если до него не получилось дойти) 3. Больше деталей можно узнать из цикла про Leetcode собеседования В Big Tech считается, что остальные аспекты рабочего процесса недостаточно важны, чтобы включать их в собеседования. Кодить фичи, изучать фреймворки, проходить и делать код ревью -- это все мелочи жизни, которым вас по надобности научат уже внутри. Аналогичная картина с остальными секциями собеседования, они по-разному симулируют важные аспекты рабочего процесса в компании. Каким и на какую позицию бы ни было собеседование, всегда помните, что собеседующий изучает вас именно на предмет того, как вы справляетесь с важными аспектами будущей работы. По результату собеседования, принимающие решения о найме люди сделают вывод, что если кандидата нанять, то он будет работать ровно так же, как симулированно работал на собеседовании. Оффер кандидату основывается именно на этой экстраполяции.