Карьера в FAANG

Расскажите о своих сильных и слабых сторонах? Part II.

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

Каждая сильная сторона -- одновременно и слабая.

Что? Как это так, это же антонимы? А вот так. Вообще-то, нас всех этому учили еще с детского сада: быть камнем -- сильная сторона, когда перед тобой ножницы, но слабая, когда перед тобой бумага. Пример сильной стороны из прошлого поста -- “я хорош в работе, где непонятно что делать”, становится слабой стороной в другой ситуации -- “я теряю интерес, когда все понятно; большой объем понятной работы я сделаю медленно”. Альтернативно, может быть вы можете писать тысячи строк продакшен кода в неделю, чтобы быстро запускать новые продукты? Вероятно, это также значит, что вы не можете пол года смотреть на графики и медленно тюнить десять строк конфига формулы ранжирования. Что, можете? Тогда, скорее всего, вы не можете спокойно ждать, когда команда напишет этот код в три раза медленнее, что ее разовьет.

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

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

Расскажите о своих сильных и слабых сторонах? Part I.

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

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

Что же хотят услышать нанимающие?

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

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

От вас ждут ответ про вас. Не нужно говорить общие фразы, которые может сказать любой кандидат. “Я хорошо работаю” добавляет ноль бит информации в ваш кейс и никак не помогает менеджеру понять, как вас встроить в команду. Ответ должен быть специфичен лично для вас. Например, “я хорош в работе, где непонятно что делать”. Если у менеджера как раз есть проблема, где никто ничего не понимает, он будет рад вас видеть в команде и похлопочет за вас о хорошем оффере.

От вас ждут разнообразия. Не бывает, чтобы у человека была одна сильная сторона, или не было слабых. Они всегда есть. Демонстрация себя с разных сторон не только дает больше информации менеджеру, но и показывает, что кандидат self aware, что ценно само по себе.

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

Вышло видео с Димой Senior Software Vlogger по моей серии performance review. Немного пересказываю серию постов, но дополнительно мы отлично обсудили множество связанных вопросов. Получилось хорошо!

https://www.youtube.com/watch?v=POmPyB11LiQ

#perf

Завтра стрим в 21:00 мск!

Разберемся как стать из простого инженера ЭЙ-АЙ инженером

Жмите Notify чтобы не пропустить

В гостях
Макс @faang_career
Майк @pixels_science

https://youtube.com/live/pLg89I1jabY?feature=share

Я рассказал, как писать половину performance review -- self assessment документ. В этом, завершающем цикл, посте поговорим о том, как писать вторую половину -- peer feedback.

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

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

В недавнем посте я писал про артефакты, как один из важнейших инструментов написания качественного perf документа. Так вот, вы, автор фидбэка, и есть источник самого главного артефакта. От вас требуется подтвердить заявления автора, которые он не смог подтвердить сам. Допустим, автор снизил p50 latency на 30%. Он может это доказать, приложив ссылку на мониторинг. Но он не может доказать, что это вообще было нужно делать. Поэтому, он просто заявляет, что это улучшило UX. А вы, старший UX дизайнер, подтверждаете это заявление. Если подтверждений нет совсем, надо их подтвердить. Если уже есть артефакты (например, снижение time to first byte), надо их контекстуализировать своим экспертным мнением: я, UX дизайнер шестого уровня, подтверждаю своим авторитетом, что снижение time to first byte доказано положительно влияет на долгосрочные бизнес метрики.

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

Автор фидбэка, запомни: ты -- артефакт.

Разумеется, к фидбэку так же применимы и правила написания самого документа -- максимально цитировать ладдер и быть структурным.

Стрим завтра, 8 мая 20:00 мск

Разбираемся в разнице систем дизайн интервью в корпорации и стартапе

В гостях Макс C и Дима К

https://youtube.com/live/pZBve6IJ3WI?feature=share

Привет! Сегодня стрим в 21:15 мск

Разбираем мок систем дизайн интервью

В гостях
Max Strakhov @faang_career
Dima Korolev @SysDesignMeetup

Кликайте Notify Me чтобы не пропустить

https://youtube.com/live/OLksql9yEG0?feature=share

В прошлом посте я начал говорить об ожидаемом содержании 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