Как развиваться на работе? Про людей

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

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

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

Портрет сильного инженера

Недавно послушал посмотрел подкаст с Шамилем Арсунукаевым, проработавшим более 17 лет в Кремниевой Долине в качестве инженера и engineering-менеджера. В целом подкаст просто топ, очень рекомендую послушать.

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

1. Высокий уровень технических скиллов
2. Умение добиваться результата несмотря на сложности, выходящие за рамки написания кода

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

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

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

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

И вся вот эта основная мысль, на мой взгляд, переплетается с одним крайне важным тезисом, который упоминался в этом посте — «You’re not a programmer, you’re a problem solver».

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

Пишем грамотное CV

Написать резюме сложно. Написать грамотное резюме ещё сложнее, особенно, если не следовать советам людей, находящихся «по ту сторону», т.е. оценивающих эти самые резюме.

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

1. Правило 10 секунд

С детства нас учили тому, что нельзя судить по первому впечатлению. Так вот, забудьте. У hiring manager-а скорее всего нет времени на то, чтобы пытаться познать вашу невероятную внутреннюю красоту и скрытые таланты, резюме должно чётко и быстро дать понять, кто вы и что из себя представляете (стек, опыт, образование, достижения).

• «It should be clear that you are a strong developer for the targeted role within the first few moments of reading your resume. If it is not strong, you need to rephrase your resume»

2. Показывать, а не рассказывать

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

Сравните сами два пункта, написанных вроде бы про одно и то же, но дающих совершенно разное восприятие опыта:

• «Implemented Carraform v2.0 and launched to Prexo SpringSuite»
• «Developed a server-side layout engine in iOS by teaching myself GoLang to automate 1000+ antiquated manual layouts. Working with a coworker, this began as an ambiguous project that I drove to completion and launched company-wide»

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

• «Mentored a team through weekly presentations, leading to the adoption of the ViewModel pattern in the codebase»

3. Less is more

Сделайте фокус на наиболее интересных и релевантных проектах и опыте. Не нужно пытаться поместить в резюме каждый свой чих. Как я слышал от hiring manager-а, любое резюме размером более 2 страниц практически наверняка идёт в мусорку. В идеале — одна страница, в редких случаях — две.

• «If you have less than 10 years of experience, you have less than 2 pages of content. If you have more than 10 years of experience, you know how to summarize into 2 pages of content»

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

— Статья от Engineering Manager-а (очень советую почитать комментарии под статьёй)
— Подкаст с Engineering Manager-ом, таймлайн про резюме
— Resume Workshop от Ex-Google Tech Lead