Вы решили продать душу Тьюрингу и стать инженером программистом, не имея на то специального образования скажем MIT или любой другой известной школы computer science. Тут нет причин для волнений, более 20% профессиональных инженеров программистов не имеют даже степени бакалавра по опросам StackOverflow 2021 года. И как я уже рассказал в прошлом посте, начать с BigTech компаний может быть одной из простых и понятных опций. Что делать дальше? Ключевое момент принять ответственность за свое профессиональное развитие - свою карьеру. На это можно было бы закончить рассказ. Дальше я попытаюсь развернуть это утверждение, показать почему это так важно и проиллюстрировать на примерах.
Учение свет ?
Не будет большим сюрпризом заявить, что вам потребуются знания. Придется учиться и делать это постоянно. Индустрия растет и меняется с головокружительной скоростью. То, что было актуально и широко использовалось 4 года назад, сегодня объявляется устаревшим и при первой возможности активно переводится на новые технологии. Я пришел в Яндекс в декабре 2013, революционный стандарт C++ 11 тогда только появился и его обсуждали исключительно энтузиасты на кофе-пойнтах. К 2018 когда я покидал компанию, по-старому уже давно никто не писал, новые сотрудники, вчерашние выпускники, недоумевали как этот старый код можно читать и по ночам переписывали его. И это при том, что C++ находится в той части технологического стека, которая меняется значительно медленнее верхушки - пользовательских интерфейсов (Angular, ReactJS, and Vue.js).
При этом ошибочно полагаться, что компания или университет должны нас научить. Это наша цель, в первую очередь. Во-первых нас всегда легко можно заменить, за воротами стоят тысячи других соискателей. А корпорация при этом велика достаточна, чтобы не заметить подмены. Незаменимых людей не бывает. Это обратная сторона массовости отрасли. Если скорость роста сотрудника недостаточна, компания его заменяет. Такой минимальный уровень называют “первым терминальным” (first "terminal" level), в Meta это уровень E5 (или IC5). Идея проста, добиться высокой средней квалификации инженеров в компании и сделать их минимально зависимыми от старших товарищей. В наших прямых интересах учиться быстро чтобы не вылететь, а потом не упустить мотивацию и расти дальше. А во-вторых, корпорация обучая наемных инженеров преследует свои цели, не всегда совпадающие с нашими. Как я уже говорил в первой части, в большой компании у нас есть все ресурсы и возможности для обучения. Некоторые компании идут на невиданную щедрость и даже открывают свои школы. Например ШАД в Яндексе. Но важно помнить, что интерес в нас, как в специалистах у компании пропадает с нашим уходом. Нет никакого смысла обучать сотрудников для компании “через дорогу”. Нет никакого смысла заботиться, чтобы получаемые навыки могли быть повторно использованы. И тут для нас фокус в том, чтобы учиться для себя в первую очередь. Чтобы избежать чрезмерных инвестиций в технологии специфичные для конкретной компании и расширять свой кругозор с оглядкой на возможный уход в другую компанию “через дорогу”. Очень важен баланс, с одной стороны это шанс заглянуть внутрь уникальных технологий внутри корпорации недоступных больше нигде. С другой стороны тратить время на изучение, наример, проприетарного языка программирования не самое эффективное вложение нашего времени.
Уровень инженера
Как я уже упомянул выше, существуют формальные уровни инженеров, сквозные для всех специализаций. Эти уровни декларируют рост и развитие сотрудников, продвижение по карьерной лестнице. Между компаниями, шкалы разнятся, но среди крупных игроков они однозначно конвертируемы друг в друга. В сети можно найти массу информации об этом, например levels.fyi. Для каждого уровня есть формальный список ожиданий открытый для всех. Последние разнятся в деталях для специализаций, что понятно - сложно рассуждать в одних и тех же терминах о производительности UI инженера и reliability инженера. Суть ожиданий при этом для всех специализаций одна - чем инженер более независим от поддержки старших товарищей, чем больше доверия к нему, тем большего масштаба он решает задачи, тем выше его уровень и выше требования.
Уровень инженера может быть изменен, если сотрудник прогрессирует и в какой то момент, начинает удовлетворять ожиданиям не только своего уровня, но следующего вдобавок. Стабильная производительность на уровне следующей ступени это критерий повышения. Важный момент, есть ожидаемая скорость роста для младших сотрудников - важно чтобы они выросли за ограниченный промежуток времени до “терминальных уровней” на которых можно оставаться бесконечно долго. При недостаточно быстром прогрессе, им могут назначить ментора в помощь который составит понятный план действий. Если это не сработает, то таких сотрудников уволят.
Помимо скорости роста, поводом для увольнения может послужить недостаточная производительность, которая оценивается раз в квартал / полугодие / год - пресловутый “performance review”. Производительность оценивается согласно формальным “ожиданиям” от каждого уровня. Процедура оценки прозрачная, критерии общеизвестны. При оценке учитывается, то каких результатов лично вы добились, добились коллеги с вашей помощью, какие отзывы на вас написали коллеги и как вас видит и оценивает ваш непосредственный руководитель. При этом вы сами пишите отчет о результатах для менеджера, который он/она потом используют для калибровки вашей оценки относительно остальных сотрудников, дабы обеспечить некоторую справедливость распределения. Тот факт, что вы сами рефлексируете над результатами, крайне положительным образом сказывается на том, как вы потом планируете свое полугодие и как работаете. А значит у нас есть очень простой критерий оценки своей работы на каждый день - “то, что я делаю приближает меня к намеченной в плане цели?”, или “то, что я делаю я смогу использовать как бонус на ревью?”. Усилия которые вы затрачиваете в процессе не важны, важен результат - “impact”. Несмотря на всю очевидность, это было самое шокирующее, с чем я столкнулся. Никто не смотрит, как много ты пишешь кода, как часто ты задерживаешься после работы, как изящны и сложны твои решения. Это все не имеет значения до тех пор, пока намеченная изначально цель не выполнена. Подробно про это можно почитать в главе “Good enough software” The Pragmatic Programmer.
“Performance review” похоже на университетскую сессию, только смотрят за тобой все время, а не только на экзамене в конце. Если инженер удовлетворяет всем писаным ожиданиям, он получает стандартный бонус оговоренный в контракте (у каждого он свой и очень сильно зависит от уровня, в разы). Если превосходит ожидания - бонус увеличивается, иногда кратно(!). Если не удовлетворяет, получает бонус меньше или не получает вовсе. При этом 2 полугодия с такой оценкой приводят к санкциям в виде PIP (Performance Improvement Plan), такой план индивидуального спасения. При неэффективности реанимационных действий от “пациента” избавляются. Но до этого доходит исчезающе редко.
Компенсация ?
Размер компенсации зависит от формального уровня сотрудника. Это главный критерий для конвертации уровней между компаниями, сравнивать навыки сложно, деньги считать проще. Все крупные компании доверяют друг другу в определении уровня инженера, потому перепрыгнуть сразу несколько уровней при переходе в другую компанию не выйдет. Но правильно разыграв карты, можно ускорить получение следующего уровня при переходе в другую компанию, особенно когда вы уже ожидаете повышения, но ваш менеджер осторожничает.
Я избегаю использования термина зарплата здесь, так как последняя является только частью того, что вы получаете от компании. То есть компенсация складывается из 3 компонентов :
Базовая оплата или зарплата, это то что вы получаете на счет каждый месяц. Плюс бонусы несколько раз в год, в зависимости от результатов ревью. Интересный факт, здесь не принято считать размер зарплаты в месяц, всегда говорят о суммарном годом доходе. Связано это с налогами и декларацией которые вы сами подаете раз в год осенью.
Акции или точнее RSU. Это то, что выдается по результатам ревью в виде акций компании. Механизм меняется в зависимости от того, представлена ли акции компании на публичных торгах. Но принцип остается тем-же, в качестве вознаграждения за работу сотрудниками выдается маленькая часть компании стоимость которой зависит от успеха компании. То есть вы видите результаты своих трудов по оценке стоимости всем ваших акций. При этом выданные RSU нельзя сразу конвертировать в акции, есть стандартная процедура вестинга. Вестинг это когда RSU, но воспользоваться вы им ещё не можете, выдается оно равными порциями (1/16) каждый квартал на протяжении 4 лет. Давая вам мотивацию работать лучше, чтобы стоимость незавестившихся RSU быстрее росла. И мотивацию оставаться в компании дольше, чтобы не потерять незавершившиеся RSU - они сгорают после увольнения, как правило. О всех тонкостях компенсации в RSU я писать не буду, вы можете почить об этом например здесь или здесь.
Льготы (perks). Не самая крупная, но самая разнообразная часть. В нее входят пенсионные отчисления, медицинская и стоматологическая страховки, помощь с переездом, бесплатная еда в офисе, скидки на сервисы партнеров и еще много всего. Большая часть это мелочи, учитывать которые сложно, но крупные стороны такие как помощь с переездом или страховку стоит учитывать при выборе оффера.
Чем выше уровень сотрудника, там больше перевес в пользу акций. На уровнях Тех лида и выше, часть в стоках уже превышает базовую зарплате. Делается это по многим причинам, главная из которых это степень влияния на успех компании и масштаб последствий в случае успеха или ошибки. Чем выше уровень инженера, тем выше цена его ошибки для компании, все помнят сколько было историй с недоступностью крупных сервисов в 2021? Зеркален вклад от успехов, чем выше уровень, тем масштабнее проект, тем больше прибыли для компании он принесет в случае успеха. Публичный рынок акций крайне чувствителен к любым переменам: к запуску новых продуктов или ускорению старых, к большим периодам отключений или неосторожным комментариям для СМИ. Наличие и количество RSU очень мотивирует быть ответственным, как можно догадаться.
Размер компенсации может варьироваться в пределах некоторого диапазона для конкретного уровня, формально не разглашаемого компанией. Но, он определяется эмпирически, кооперацией сотрудников, которые деляться друг с другом информацией о себе. Где именно вы окажетесь - у верхнего ли края диапазона или у самого нижнего, зависит от торгов при заключении контракта. И это важный этап, про который мы чаще всего упускаем на старте карьеры или не умеем правильно разыграть свои карты. В контексте переговоров об условиях контракта стоит также упомянуть RSU которые дают сразу, чтобы перебить предложение другой компании. Я вернусь к этой теме, когда буду говорить о первых шагах.
Что учить
Самообразование и саморазвитие наша ответственность. Значит нам нужен план, без целей краткосрочных и долгосрочных, обучение рискует оказаться неэффективным, недостаточно быстрым или вовсе бесполезным. В университетском образовании, скажем, план составлен и перепроверен умными людьми. Хорошая новость в том, что находясь среди множества себе подобных близко к “станку” мы можем отслеживать пробелы в своем образовании и восполнять их, работая на краткосрочные цели. С большими долгосрочными целями нужна помощь извне, и самый эффективный путь - найти себе ментора. В BigTech работают блестящие умы самых разных профилей, будучи внутри у вас будет доступ к ним. Помогать людям вокруг расти прямое ожидание от опытных инженеров, так что помогать вам они станут не только и столько по доброте душевной. Не стесняйтесь им написать, это очень важно. Это одна из ошибок которую я сам совершил несколько раз - недооценив себя и не отправив письмо с вопросом. Разумеется к рок-звездам выстраиваются очереди желающих, у них может не хватить времени на всех. Но часто оказывается так, что они сами ищут кому бы помочь ?♂️, не упустите свой шанс! Разумеется ментора можно найти и за пределами корпораций, в этом случае несколько сложнее с мотивацией для старшего товарища вас обучать. Тут могут помочь друзья которые несколько опытнее вас. Так же не стоит недооценивать добрую волю и энтузиазм, такую помощь можно найти в разнообразных интернет сообществах и форумах.
Для определения своих целей сегодня я использую подход “knowledge portfolio” предложенный в книге The Pragmatic Programmer. Кратко, это прямая аналогия с “финансовыми активами”, например акциями компаний. Весьма полезно держать в своем активе акции бурно растущей “Tesla”, в случае успеха вас ждет десятикратный рост стоимости всего за два года. Так же и со знаниями, скажем языки программирования - полезно изучать быстро набирающий популярность Rust и Kotlin. Есть шанс, что популярность их будет быстро расти и вы окажетесь одним из первых, кто начнет на них писать. Помимо этого можно и нужно перенимать свежие идеи из новых технологий. Лучший способ творчества, как известно - заимствование. Не помешает разбавить ваши активы и стабильными “акциями” - фундаментальными алгоритмами и языками широко используемыми сегодня: C++/ JavaScript/ Python. На них уже написано столько кода, они точно останутся с нами в обозримом будущем. Это же касается разумеется любых технологий от алгоритмов до распределенных фреймворков и способов управления проектами. Здесь очень важно не ограничиваться рамками одного источника, читать книги, смотреть лекции на YouTube, читать статьи. Например ежегодный анализ рынка на основе опроса пользователей сайта StackOverflow. Я крайне рекомендую прочитать целиком главу 5 “Your knowledge portfolio”, чтобы узнать принципы создания и поддержания такого портфолио с массой практических рекомендаций.
Engineer ≠ developer
Пополнение портфолио знаний играет важную роль в становлении вас как инженера, это не только возможность добавить строчку в CV, но и расширяет ваш профессиональный кругозор. В этом, как я это вижу, прослеживается разница между “software developer” и “software engineer”, позиция последнего очень требовательна к широте кругозора. Инженер занимается полным циклом работы над “проектом”, начиная от определения решаемой проблемы. Инженер всегда работает с людьми вокруг, как в генерации решений, так и в его реализации. Инженер должен работать с потенциальным заказчиком, только частично перекладывая эти обязанности на специальных людей в особо крупных проектах. Написать код, просто удовлетворяющий заданным требованиям, задача самых младших членов команды и только в первые месяцы работы. Это тот недолгий период который можно описать термином “software developer”, как я это вижу. Уже через полгода от вчерашних новичков ожидается больше самостоятельности и движения в сторону “инженера”. В сторону планирования, принятие ответственности, оценку рисков и рефлексии над результатами. Поэтому я всегда поправляю, я инженер, не девелопер.
В этой части я попытался раскрыть про рост внутри корпорации и про то, как крупные компании в этом помогают. Про формализацию уровня инженера и как это влияют на размер компенсации. В следующей части я расскаже про 3 возможных исхода проекта, риски проекта, не-инженерную часть работы и code review.
Если у вас есть вопросы, замечания или пожелания, пожалуйста дайте мне знать в комментариях или любым другим способом. Было бы полезно понимать насколько заметки полезны, что я упускаю, согласны ли вы со сказанным.
