Оглавление

• Мой карьерный путь

• Что мне стоило начать делать раньше

  • Вести рабочий журнал

  • Выходить из зоны комфорта

  • Интересоваться другими командами и проектами

  • Присоединиться к on-call команде

  • Сменить команду

  • Писать статьи

• Что я хотел бы сделать по-другому, вернись я в прошлое

  • Быть более осторожным, производя глобальные изменения

  • Не позволять эмоциям брать верх перед командой

  • Время от времени мониторить рынок труда

• Заключение

Привет!

Меня зовут Бенуа, я работаю разработчиком программного обеспечения последние 8 лет. В своей предыдущей (и первой) компании я проработал 7,5 лет, а в начале 2022 года перешел в новую.

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

То, чем я здесь делюсь, может быть полезно любому Junior или Middle разработчику, который хочет совершенствоваться и продвигаться к уровню Senior и выше. Советы в этой статье по большей части касаются так называемых мягких навыков, по техническим навыкам я пройдусь отдельно во второй части.

Мой карьерный путь

Прежде чем перейти к основной теме, расскажу кратко об эволюции моей карьеры:

1. В начале я стажировался три месяца в быстрорастущем стартапе.

2. После этого проработал целый год по программе Work&Study, в рамках которой 3 месяца учился, а 9 месяцев работал.

3. Затем я устроился на постоянную работу в качестве Software Engineer и проработал в этой должности 3,5 года.

4. Вскоре после введения системы грейдирования меня повысили до Senior Software Engineer. Я сохранял этот грейд в течение трех лет, пока не ушел из компании, и в это время штат технических специалистов насчитывал около 200 человек.

5. И наконец, я пришел на должность Software Engineer в компанию с тысячами технических специалистов. Несмотря на понижение в грейде (см. Big Tech Hiring is Conservative — But Why?), я старался сохранить те же функциональные обязанности, что и раньше.

В самом начале я был частью фронтенд-команды. Разработка была разделена на бэкенд и фронтенд-разработчиков. В то время нас было около 30 инженеров. Когда через год пришел новый технический директор, он ввел организацию, основанную на feature-teams: модель Spotify. И хотя вначале были некоторые трения (люди не любят перемен), эта реорганизация определенно была к лучшему.

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

Что мне стоило начать делать раньше

Вести рабочий журнал

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

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

Почему рабочий журнал важен? По двум причинам:

• Чтобы напомнить себе обо всем, что вы сделали за последние полгода-год. Это очень важно во время performance reviews, чтобы показать руководителю, чего вы добились и почему заслуживаете увеличения зарплаты или перехода на грейд выше.

• Отслеживать проекты, заметные обязанности и критические показатели (например, снижение задержки на X % для критически важного сервиса). Это очень поможет при составлении резюме, когда вы захотите выйти на рынок труда.

Я начал вести рабочий журнал примерно за два года до ухода из первой компании. Таким образом, за последние 8,5 лет мой рабочий журнал содержит данные только за три года (с некоторыми пробелами). Когда в конце 2021 года я составлял резюме, мне пришлось полагаться на память, чтобы вспомнить, чем я занимался в первые пять лет своей карьеры. Мне потребовалось много времени, чтобы вспомнить все ценное, и я уверен, что что-то забыл.

При желании вы можете использовать шаблон рабочего журнала (вот пример). Лично я первые два года использовал Microsoft Notes, а затем перешел на Google Docs.

Выходить из зоны комфорта

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

Но почему я советую покинуть это прекрасное место? Потому что эта среда не подходит для значительного развития.

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

Как только вы достигли зоны комфорта в конкретной теме, следует:

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

• Искать что-то новое, выходящее за пределы вашей зоны комфорта.

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

Что касается новых дел, то это может быть что угодно. Вот список для вдохновения:

• Принять участие в проекте, к которому раньше у вас не было возможности прикоснуться, например, потому что он всегда поручался одному и тому же человеку (который находился в своей зоне комфорта).

• Написать документацию по теме, которая вам близка. Цель — поделиться своими знаниями и косвенно наставлять людей, чтобы они могли получить эти знания быстрее, чем вы. Кроме того, умение писать — это полезный навык, которому стоит учиться, будь то документация, письма, сообщения, RFC (Requests For Comments), статьи для блога и т.д.

