Карьера в FAANG

Principal позиция в FAANG. В прошлый раз я рассказывал про Senior Staff позицию, на которой от сотрудника ожидается импакт большого масштаба. Сегодня поговорим о занятиях людей на следующей после Senior Staff позиции. Principal позиция в FAANG описывается одним словом -- transformative (трансформация). Сотрудник на этой позиции существенно изменяет, как работает компания. Один из признаков transformative impact в FAANG -- влияние на индустрию. FAANG -- очень большие компании. Потому они редко принимают новые способы работать первыми. Если инженер смог повлиять на то, как работает много компаний в индустрии, это хороший сигнал для изменения в работе тех гиганта, необходимого для Principal позиции. Сложно дать определение трансформации. Это проект, который значительно меняет, как работает компания. Что значит значительно, что значит работает? В реальности, никто не дает более детальных определений. Оценка проекта как "трансформационного" дается в сравнении с другими проектами, которые были признаны трансформационными ранее. Поэтому, этот пост отличается от предыдущих постов про уровни. Для этого уровня я только приведу примеры проектов, и расскажу, почему они считались трансформационными. Система сборки кода Гугла Blaze, опубликована в Open Source как Bazel. Еще очень давно это был проект с масштабным импактом -- эта система сборки эффективно собирать терабайты кода десятка тысяч инженеров в Google. Бывшие сотрудники Гугла имплементировали аналогичные решения внутри Facebook и Twitter, поэтому было понятно, что эта технология имеет большой потенциал. Публикация этой системы в Open Source, организация конференции, создание коммьюнити, все это привело к адаптации этой технологии в значительном количестве компаний. Это заметное изменение индустрии разработки программных систем, и несомненно привело к нескольким повышениям до Principal позиции (Sr. Staff TLM -> Director для менеджера команды, Sr. Staff SWE -> Principal SWE для техлида). Тут стоит заметить, что Bazel не трансформировал, как работает сборка внутри Google. Внутри она всегда была так устроена, и Bazel был лишь итерацией для улучшения UX. Этот проект трансформировал индустрию именно при публикации в Open Source. Новая платформа для рекламных B2B приложений. Рекламные продукты в Google создает команда из десятка тысяч инженеров. B2B приложения создавались на GWT (это был такой компилятор Java для браузеров), но без какого-то общего подхода. В какой-то момент, все эти приложения переделали на новый стек -- Material UI, Angular, Dart. Для этого был разработан фреймворк на Dart, поверх Angular-Dart, со стандартными компонентами Material UI и другими подходами к разработке. Читателю могут не нравиться какие-то из этих технологий, но вне всякого сомнения этот проект сильно изменил, как тысячи инженеров разрабатывают критически важные для компании приложения. Замена Bigtable на Spanner. Bigtable -- eventually consistent база данных, использовавшаяся в Google для всего подряд. Для некоторых задач это идеальное, дешевое решение. Но как только требуется strong consistency, Bigtable начинает создавать боль в виде редких, плохо воспроизводимых багов консистентности данных. Эта проблема породила зоопарк кастомных решений поверх Bigtable, добавляющих неидеальные аналоги консистентности, для конкретных приложений. Spanner -- другая база данных, разработанная позже, и обладающая strong consistency. Проект по апгрейду всего Гугла с Bigtable на Spanner несомненно изменил, как десятки тысяч людей разрабатывают серверные приложения, почти всегда в лучшую сторону. Этот проект наверняка привел в нескольким повышениям до Principal позиции. Специально замечу, что речь идет не о самой разработке Spanner, там был свой трансформационный импакт. Проект по апгрейду всего Гугла на уже готовый Spanner был трансформационным сам по себе. Получить оффер на Principal позицию очень просто: кандидату нужно показать, что он трансформировал технологическую индустрию, связанную с бизнесом компании. Нет смысла вдаваться в детали: если вы трансформировали индустрию, это будет очевидно всем собеседу

