Карьера в FAANG

В прошлом посте я начал говорить об ожидаемом содержании performance review документа и поговорил о необходимости подтверждающих заявления артефактов. Сегодня же я хочу поговорить о том, как правильно делать эти заявления.

Инструмент 4: ladder description

В бигтех компаниях уровни (#level) более или менее точно описаны. Где-то есть официальный ladder документ на всю компанию, где-то с локальной спецификой организации, где-то он вообще может передаваться устно. Но независимо от формы, содержание описания уровней существует и понятно старожилам. Такие документы могут быть написаны непонятным корпоративным языком, но это не значит, что они бесполезны. Просто их нужно уметь читать, с чем я помогаю в этом канале. Понимание этого документа -- самый главный ассет сотрудника, желающего расти в бигтехе.

К каждому заявлению в perf документе возникает вопрос: "чем докажешь?", на который отвечают ссылки на артефакты. После него возникает второй вопрос: "и что?". Кандидат снизил latency сервиса вчетверо? И что? Увеличил прибыль на $XXX/год? И что? Запустил сложное изменение? И что? Каждому сотруднику за его работу платят зарплату. Почему вся вышеперечисленная работа должна быть вознаграждена дополнительно? На этот вопрос отвечают ссылки на ladder документ. Сложное изменение требовало leadership, чтобы организовать и синхронизировать работу нескольких команд? В ladder документе написано, что такой организацией занимается Senior. Значительно снизить latency безуспешно пыталось много квалифицированных людей в течении долгого времени? В ladder написано, что Staff решает проблемы, которые не может решить большинство коллег. $XXX -- число, заметное на уровне VP? В ладдере написано, что Senior Staff приносит масштабный импакт.

Отсюда вытекает самое важное правило при написании perf пакета: пишите perf цитатами из ladder документа (или цитатами руководителей об уровнях, если документ отсутствует).

При чтении этих цитат, ни мнение кандидата о работе, ни его же мнение об его уровне / оценке, не оставляют сомнений. Если вы пишите о себе цитатами из Senior уровня, очевидно, вы намекаете на повышение до Senior. Ревьюеры могут не соглашаться с вашей оценкой работы, но по крайней мере они совершенно точно поймут эту вашу оценку и не запутаются в том, что происходит в вашем пакете. Было бы обидно описать крутой проект, только чтобы ревьюеры прочитали ваше описание, похлопали вам, и сказали, какой же классный вы инженер на вашем уровне, вместо того, чтобы увидеть сигналы на следующий уровень, не правда ли? Помимо всего прочего, старшие коллеги, которые занимаются ревью perf пакетов, затерли ladder документ до дыр, и вы сделаете оценку вашего пакета на порядок проще и быстрее, если не будете придумывать свои формулировки, а вставите стандартные и уже знакомые ревьюерам.

#perf

Зачем топовые инженеры работают в корпорациях?

Я много писал про уровни в бигтех компаниях (#level). Список навыков, требуемых от этих уровней варьируется от "быстро учиться сложным вещам" до "трансформировать индустрию". Меня часто спрашивают, а почему же такие крутые люди работают на корпорации, когда уже Senior инженер умеет самостоятельно достигать бизнес-целей. Чего же все эти люди не основывают свои компании и сказочно богатеют? Поговорим, почему так происходит.

Причина номер один: дай мне достаточно большой рычаг и я переверну мир.

Топовые инженеры работают на корпорацию. Но и корпорация работает на них! Присоединиться к бигтех компании означает получить доступ к гигантскому масштабу. Да, работать сложнее, но зато, когда вы разработали продукт, то им пользуется несколько миллиардов человек еженедельно. Получив такой большой рычаг, топовый инженер может менять мир гораздо быстрее и сильнее, чем в 99.9% случаев основания своей компании. Знать, что результатом твоих трудов пользуются миллиарды людей, сильно повышает мотивацию и качество жизни.

Причина номер два: фокус.

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

Причина номер три: люди.

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

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

Инструмент 3: артефакты

Большинство пакетов при чтении вызывает мысль: ууух, понаписал-то! Каждый норовит описать себя супергероем. Настоящего супергероя же отличает одна критически важная деталь -- пруфы. Каждый факт нужно подтверждать таким пруфом, которые еще называют артефактами. Имплементировал фичу? Прикрепи PR. Придумал дизайн? Прикрепи дизайн документ. Пишешь, что фича была важна? Прикрепи оживленные дискуссии. Пишешь, что поднял метрики? Прикрепи графики (а еще лучше ссылки на систему мониторинга). Пишешь, что починил критический баг? Прикрепи пользовательские жалобы. Вся информация, которая не подкреплена артефактами, считается hearsay, и, в теории, не учитывается при принятии решения. На практике же, сбор пруфов ляжет на плечи вашего менеджера, причем в кратчайшие сроки, пока заседают комитеты. Стоит ли удивляться, что он плохо справится с этой задачей.

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

Собрать артефакты -- простая часть. Вот вы своим улучшением серверного фреймворка уменьшили p90 latency на 10% на всех серверных приложениях вашей команды. Сделали скриншоты метрик latency "до" и "после", красиво показав снижение в момент деплоя вашего изменения. Сделали еще скриншот долгосрочной стабильности новых значений в течении недели. И уже потираете руки, как вас отблагодарят за это бонусом! Однако, рано радоваться. Да, вы собрали артефакты, подтверждающие ваше заявление об улучшении. Но вы не собрали самого главного артефакта, который дает ответ на вопрос: и чо?

Невозможно отрицать, что снижение p90 latency на 10% -- это улучшение. Но есть не менее важный второй вопрос: а насколько это лучше? Если вы разрабатываете рекламную платформу с 1M QPS, то это революционная технология. А если batch сервис, который вызывается раз в неделю, то это эквивалент сэкономленных пяти центов в год. Вторая половина артефактов должна подтвердить, что ваши улучшения действительно полезны, и насколько. Как это сделать? Пока не изобретен объективный прибор, измеряющий пользу, для этого мы пользуемся коллективным мнением более опытных коллег. Иначе говоря, пользу подтверждает артефакт под названием peer feedback. Вы просите коллег, которые считаются экспертами в том деле, в котором вы считаете, что принесли пользу, подтвердить и квантифицировать эту пользу. Да-да, комментарии от коллег собираются исключительно для решения этой задачи. Написание коллегами хвалебных поэм кандидату совершенно бесполезно, и игнорируется при принятии решений. В фидбэке должно быть написано: "признанный эксперт X в домене Y подтвердил, что достигнутый кандидатом результат Z в домене Y действительно важен и сложен на уровень L".

Итого, кандидат должен предоставить артефакты, подтверждающие достижение результата; коллега-эксперт должен предоставить артефакт (peer feedback), подтверждающий ценность и сложность этого результата, а также вклад кандидата в этот результат. Менеджер кандидата же должен всех напрячь, и убедиться, что на все эти вопросы есть нужные ответы.

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

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

Инструмент 1: структура

- Писать тексты сложно
- Писать тексты, понятные другим людям, еще сложнее
- Вместо текста, можно писать структурно:
- Составлять списки фактов (например: запустил фичу X, померял Y% DAU increase MoM)
- Использовать буллеты
- Перечислять факты
- Группировать факты
- Сопровождать факты дополнительным контекстом
- Типичный перф-пакет состоит из:
- Списка проектов
- Для каждого проекта:
- Краткого описания
- Списка фактов о принесенной проектом пользе
- Списка фактов о сделанных действиях
- Артефактов (о них ниже)
- Иногда, пояснений некоторых неочевидных фактов
- Минусы этого подхода:
- Получится большая простыня буллетов, которую:
- Долго читать
- Приходится суммаризировать в голове, для построения полной картины
- Выглядит очень длинно
- Тяжело использовать на L6+ уровнях, так как сложно передать когерентную историю
- Плюсы:
- Максимально просто писать: перечисляешь себе факты, и все
- Максимально просто редактировать: буллеты легко двигать и выделять в группы
- Все-таки легко читать: принимающие решения люди могут:
- Сканировать список
- Прикидывать независимое решение по каждому факту
- Считать что-то вроде среднего/минимума в конце для финальной оценки

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

Инструмент 2: стиль языка

Помимо структуры, сам стиль используемого тоже должен быть специализирован. Лучшая практика -- уложиться в 1000 слов. Это нужно не только для экономии время читающим, хотя это тоже важно. Но главным образом, форсированная краткость позволяет сфокусироваться на самом главном, и отбросить ненужное. Это самое ненужное вполне может испортить о вас впечатлении: да, вы сделали 2 проекта на L5 и вроде готовы к повышению, но почему в пакете еще 5 проектов на L4? Не были ли эти L5 проекты удачей, если кандидат в основном работает работу L4? Краткость -- ваш друг.

Дополнительно к общему принципу сухого и краткого изложения, есть еще конкретные эвристики. Например, удалите из вашего текста все прилагательные. Прилагательные (обычно, позитивные) -- это просто пустая хвальба себя. В вашем тексте их быть не должно. Вместо каждого прилагательного должен быть приложен артефакт. Сделали "сложную" систему? Удалите. Вместо этого приложите дизайн документ, в котором описана сложная система. Работали в "кросс-функциональной" команде? Удалите. Вместо этого, приложите список ключевых людей из разных функций и попросите их подтвердить работу с вами в фидбэке.

Используя эти базовые инструменты, вы превратите свои пакеты из "praising word soup" в адекватный и полный документ о достижениях, по которому можно понять, кто вы такой и что вы умеете делать. В следующем посте я расскажу про более продвинутый инструмент, который поднимет уровень вашего пакета до ~80% качества.

Вышел подкаст со мной. Поговорили о техническом лидерстве, карьере в FAANG, и создании стартапов. Получилось душевно!

https://youtu.be/7XPyBonXG9s?si=KwtQOzD0AcgBSsQk

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

В комментариях под прошлым постом было бурное обсуждение на тему проблем с перфом. Была упомянута реальная проблема: stack ranking (она же curve fitting, она же бюджетирование). Я не считаю это проблемой именно перфа, потому, что не считаю ее частью перфа. Это отдельная, независимая система, приделанная сбоку, уже значительно позже разработки самого процесса перфа. Было недовольство мотивацией (a.k.a. promo-driven development). По нему моя позиция, что это не баг, а фича. Финансовое давление помогает фокусироваться на важном и игнорировать неважное. Ну и было много ругани на менеджеров, чего я совсем не понимаю, ведь они меньше всех влияют на результат. А теперь поговорим о главном наблюдении очень старших инженеров в тех гигантах.

Главная проблема перфа -- он очень сложный. Это была идеальная система во времена духа Bell Labs или раннего/среднего Google. Но за последние 10 лет Big Tech вырос с десятков тысяч до нескольких сотен тысяч человек. Очевидно, это не могло произойти без понижения планки качества нанятых людей. Ну и конечно, пик снижения планки мы все наблюдали в ковид. Чем дальше, тем больше становилось компромиссов по скиллам кандидатов. И если технические знания поддерживать проще, то очень тяжело держать планку по скиллу рефлексировать о своей собственной работе, детально разбирать каждое свое действие, и описывать их в хорошо оформленном и понятном случайному инженеру из другого угла компании. В итоге, на это просто забили, и решили, что фиг с ним, там научатся. Ну или не научатся, и уйдут сами. Если читателю кажется, что этот мой вывод звучит очень снобско, мол понанимали средненьких новобранцев, то я смею заверить этого читателя, что на входе в бигтех я сам не обладал этим скиллом, и кто знает, наняли ли бы меня самого без этого компромисса. К счастью, я смог довольно быстро научиться: я был хорошим джуном. Но проблема остается проблемой. Писать perf -- это очень сложная работа, которая каждый раз сопровождается месяцем нытья на внутренних форумах компаний. В результате производится гигантский объем низкокачественной писанины, что создает кучу работы и для написания peer review, и для менеджеров, и для комитетов. Эта работа выглядит неэффективно, вынуждая старших экзекутивов давить на менеджеров, чтобы они брали на себя часть ответственности. Это приводит к тому, что люди так и не научатся этому скиллу, а планка снижается еще сильнее. В итоге мы видим спираль, которая раскручивается прямиком на дно.

Я не смогу научить читателя писать крутой и легкий перф. Этого можно достичь только упорной самостоятельной работой. Но я смогу помочь читателю сделать первые шаги и помочь перейти из режима "я не знаю, что тут писать" в режим "могу написать хороший перф, а теперь надо научится писать идеальный". И начну я с нескольких простых инструментов, которые решают 80% проблемы. В следующей серии.

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

Итак, в Big Tech компаниях существует процесс под названием performance review. Каждый сотрудник хочет бонус побольше. Большинство сотрудников хотят повышения позиции. Чтобы жизнь организации не превратилась в хаос все время клянчущих денег сотрудников, эти естественные желания официально признаны, и организованы в стандартизированный процесс, который и назвали performance review, или, в простонародье, perf (перф). Прежде чем обсуждать суть дела, быстро про форму:

- Заранее готовится сетка требований для уровней, о которой я много писал
- 1-2 раза в год в фиксированные даты объявляется perf
- Каждый сотрудник пишет документ, который называется self assessment. В этом документе сотрудник описывает, что он полезного сделал для мира и компании, что у него получилось особенно хорошо, а где он в себе обнаружил слабые стороны
- Сотрудник так же просит коллег, с которыми работал, написать ему "peer feedback" -- то же самое, что и self assessment, только вкратце и с точки зрения коллеги
- Сотрудник сам пишет peer feedback для коллег
- Лиды организации собираются в calibration committee и обсуждают все self assessment документы, анализируют и соглашаются (или нет) с тезисами
- Дальше идет процесс stack ranking, который изобрел лично дьявол, поэтому я про него тут писать не буду (а еще потому, что о нем бесполезно писать, все равно кандидат ничего не может сделать, чтобы на него повлиять)
- В результате обсуждения self assessment документов сотруднику назначается "рейтинг"
- От рейтинга напрямую и значительно зависит годовой бонус -- можно заработать вплоть до x1.5 от ожидаемого

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

- Self assessment документ становится больше / полнее / сложнее написать, ведь нужны дополнительные доказательства для новой аудитории читателей
- Дополнительно к calibration committee собирается promo committee, обычно из более старших коллег (а в Гугле раньше еще и из случайных коллег со всего Гугла)
- Второй комитет решает, одобрить ли номинирование сотрудника или нет
- Senior leaders (обычно VP) подписывают одобренные номинации, делая повышение официальным

Такова форма, а в чем же суть? Суть процесса в том, чтобы главным по процессу получения бонусов и повышений был самый заинтересованный в них человек -- сам сотрудник. Именно он сам для себя изучает ладдер, весь год выбирает правильную работу, которая ему поможет на перфе, сам собирает все нужные доказательства, сам составляет self assessment -- презентацию своих аргументов, сам анализирует, что нужно изменить в работе в следующий цикл, чтобы в следующий раз составить еще более впечатляющий документ, который приведет к еще большим бонусам. Кандидат больше всех заинтересован в финансовом вознаграждении, а значит никто больше не сможет так хорошо доказать, что он его достоин. Такой процесс убирает гигатонны микроменеджмента, назначения задач, слежки, кто что сделал. Ведь perf рассудит.

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

#perf

All your packets are awful.

Так называется внутренний документ, написанный одним из опытных членов промо комитетов в Гугле. И я не смог бы придумать лучшего названия: подавляющее большинство промо пакетов, а также self-assessment документов на performance review просто ужасны.

Предполагается, что кандидат пишет про свою работу с целью дать старшим коллегам всю необходимою информацию, чтобы они смогли защитить заявку кандидата на повышение (промо пакет) или на высокий рейтинг (обычный self-assessment). Стоит ли говорить, что большинство этих документов не достигают поставленной цели. При их чтении возникает стойкое ощущение, что кандидат даже не знал, что такая цель существует, чего только там не пишут. Это приводит не только к отказам кандидатам в повышениях и рейтингах, но и к выгоранию коллег, чья работа -- читать эти документы. Быть обязанным тщательно изучить и дать детальный фидбэк по потоку нерелевантного текста -- совершенно неприятная работа, особенно когда ты взял на себя ее делать из мотивации помогать классным людям.

Ну и конечно, плохо составленный документ снижает шансы самого кандидата на на желанное повышение или высокий рейтинг. Чтобы спасти ваши бонусы, я решил написать серию постов про performance review. В этой серии я расскажу, что такое performance review, как правильно писать self-assessment и promo packet, как правильно просить и давать peer feedback. Эти инструкции помогут вам "думать как промо комитет", делать их работу проще и приятней, и соответственно улучшать их настроение. Не важно, состоит ли промо комитет из случайных старших коллег, которые вас не знают, или из лидов вашей организации. Они все думают примерно одинаково, и эта серия поможет вам "хакнуть" одну из компонент процесса роста в Big Tech компании.

#perf

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

Многие люди на интуитивном уровне думают, что повышение уровня -- это вознаграждение за хорошую работу. Это заблуждение. Вознаграждение -- это нечто одностороннее. А повышение уровня -- это двусторонний "контракт" между работником и компанией. И я не имею в виду буквальный переподписанный контракт на новую ЗП. Я говорю о неформальном контракте. Все понимают, что при повышении сотрудник обязуется выполнять работу на следующем уровне. Но мало кто знает, что этот контракт двусторонний -- компания обязуется дать сотруднику свободу работать на этом следующем уровне.

Что это значит -- дать свободу работать? У этого обязательства есть две части: формальная и неформальная. Формальная часть заключается буквально в том, что с вами нельзя работать, как с сотрудником предыдущего уровня. Разберем на примере: главная разница между Junior и Middle уровнями -- способность самостоятельно выполнять задачи. Когда сотрудник на Junior уровне доказывает эту свою способность, ему предлагают повышение до Middle позиции, где он уже обязуется продолжать консистентно выполнять сложные задачи самостоятельно. Но одновременно с этим компания (в лице менеджера, техлида, коллег) так же обязуется уважать эту способность сотрудника и не лезть к нему с попытками смотреть на его работу из за спины, требовать частых чек-инов, пытаться вести его за руку через сложности. Вся та помощь, которая была очень полезна Junior инженеру, чтобы быстро учиться, превращается в препятствие, только мешающее работе Middle инженера. И компания обязуется устранить это препятствие, что повышает его эффективность, и сильно упрощает его жизнь.

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

И формальное и неформальное обещание компании дать вам свободу работать на вашем уровне -- это серьезная проблема для компании в целом, а так же для вашего руководителя и команды, в том случае, если эту свободу дали вам по ошибке. Это еще один фактор, почему повышения в FAANG так сложны. Нужно серьезно доказать, что когда кандидат получит новую свободу, он не растеряется и не провалит новые задачи.

#promo

В этом канале я рассказываю про FAANG и похожие Big Tech компании. Но мир на них не заканчивается. В мире есть большое разнообразие компаний, подходов и индустрий. Меня часто спрашивают, как получить релевантный опыт для попадания в FAANG, работая в совершенно другой среде? На этот вопрос нет единого ответа. Но есть принцип, который работает всегда: чтобы старшие коллеги делились с вами информацией, скоупом и свободой самовыражения, нужно хорошо разобраться в вашем окружении, понять его правила и нужды людей. Мне сложно с этим помочь в широком мире, так как мой опыт в основном происходит из Big Tech компаний. К счастью, я не один рассказываю, как устроен IT-мир. Хочу поделиться папкой с каналами про разработку, менеджмент и тимлидство. Несколько из них я сам читаю! Мои коллеги по образовательной деятельности пишут на самые разные рабочие темы, и у каждого есть хороший шанс найти информацию про среду, похожую на вашу, которая поможет вам разобраться, как найти возможности и получить опыт для желанного развития вашей карьеры.

Рассказал на Подлодке о карьере в FAANG -- теме этого канала.

На такую тему сложно читать лекции, слишком много нюансов и ситуаций. Потому, я постарался рассказать об общих принципах. А вместо разбора всех возможным гипотетических сценариев, я предлагаю всем советую задать вопросы в комментариях тут в канале или на Ютубе. И мы устроим стрим, где меня можно будет закидать вопросами вживую.

https://t.me/podlodka/94291

Всем привет!

Скоро я буду записывать подкаст с Podlodka про карьеру в 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 позицию очень просто: кандидату нужно показать, что он трансформировал технологическую индустрию, связанную с бизнесом компании. Нет смысла вдаваться в детали: если вы трансформировали индустрию, это будет очевидно всем.

#level

Как Твиттер сократил 80% работников и выжил?

Интернет полон мнений на эту тему, которые в основном расположены на шкале от "Твиттер живет на инерции и постепенно разваливается", до "80% сотрудников (и программных систем) не делали ничего полезного".

В этом посте я предлагаю выпрыгнуть с этой линейной шкалы в плоскость и посмотреть на этот вопрос с другого угла.

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

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

С высоты 11 лет опыта работы в публичных технологических рекламных гигантах, я оцениваю работу, которая обеспечивает публичность и рекламность в как минимум 90% от всей работы. Так что Твиттер по моей оценке даже недожал, возможно, как раз из за необходимости поддерживать или чистить легаси софт. Во-первых, публичные компании требуют огромного пласта аналитики. Код продуктов пронизывает инструментарий для сбора и организации данных. Для их хранения, организации, анализа создаются внутренние технологические продукты, и целые организации инженеров, их разрабатывающие. Создаются целые организации инженеров по аналитике этих данных. Большие организации финансистов, которые обеспечивают уже не продукты компании, а публичный образ компании для инвесторов, основанный на данных. Создаются организации PR-щиков для создания публичного образа для обычных людей, так как этот образ тоже отражается на биржевых показателях.

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

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

Старый Твиттер делал все правильно для своей бизнес-модели. И новый делает правильно для своей.

https://t.me/podlodkanews/1313

Через 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.

#role

Что такое 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 я и выбрал рассказывать.

Какие еще компании, которые подходят под это определение, предлагайте в комментариях?

Что такое собеседование?

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

Очень распространен миф, что собеседование -- это что-то вроде экзамена. И действительно, по некоторым признакам выглядит похоже, особенно если не вдаваться в детали. Но нет, это не экзамен:

- Экзамен односторонен (собеседование двусторонне)
- На экзамене есть правильный ответ (на собеседовании нет)
- На экзамене проверяются знания (на собеседовании, в основном, подход к работе)

Так как собеседование -- вообще не экзамен, подход к нему как к экзамену обречен на провал, ну или уж по крайней мере на существенно сниженный результат. Окей, что же такое это ваше собеседование?

Собеседование -- это дистилляция симуляции работы.

В этом месте многие сотрудники FAANG+ компаний возразят, мол какая еще симуляция работы, на работе мы ни разу не обращали бинарное дерево! Действительно, не обращали. Именно поэтому я и сказал "дистилляция". В собеседование компания выделяет все действительно важные аспекты рабочего процесса, игнорируя неважные (по мнению лидеров этой компании).

В примере с Leetcode-собеседованием для SWE эти важные части такие:

1. Умение объяснять вычислительной машине, что вы хотите, чтобы она вычислила (в простонародьи -- кодить)
2. Умение, столкнувшись со сложной задачей, ее решать (заметьте, не решить, а решать -- двигаться в сторону решения, даже если до него не получилось дойти)
3. Больше деталей можно узнать из цикла про Leetcode собеседования

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

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

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

В прошлом посте я рассказал о своем L3->L4 SWE промо в Google. А еще я пригласил коллег поучаствовать и тоже рассказать о своих промо.

Чтобы привлечь больше классных людей к этой затее, я сделал пост в LinkedIn. Если вам понравилась идея и вы хотите услышать больше историй, распространите его в своей сети!

#link