• Добровольно участвовать в кросс-командных проектах. Вы даже можете занять в них лидерскую позицию, чем убьете двух зайцев.

• Заняться улучшением инструментария, мониторинга или процессов в команде или организации.

• Участвовать во встречах, организуемых компанией.

• Вступать в сообщества компании, чтобы работать над проектами на более высоком и кросс-командном уровне.

• Помогать команде в подборе персонала, проводя технические собеседования и/или проверяя тестовые задания кандидатов.

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

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

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

Интересоваться другими командами и проектами

Этот пункт близок к предыдущему, хотя вам и не обязательно брать на себя дополнительную ответственность.

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

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

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

• Стал лучше понимать, что может быть причиной, когда что-то идет не так.

• Начал понимать, почему нам нужен именно этот сервис или почему мы выбрали именно это хранилище данных.

• Наконец-то собрав все воедино, после многих лет работы на благо компании, я испытал потрясающее чувство: «О, теперь я понял».

Если у вас есть возможность, посмотрите на другие проекты и команды внутри компании. Почитайте их внутренние вики-страницы, посетите их демо, ознакомьтесь с их публичной документацией. Это можно делать время от времени, это не обязательно должно быть постоянным занятием. Бонус: если вы можете нарисовать диаграмму и написать документацию о «полной картине», сделайте это. Есть шанс, что многие люди в организации будут вам за это благодарны!

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

Присоединиться к on-call команде

Этот совет может показаться спорным, а может быть, в вашей компании это вообще невозможно. Конечно, вам стоит прислушаться к этому совету только в том случае, если в вашей компании здоровая on-call атмосфера (см. Компенсация за On-call для разработчиков).

Оn-call команда состоит из людей, готовых вмешаться, если что-то пойдет не так в рабочее время и вне его, то есть ночью, в выходные и праздники. Возможно, в вашей компании есть команда SRE, и/или ваша команда может не отвечать за работу DevOps.

Но если у вас есть возможность присоединиться к on-call команде, будь то для продукта, над которым вы работаете, или для всей компании (в зависимости от ее размера), я бы посоветовал это сделать.

Я вижу здесь следующие преимущества:

• Вы узнаете много нового о «закулисье» продуктов и услуг, благодаря которым компания процветает.

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

• Вы почувствуете себя более вовлеченным в работу компании, поскольку будете вкладывать больше своего времени в то, чтобы продукты и услуги работали так, как ожидают клиенты.

Но прежде чем брать на себя эту ответственность, необходимо создать благоприятные условия для работы в режиме on-call.

В своей первой компании я присоединился к on-call команде (которая отвечала за все услуги) примерно за два месяца до ухода. Я жалею, что не сделал этого раньше, так как за эти пару месяцев я многому научился, и эта дополнительная ответственность хорошо оплачивалась.

В моей второй и нынешней компании я присоединился к on-call команде (которая отвечает за обслуживание одного продукта) спустя два-три месяца после первого дня работы. Пока я работаю только в рабочее время, но со временем смогу реагировать в ночное время и по выходным.

Сменить команду

В каких случаях есть смысл попробовать перейти в другую команду:

• Вам слишком комфортно на нынешней должности, и вы хотели бы выйти из зоны комфорта.

• Вам не очень нравятся проекты/задачи команды, и вы хотели бы работать над проектами, которые вам больше по душе.

• Отношения с коллегами и/или руководителем ухудшились, и вы хотите улучшения рабочей атмосферы, оставаясь при этом в компании.

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

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

Я считаю, что смена команды — это может быть здорово по следующим причинам:

• Организация новой команды может быть другой (ритуалы, способы совместной работы), поэтому вы получаете больше опыта в этой области.

• Вы можете привнести положительные изменения, которым научились в предыдущей команде — улучшить процесс проверки кода, инструменты, библиотеки, ритуалы. И в результате стать проводником передового опыта в своей компании.

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

• Вы можете изучать новые инструменты, языки, библиотеки, архитектуры, способы решения проблем. Другими словами, стать лучшим разработчиком.

• Возможно, у вас появится возможность работать в лучших условиях, если ваш переход вызван причинами 2 или 3, упомянутыми ранее.

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