Как Твиттер сократил 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 считается, что остальные аспекты рабочего процесса недостаточно важны, чтобы включать их в собеседования. Кодить фичи, изучать фреймворки, проходить и делать код ревью -- это все мелочи жизни, которым вас по надобности научат уже внутри. Аналогичная картина с остальными секциями собеседования, они по-разному симулируют важные аспекты рабочего процесса в компании. Каким и на какую позицию бы ни было собеседование, всегда помните, что собеседующий изучает вас именно на предмет того, как вы справляетесь с важными аспектами будущей работы. По результату собеседования, принимающие решения о найме люди сделают вывод, что если кандидата нанять, то он будет работать ровно так же, как симулированно работал на собеседовании. Оффер кандидату основывается именно на этой экстраполяции.

В прошлом посте я рассказал о своем L3->L4 SWE промо в Google. А еще я пригласил коллег поучавствовать и тоже рассказать о своих промо. Чтобы привлечь больше классных людей к этой затее, я сделал пост в LinkedIn. Если вам понравилась идея и вы хотите услышать больше историй, распространите его в своей сети!

Мой L3->L4 SWE promotion в Google Я работал в роли Junior SWE в Google AdSense Frontend в Лондоне. Моя команда разрабатывала поисковую систему для людей и компанией, которые устанавливают на свои сайты и приложения рекламу от Гугла. Они использовали этот поисковик для просмотра и поиска рекламных объявлений, которые Google показывал на их сайте. Так же мы давали возможность заблокировать объявления или рекламодателя, чтобы эти объявления больше не показывались на их сайте. Когда-то давно, уже много лет как ушедший из команды инженер разработал поиск по картинкам для этого поисковика. Пользователь загружал картинку, и получал рекламные объявления, которые похожи на эту картинку. Уточню, что это все было сильно задолго до бума нейросетей, так что поиск использовал классические алгоритмы. Вот только была проблема -- этот поиск не работал. У команды было множество репортов от пользователей, что они не нашли нужное объявление по загруженному логотипу. Внутреннее тестирование показало, что система действительно плохо работает. В этот момент руководителю удачно подвернулся я, и мне поручили разобраться. И я разобрался! В результате моей работы поиск по картинкам стал отлично работать на простых случаях (лого, ландмарки). Еще в нем появилась новая функциональность поиска по скриншоту объявления, на котором Гугл рисует вотермарк, и мы можем найти именно то объявление, что было показано, при чем, уже в течении минут после показа. К тому же, я сделал систему измерения качества этого поисковика, чтобы подтвердить все эти улучшения. Все это заняло у меня где-то 3 квартала (9 месяцев). Повышение до L4 с этим кейсом прошло без сучка и задоринки (по заявлению моего менеджера и даже директора). Почему так вышло? В тот момент я был уверен, что дело в масштабе и сложности работы. Еще бы, я фактически разработал новый поисковик! Да, наработки были, но они не работали и требовали почти полной переделки. Девять месяцев работы, весь стэк: UI, сборка поискового индекса, серфинг индекса, интеграция в существующий продукт, онлайн метрики работы системы, поддержка и автоматизация релизов, оффлайн метрики качества поиска, работа с внешней командой вотермарков, совместный запуск. Звучит впечатляюще! Да мне надо было сразу директора дать за разработку целой поисковой системы! На самом деле все было гораздо приземленней. Эта работа была совершенно точно не Staff уровня, ведь мне ее спустили "сверху", не я задавал стратегию. Эта работы была так же не Senior уровня, потому, что не я лидировал проект, в частности не я разработал план: мне предложили начать с разработки системы измерения качества, мне предложили сфокусироваться на конкретных частях системы после сбора данных, etc. Но это была хорошая Middle работа: имея готовый план, разбивающий общую задачу на несколько подпроектов (измерение качества, новый UI, новый индексер, новая инфраструктура), я самостоятельно спроектировал программные системы для этих подпроектов, на требуемом (в рекламе очень высоком) уровне качества и в адекватный срок. По сути, проект состоял из нескольких подпроектов уровня Middle и тем самым я показал не только способность работать на уровне Middle, но и консистентность -- я смог это сделать на нескольких под-проектах подряд, не скатываясь в Junior поведение. #canonical_packet

Мой L3->L4 SWE promotion в Google Я работал в роли Junior [SWE]() в Google AdSense Frontend в Лондоне. Моя команда разрабатывала поисковую систему для людей и компанией, которые устанавливают на свои сайты и приложения рекламу от Гугла. Они использовали этот поисковик для просмотра и поиска рекламных объявлений, которые Google показывал на их сайте. Так же мы давали возможность заблокировать объявления или рекламодателя, чтобы эти объявления больше не показывались на их сайте. Когда-то давно, уже много лет как ушедший из команды инженер разработал поиск по картинкам для этого поисковика. Пользователь загружал картинку, и получал рекламные объявления, которые похожи на эту картинку. Уточню, что это все было сильно задолго до бума нейросетей, так что поиск использовал классические алгоритмы. Вот только была проблема -- этот поиск не работал. У команды было множество репортов от пользователей, что они не нашли нужное объявление по загруженному логотипу. Внутреннее тестирование показало, что система действительно плохо работает. В этот момент руководителю удачно подвернулся я, и мне поручили разобраться. И я разобрался! В результате моей работы поиск по картинкам стал отлично работать на простых случаях (лого, ландмарки). Еще в нем появилась новая функциональность поиска по скриншоту объявления, на котором Гугл рисует вотермарк, и мы можем найти именно то объявление, что было показано, при чем, уже в течении минут после показа. К тому же, я сделал систему измерения качества этого поисковика, чтобы подтвердить все эти улучшения. Все это заняло у меня где-то 3 квартала (9 месяцев). Повышение до L4 с этим кейсом прошло без сучка и задоринки (по заявлению моего менеджера и даже директора). Почему так вышло? В тот момент я был уверен, что дело в масштабе и сложности работы. Еще бы, я фактически разработал новый поисковик! Да, наработки были, но они не работали и требовали почти полной переделки. Девять месяцев работы, весь стэк: UI, сборка поискового индекса, серфинг индекса, интеграция в существующий продукт, онлайн метрики работы системы, поддержка и автоматизация релизов, оффлайн метрики качества поиска, работа с внешней командой вотермарков, совместный запуск. Звучит впечатляюще! Да мне надо было сразу директора дать за разработку целой поисковой системы! На самом деле все было гораздо приземленней. Эта работа была совершенно точно не Staff уровня, ведь мне ее спустили "сверху", не я задавал стратегию. Эта работы была так же не Senior уровня, потому, что не я лидировал проект, в частности не я разработал план: мне предложили начать с разработки системы измерения качества, мне предложили сфокусироваться на конкретных частях системы после сбора данных, etc. Но это была хорошая Middle работа: имея готовый план, разбивающий общую задачу на несколько подпроектов (измерение качества, новый UI, новый индексер, новая инфраструктура), я самостоятельно спроектировал программные системы для этих подпроектов, на требуемом (в рекламе очень высоком) уровне качества и в адекватный срок. По сути, проект состоял из нескольких подпроектов уровня Middle и тем самым я показал не только способность работать на уровне Middle, но и консистентность -- я смог это сделать на нескольких под-проектах подряд, не скатываясь в Junior поведение. #canonical_packet