Когда я присоединился к новой команде, я почувствовал, что мое звание Senior программиста больше не является легитимным. Мне пришлось изучать новые кодовые базы, инструменты и практики. Конечно, я сохранил свои мягкие навыки и знания о бизнесе/продуктах, но мои технические навыки пострадали. Изучать что-то новое, конечно, здорово, но я больше не был техническим лидером в команде. Хотя, когда новой команде приходилось участвовать в проектах моей предыдущей команды, я мог помочь им более эффективно. Со временем чувство самозванца прошло, и я вырос, поскольку приобрел больше навыков.

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

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

Писать посты в блог

Этот пункт должен быть просто «Писать», но он показался мне слишком коротким. Умение писать — один из самых важных навыков, которыми должен обладать разработчик. Большая часть нашей повседневной работы связана с написанием текстов: кода, сообщений, писем, документации, RFC, заметок о встречах, разборов инцидентов и т. д.

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

Писать статьи полезно по следующим причинам:

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

• Цель написать статью заставит вас разбираться в выбранной теме. Это отличный способ узнать что-то новое, закрепить знания или разобраться в чем-то на более высоком уровне. 

• Это развивает ваш личный бренд. Чем больше людей интересуются вашими статьями, тем больше подписчиков вы получаете и тем более заметным становитесь.

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

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

Я начал этот путь с публикации в инженерном блоге своей первой компании: The most accurate way to schedule a function in a web browser. Она даже получила упоминание в рассылке JavaScript Weekly, что было очень приятно.

Затем, в марте 2021 года, я начал писать статьи в блог на Dev.to и продолжаю это делать время от времени. Я также опубликовал статью на HackerNoon, но мне не понравилось, как они отредактировали заголовок, и я решил, что моим основным местом для ведения блога будет Dev.to, по крайней мере пока.

Что я хотел бы сделать по-другому, вернись я в прошлое

Быть более осторожным, производя глобальные изменения

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

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

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

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

В какой-то момент после этих презентаций мы увидели возможность:

• Это было в начале лета, поэтому активность бизнеса в течение нескольких месяцев будет ниже обычного.

• В первой половине года мы столкнулись с несколькими ошибками и были вынуждены использовать костыли в одной из наших старых систем.

• Мы могли бы радикально улучшить тестируемость и удобство для разработчиков этой системы, используя функциональные концепции и типы TypeScript (он же TS). Эта старая система была изначально разработана на ранней версии TS, которая не предоставляла широких возможностей для работы с типами.

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

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

Меня сильно вдохновила библиотека fp-ts, способ кодирования которой, можно сказать, отличается от «обычного JavaScript». Мы не могли просто импортировать библиотеку в нашу кодовую базу из-за ограничений, о которых я не буду здесь упоминать, поэтому мне пришлось заново внедрить некоторые из ее функций и типов данных самостоятельно, с небольшими адаптациями. Я провел несколько презентаций об этих изменениях и получил положительный фидбек.

Отсутствие возражений замотивировало меня продолжить углубляться в эту тему.

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

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

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

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

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

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

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

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

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

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

Независимо от того, являетесь ли вы индивидуальным разработчиком (он же IC, individual contributor) или менеджером, если старший член команды вносит важные изменения, подобные этим, я настоятельно советую вам оспорить его предложение. Я уверен, что в моем случае можно было бы найти лучшее решение.

Если вы находитесь в таком же положении, как и я, я призываю вас дважды подумать, прежде чем принимать решение. Действительно ли это прагматичное решение? Уверены ли вы, что определена область применения и выявлены риски? Вы делаете это для блага команды или потому, что вам это нравится? Будет ли команде ок с этим решением, когда вас не будет рядом, чтобы помочь?

Не позволять эмоциям брать верх перед командой

Бывали моменты, когда я был категорически не согласен с тем, что руководитель или коллега рассказывал команде во время митинга. Я давал всем присутствующим понять, что меня это беспокоит, и таким образом публично начинал «конфликт».

Я хотел показать коллегам, что не соглашаться с чьим-то решением — это нормально. Однако такое поведение не является здоровым:

• Люди могут чувствовать себя неловко, когда конфликт становится видимым/очевидным, как в этих ситуациях. Несправедливо ставить их в такие ситуации.

• Это может привести к расколу в команде, когда одни соглашаются с человеком А, а другие — с человеком Б. Команда должна оставаться единой, чтобы быть эффективной.

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

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

На мой взгляд, в такой ситуации правильнее всего будет дождаться конца встречи, а затем сразу же:

• Поговорить с этим человеком на встрече 1-1.

• Или поговорить о ситуации с руководителем и найти способ ее исправить.

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

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

Время от времени мониторить рынок труда

Когда я пришел в первую компанию в качестве стажера, у меня было 30-минутное собеседование с моим будущим руководителем. И все. Я прошел быстрое собеседование на «соответствие культуре», и меня приняли.

После этого я семь с половиной лет не выходил на рынок труда. Когда я наконец решил сменить место работы, мой единственный и короткий опыт трудоустройства явно не соответствовал тому, с чем мне предстояло столкнуться. Процесс трудоустройства, когда вы претендуете на должность Senior с опытом около 8 лет, определенно не состоит из одного лишь «30-минутного поведенческого интервью».

После прочтения книги The Most Heated Tech Job Market in History я почувствовал, что готов попробовать. Я обновил информацию в профиле на LinkedIn и указал статус «в поиске».

Я чувствовал подавленность. Разбираться со всеми предложениями, которые сыпались на меня ежедневно, было утомительно. С сентября 2021 года по конец октября 2021 года я получал, наверное, от 5 до 10 предложений в рабочий день. Мне приходилось брать отгулы, чтобы справиться с ситуацией, и я тратил на это значительную часть своих выходных.

Поначалу я мог отвечать на каждое сообщение рекрутера. Но в какой-то момент я оказался в ситуации, когда:

• Я должен был работать весь день, так как в то время я еще работал в своей нынешней компании.

• Я находился в процессе переезда в другой город, что было для меня довольно стрессовым.

• Мне постоянно поступали новые предложения о работе.

Становилось все труднее отвечать на сообщения от рекрутеров.

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

Хочу сказать всем рекрутерам, которые связывались со мной в то время и которым я так и не ответил: Мне очень жаль. Я был просто ошеломлен ситуацией.

Но ответы на сообщения на LinkedIn были не самой сложной частью. Самыми утомительными были собеседования. У меня никогда не было возможности пройти обучение DSA (Data Structures and Algorithms), поскольку я не чувствовал необходимости менять компанию.

Я тренировался в основном на leetcode, а также купил несколько книг, которые мне помогли:

• Cracking the Coding Interview, Gayle Laakmann McDowell.

• System Design Interview Volume 1, by Alex Xu.

Кроме того, мне нужно было вспомнить и представить в деталях некоторые из наиболее значимых проектов, над которыми я работал. Именно в этом случае журнал работ, о котором мы уже говорили, может стать полезным подспорьем.

Когда я наконец принял оффер, я написал заявление об увольнении. Если я правильно помню, я получил тогда повышение зарплаты на 25%, а также дополнительную компенсацию и в целом более выгодные условия для сотрудников в моей ситуации (удаленная работа).

Причина, по которой я рекомендую вам время от времени проходить собеседования, заключается в следующем:

• Вы получите опыт, и когда придет время переходить в новую компанию, вы будете чувствовать себя менее подавленным.

• Вы сможете узнать, сколько вы стоите на рынке, и, возможно, попросить о корректировке заработной платы в вашей нынешней компании. Если вы получите оффер, то, скорее всего, это еще больше поможет вам получить то, чего, по вашему мнению, вы заслуживаете на своем нынешнем месте.

В моей первой компании я получал хорошие прибавки к зарплате (от 7 до 10 % в год), за исключением последнего года. Несмотря на то, что я не был доволен той зарплатой, которую получал в последний год, я считал, что в следующем году я все равно получу еще более высокую прибавку.

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

Не поймите меня неправильно: получить прибавку в 10% — это хорошо. Но если ваша зарплата на 15-20% ниже того, что рынок говорит вам о вашей ценности, то в конечном итоге и 10% прибавки будет недостаточно. А как узнать, есть ли у вас та компенсация, которую вы заслуживаете? Испытав этот рынок на себе. А также поддерживая связь с бывшими коллегами, которые сами испытали этот рынок.

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

Заключение

Прежде всего, спасибо, что дочитали до этого момента! Надеюсь, эта статья была для вас хоть в чем-то полезной. 

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

А сделать шаг навстречу профессиональному развитию и карьерному росту можно, посетив открытые уроки в OTUS, на которых эксперты в IT передают актуальные знания и делятся опытом. Смотрите расписание событий в календаре.