#canonical_packet Я написал много теории о ролях и уровнях, и еще продолжу писать. Но теория иногда слишком абстрактна, и ее легко понять только уже эксперту в домене. Потому я решил дополнить теорию рассказами о реальных повышениях (мы их назваем promo packets) и их мотивации. В Google есть инстритут каноничных пакетов (canonical packets). Это репозиторий с документами, в который описаны промо кейсы людей, каковые кейсы были одобрены комитетами очень старших коллег как "каноничные", такие, которые будущие кандидаты на повышения должны копировать, чтобы повышение было заппрувлено без обсуждений и сомнений, одним махом. Так уж получилось, что мне мои промо кейсы были без шероховатостей и вполне могут быть включены в репозиторий каноничных. Начну я с себя, но один человек -- не самая большая выборка. Потому я приглашаю всех коллег написать о своих промо-пакетах и опубликоваться в этом канале! Что рассказывать? 1. Компания и уровень, на который вы повышались. 2. В чем была основа промо кейса? 3. В чем, по вашему мнению сразу после повышения, была причина повышения? 4. В чем вы ошибались и как вы сейчас понимаете, почему на самом деле вас повысили? Правила такие: 1. Вы работаете в FAANG или в Big Tech компаниях, которые копируют карьерный фреймворк у FAANG. 2. Вы хотите рассказать про повышение L(X-1) -> LX. 3. Cейчас вы L(X+1), или повышение до LX было как минимум 2 года назад. 4. Промо-пакет должен быть "каноничным" -- должен был пройти без запинки и без обсуждений.

Staff Engineer в FAANG. В прошлый раз я разобрал Senior позицию, на которой сотрудник FAANG занимается достижением установленных конкретных бизнес-целей. Senior Software Engineer (SWE) разрабатывает программную систему, с помощью которой достигается цель, а Senior Product Manager (PM) разрабатывает требования к этой системе. Но кто ставит эту цель? Многие могут подумать, что знают ответ на этот вопрос. Понятно кто -- руководитель! В FAANG это не так. О том, чем занимаются "руководители" (Engineering Manager, EM) я расскажу в другом посте, а сегодня речь об установке целей. Staff позиция в FAANG описывается одним словом -- стратегия (strategy). Человек на этой позиции устанавливает конкретные цели. Нужно ли сейчас повышать надежность продукта для существующих пользователей или нужно расширяться на новых? Это решает человек на Staff позиции. Как и на Senior позиции, Staff SWE и Staff PM ставят цели совместно, согласовывая свои видения ситуации с разных углов зрения. Многие представляют себе компании как иерархические структуры, где сверху вниз идут команды, что делать. В FAANG же выше Staff уровня еще как минимум 6 других уровней. Это что получается, какой-то Staff инженер диктует Гуглу, что Гугл должен делать? Да, именно так все и происходит. На Staff позиции не директор говорит инженеру, что ему делать, а инженер своему директору, что его организация должна делать. Успех (и бонусы) человека на Staff позиции определяются успешностью предлагаемой им стратегии. Подняться до Staff позиции очень сложно. В Google считается, что это повышение даже сложнее, чем следующее. И неудивительно: фактически нужно вывернуть свою работу наизнанку. Не хорошо делать, что попросили другие, а самому говорить себе и другим, что им надо делать. Мало того, что на это способен далеко не каждый сотрудник, даже уровня FAANG, так еще и получить возможность продемонстрировать это умение очень тяжело. Сами посудите, почему ваш директор и остальные лидеры в его организации должен согласиться спонсировать именно вашу уникальную стратегию, а не стратегии остального десятка Staff+ сотрудников в его организации? Совершенно не потому, что предлагаемая стратегия хороша. Вероятнее всего, стратегии от более опытных коллег еще лучше. Главная причина в том, что у Senior кандидата на Staff позицию есть репутация человека, который создает инновации там, где их ранее не было. PM предлагает такие требования, которые пользователи даже еще не знают, что они им нужны. SWE разрабатывает программные системы, которые решают проблемы, которые никто не знал, что можно решить, а еще лучше проблемы, о чьем существовании никто даже не знал. Как себя вести на собеседовании на Staff позицию? От кандидата, который будет успешен на Staff позиции ожидается демонстрация умения определять стратегию организации. Иными словами, это кандидат должен сказать компании, какую задачу надо решать, а не компания кандидату. На этом месте читатель может подумать: что за бред, это же кандидату дают задачу в начале собеседования, как это он будет сам диктовать, какую задачу надо решать? Если кандидат будет решать не ту задачу, что попросили, ему же откажут? Если читатель так подумал, это всего лишь значит, что читатель просто-напросто не имеет опыта выбора стратегии для компании калибра FAANG. Разрешить этот парадокс очень просто, если такой навык есть, и совершенно невозможно, если его нет.

#Гипотеза Кандидат должен быстро ориентироваться с незнакомыми проблемами и уметь преодолевать трудности. Поскольку все активно гриндят литкод, то если кандидату дать похожую задачу понятного паттерна из тех, что он уже освоил, то он не сможет показать нужных скиллов, а просто продемонстрирует умение паттерн-матчить и вспоминать. Вот и появляется дать цель не столько сложное, сколько незнакомое/непохожее.

А вот и правильный, а так же очень четко сформулированный, ответ!

Поиграем в игру? Нас уже 600! Я часто вижу вопрос: почему в FAANG с годами алгоритмические собеседования стали сложнее? Так уж вышло, что я знаю ответ на этот вопрос. Самый распространенный ответ, который я вижу -- собеседование стали сложнее потому, что в IT пришло много народу, откуда конкуренция больше, откуда у компаний требования выше. Это неправильный ответ, требования к кандидатам не изменились. Однако, собеседования сложнее и правда стали. Так почему? Предлагаю подписчикам игру, в которой подписчики получат возможность докопаться до сути вопроса. Правила игры: 1. Каждый подписчик имеет одну попытку, в которой он может предложить свою гипотезу, почему алгоритмические собеседования в FAANG стали сложнее с годами. 2. Предложить гипотезу подписчик может написав комментарий к этому посту с тегом #гипотеза. 3. Если подписчик предлагает верную гипотезу, он выигрывает и получает приз -- мок собеседование со мной (тема на выбор подписчика). 4. Если подписчик предлагает неверную гипотезу, он проигрывает и выходит из игры. 5. Дополнительно, каждый подписчик может задать максимум 5 наводящих вопросов, на которые я буду только отвечать “да” или “нет” в виде реакций. 6. Наводящий вопрос не может быть гипотезой с вопросом “эта гипотеза верна?”. Читерить я не дам, у каждого только одна гипотеза! Не пытайтесь меня обхитрить, вы просто потеряете вопрос. 7. Задать вопрос подписчик может написав комментарий к этому посту с тегом #вопрос. 8. Если в комментарии не будет тегов, или если я не смогу ответить на наводящий вопрос “да” или “нет”, я буду удалять комментарий, чтобы не было флейма. #game

Кто такой Software Engineer (SWE) в FAANG? В прошлый раз я говорил о том, кто такой Product Manager в FAANG. И пока я писал этот пост, я осознал, что хоть я и написал много постов про уровни и обязанности Software Engineer, я так и не рассказал, кто такой этот Software Engineer. Исправляюсь! Напомню, что Product Manager -- это член команды, максимально компетентный в разработке требований для проектов. Аналогично, Software Engineer -- это член команды, максимально компетентный в создании программных систем. В этом месте читателю очень важно не забывать, о чем я писал в предыдущих постах. Не стоит, на основании этого определения, полагать, что SWE отвечает за написание кода, делегируя остальные части работы другим специалистам. Нет, SWE, как и все остальные роли, занимается вообще всем подряд. В частности, SWE очень часто занимаются разработкой требований для программных систем, которые они же и создают. Это случается при отсутствии в команде PM, или же просто если конкретный проект не достаточно сложный с точки зрения требований, чтобы привлекать особо квалифицированного эксперта по требованиям. SWE действительно самый большой специалист в написании кода. Но отвечает каждый SWE за разные вещи, в зависимости от его уровня. За что конкретно отвечает SWE каждого уровня, я описывал в статьях про уровни. И никогда это что-то -- просто код. Так как FAANG и остальной Big Tech чаще всего фокусируются на разработке программных продуктов, позиций Software Engineer в них абсолютное большинство.