Друзья! Вчера прошел Карьерный навигатор в формате круглого стола – Путь развития из Senior в Techlead: живой опыт инженеров.

🎬 Запись уже на нашем YouTube-канале. Приятного просмотра!

Получилось увлекательное обсуждение. Участники поделились, как им удалось стать техлидами, с какими проблемами пришлось столкнуться, что нужно для роста выше уровня senior, и как в этом помогает курс [Технический лидер] 😉.

К сожалению, не успели ответить на все вопросы, заданные при регистрации. Но мы обещали ответить на них – значит ответим, stay tuned!

Обязанности, долгосрочные цели, зарплата – как техлиду договариваться о повышении?

Это еще одна крайне интересная тема, которую подняли на занятии курса [Технический Лидер]. Делимся результатами обсуждения с вами!

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

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

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

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

🗣 Какие у меня полномочия? Могу ли я нанимать/увольнять людей? Нужно ли мне договариваться со всеми самостоятельно или я могу продавливать какие-то решения от имени, например, CEO?

💰 Что я за это получу? Это абсолютно нормальный вопрос, которого адекватный руководитель вполне ожидает. Больше зарплата, выше грейд, одноразовый бонус – об этом нужно договориться заранее и договориться четко (а еще лучше где-то зафиксировать). А то может получиться “ну ты работай хорошо – получишь премию”.

Крайне важное условие, которое обязательно нужно обсудить заранее, – порядок отчетности. Это будут 1-1 митинги с руководителем раз в месяц или еженедельные репорты? Что это дает:

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

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

✨ Круглый стол с Архитекторами уже на этой неделе

В этот четверг четыре опытных архитектора соберутся вместе, чтобы рассказать о своем пути от роли разработчика до позиции Solution Architect, поделятся какие проекты и задачи больше всего способствовали профессиональному росту, какие hard и soft скиллы must have, как развивать стратегическое мышление и многое другое.

👥 Участники:

Антон Норко, Solution Architect
Максим Аршинов, Solution Architect в EPAM Spain
Сергей Бабицкий, Solutions Architect, TOGAF Certified
Антон Дворников, Principal Solution Architect, SEI Certified

🎙 Ведущий: Павел Вейник, Solution Architect, Staff Engineer

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

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

❓Как инженеру дорасти до СTO?
Попробуем разобраться на круглом столе 29.08

👥 Участники:

Юрий Морозов, CTO в Neocode
Сергей Зотов, CTO в SWAG42
Юрий Полосов, CTO стартапа B2B2C Gambling Platform
Илья Шкиренко, Co-founder & CTO в Platto и Interaksi, Fractional CTO и Tech Advisor, ментор стартапов в ULTRA.VC и Founder Institute

🎙 Ведущий: Павел Вейник, Solution Architect, Staff Engineer

Вопросы для обсуждения:

◆ Кто такой CTO и чем эта роль отличается от других технических ролей в ИТ компании?
◆ Какая мотивация становится CTO?
◆ Как изменить мышление с «выполнения задач» на «стратегическое руководство»?
◆ Как управлять командой: найм, онбординг, процессы, увольнения.
◆ Отношения с CEO и другим топ менеджерами.
◆ Баланс между техническими знаниями и управленческими обязанностями на позиции CTO.
◆ Частые ошибки инженеров, стремящихся стать CTO

🔗 Узнать подробнее и зарегистрироваться

😇 Через час начинаем круглый стол с Архитекторами. Успевайте присоединиться. Подробнее

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

🎥 Запись ивента уже на нашем YouTube-канале. Приятного просмотра!

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

The Goal: A Process of Ongoing Improvement
Impact Mapping
Оргуправленческое мышление: идеология, методология, технология
Software Architecture in Practice, 3rd Edition
Time Management for System Administrators
A Minimal Approach to Architecture as Code: Documenting the Modern Way
EventStorming
Шкура на кону. Скрытые асимметрии в повседневной жизни
Требования для программного обеспечения: рекомендации по сбору и документированию
System Design Interview – An insider's guide
System Design Interview – An Insider's Guide: Volume 2
Основы ТРИЗ: Теория решения изобретательских задач

С кем техлиду сверять правильность архитектурных решений?

Самый очевидный ответ на этот вопрос – обратиться за ревью к более опытным коллегам. Но техлид очень часто оказывается в положении “самого умного человека в комнате”. Особенно в небольших компаниях. В таком случае есть 4 пути:

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

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

2️⃣ Если в команде нет эксперта по конкретному вопросу, имеет смысл привлечь внешнего архитектора для консультации или аудита. Такой человек сможет непредвзято посмотреть на техническое решение.

Привлечь внешнего эксперта можно не всегда – есть NDA, риски утечки и другие издержки. Так что такое решение 100% нужно согласовывать с руководством.

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

4️⃣ Прийти на курс [Технический Лидер] и попасть в коллектив senior+ инженеров, которые сталкиваются с похожими проблемами. Отдельные аспекты своих архитектурных решений вы сможете обсудить на занятиях с другими участниками курса и преподавателем.

А пакет Architect включает в себя несколько сессий архитектурного консультирования с Павлом Вейником общей длительностью 5 часов.

❗️ Важно помнить

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

Всем продуктивного понедельника! 🧑‍💻

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

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

🔗 Регистрируйтесь и задавайте свои вопросы, будет интересно!

👋 Привет! Во время круглого стола с архитекторами осталось много вопросов, которые не успели обсудить. После мероприятия на них ответили Сергей Бабицкий, Антон Дворников и Максим Аршинов.

Публикуем первую часть ответов:

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

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

Максим: Идти во фронтенд-архитекторы.

Как быстро вырасти после двухлетнего перерыва (учеба на магистратуре) с позиции мидл?

Сергей: Рекомендую активно читать книги, проходить онлайн-курсы, смотреть образовательные видео на YouTube и самое главное — начинать что-то делать на практике, например, работать над пет-проектом. Также полезно записывать незнакомые термины и понятия в блокнот и не вычеркивать их, пока вы не узнаете о них всё необходимое.

Максим: Брать на себя ответственность и читать книжки.

Как вообще эта идея пришла в голову "Мне нужно стать архитектором", помните? Или "Как-то само"? 😃

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

Как рисковать, пробуя что-то новое, и не сталкиваться с проблемами спустя год-два?

Сергей: Важно заранее осознать и принять все возможные последствия вашего решения. Если вы готовы к этим последствиям и понимаете их, то можете смело идти на риск.

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

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

В чем ключевое отличие архитектора от сеньора?

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

Максим: Это другая работа. Архитектор знает больше, чем сеньор. И знает другие вещи.

Мы к вам с очередным анонсом! 🔥

В следующую среду, 4 сентября, проведем еще один круглый стол. Мы уже поговорили с техлидами и архитекторами, вот вот пообщаемся с СТО, но как будто бы упустили что-то очень важное. Пора исправляться!

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

Участники:

Алексей Залётов, Senior Software Engineer
Нафиса Юлдашева, Senior Python Backend Developer
Алексей Гурьянчик, Senior Java Developer

Ведущая:

Светлана Семёнова, Senior Unity Developer

📆 4 сентября
🕗 20:00 (GMT+3)

🔗 Регистрируйтесь и задавайте свои вопросы!

Вторая часть ответов на вопросы, которые задали во время круглого стола с архитекторами. А уже завтра своим опытом поделятся четверо CTO.

🔗 Регистрируйтесь и оставляйте вопросы в форме!

Как переходить на событийную архитектуру (подход), когда все на RESTах и «по-старинке»?

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

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

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

Какие отношения складываются между архитекторами и разработчиками?

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

Сложно ли найти/менять работу? Вакансий в открытом доступе мало, как происходит поиск?

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

Максим: Да, сложно. Лучше искать по знакомству. Вакансий меньше, но зато они более интересные и денежные.

Похоже, что эта работа в основном про System Design + soft skills (поправьте, если не так). Подразумевается, что hard skills к моменту перехода на данную должность уже на высоком уровне, но есть ли что-то, на что нужно обратить особое внимание?

Сергей: Hard skills всё еще должны быть на хорошем уровне. Без них и способности быстро учиться, вам будет очень, если не невероятно, сложно справляться с задачами на этой позиции.

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

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

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

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

Всем хорошей пятницы! (желательно без релизов 😉)

Вчера прошел супер интересный круглый стол с CTO. Беседа получилась очень живой и увлекательной – участники разговаривали на час больше, чем планировали.

Запись ивента уже на нашем YouTube. Приятного просмотра!

Спасибо Юрию Морозову за ответы на часть вопросов, которые не успели обсудить!

Стал недавно CTO, какие шаги:

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

Конфликт - способ решения проблемы?

Как ни странно, да.
Рекомендую "Пять пороков команды" Ленсиони и базовые курсы по конфликтологии (есть бесплатные на ютубе)

Как думаете СТО должен управлять процессом разработки?

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

Стартап 40-50 тел. Кого ставить главным?

Прекратите называть живых еще людей телами.

На каких скиллах сфокусироваться?

Sometimes the only choices you have are bad ones. But you still have to choose. (c) Doctor Who

Дает ли вам эта должность дозу дофамина?

Дофамина - нет.

Людей терзает необъятность вечности, и потому мы задаемся вопросом: услышат ли потомки о наших деяниях? Будут ли помнить наши имена, когда мы уйдём, и захотят ли знать, какими мы были, как храбро мы сражались, как отчаянно мы любили?..

Как управлять несколькими командами/департаментами?

У вас теперь одна команда - ваши лиды. Ими и управляйте.

Можно ли вырасти в CTO без бекграунда разработчика?

Думаю, можно, если иметь хороший общий технический бекграунд (саппорт, девопс).
Впрочем, там тоже кодики пишут, так что вопрос терминологии.

Если ваш вопрос остался нераскрытым – задавайте в комментариях, пообщаемся!

Что нужно знать о System Design interview?

Это стандартный этап технического собеседования на позиции от senior и выше (хотя некоторые компании проводят этот этап и для мидлов).

Во время интервью вам предложат спроектировать систему. Это может быть как что-то известное – например, Twitter, YouTube, Zoom. Так и задача в домене компании.

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

* Сколько пользователей ожидается в первый год? Через 5 лет?
* Будем работать в одном регионе или глобально? Насколько большие пиковые нагрузки ожидаются и можем ли мы их спрогнозировать?
* Сколько данных мы можем себе позволить потерять?
* Насколько большую задержку мы можем себе позволить без потери пользователей?

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

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

👉 На уровне техлида и архитектора (staff engineer, principal engineer и т.д.) интервьюер скорее всего будет менять требования в процессе создания дизайна. А следовательно будет меняться и архитектура системы.

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

👉 Никто не ждет от вас готовую архитектуру с точными расчетами нагрузок и стоимости. За время интервью это сделать невозможно.

⌚️ Важно помнить про тайминг. Интервью обычно занимает час-полтора. На первоначальный сбор требований не стоит уделять больше 10-15 минут. Остальное время нужно потратить на дизайн и объяснение своих решений.

System design interview – это не только и не столько проверка технических знаний, а скорее оценка вашей стратегии мышления и подхода к решению задач.

В практических задачах курса [Технический Лидер] мы используем шаблон Architectural Proposal. В нем содержатся все этапы проектирования архитектуры – от сбора бизнес-требований и ballpark estimations, до выбора конкретных компонентов архитектуры и защиты своих решений перед стейкхолдерами. Подробнее можете узнать на бесплатной консультации – записывайтесь!

Круглый стол о сеньорности уже на этой неделе!

4 опытных сеньора соберутся в эту среду чтобы поделиться своим опытом как у них получилось вырасти до Senior позиции 🤓

Обсудим:

🔸 Какие задачи / проекты больше всего бустанули карьеру?
🔸 Чем Senior отличается от Middle?
🔸 Сколько времени уделять обучению и самообразованию?
🔸 Как поддерживать актуальность своих технических навыков в быстро меняющемся мире IT?
🔸 Какую роль сыграли софт-скиллы в карьерном росте?

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

Друзья, а short reminder.

Cегодня в 20.00 GMT+3 мы собираемся обсуждать 10ую главу Кабанчика "Batch Processing". Модератор встречи - Ася Воробьева. Регистрация на встречу

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

PS. Записи обсуждений всех предыдущих глав Кабанчика собраны на нашем ютубе. Enjoy!

✌️Вчера прошел наш четвертый круглый стол. В этот раз поговорили с senior разработчиками о том, что значит быть сеньором:

* Чем Senior отличается от Middle?
* Какие факторы помогают расти, а что тормозит развитие?
* Важно ли официальное “звание” senior?
* Как бороться с синдромом самозванца?
* Чем помогает курс [из Middle в Senior]?

Запись мероприятия уже на YouTube. Приятного просмотра!

Ведущая круглого стола – Светлана Семёнова, Senior Unity Developer и преподаватель курса [из Middle в Senior]. Программа курса нацелена на комплексное развитие навыков, нужных, чтобы мыслить и писать код как senior: практики чистого кода, паттерны проектирования, основы system design и архитектуры веб-приложений, проектирование баз данных. Полную программу можно найти здесь.

Записывайтесь на бесплатную консультацию!

Чем опасно долго работать на одном месте?

Стабильность – это всегда приятно, но это фактор, тормозящий рост и развитие. Не только как инженера, но и как человека в целом. Да-да, та самая “зона комфорта”.

Вот основные минусы:

💰 Зарплата растет медленно. С точки зрения работодателя, если сотрудник согласился работать за сумму Х, его зона ответственности и список обязанностей изменились не сильно, то и обоснования для повышения нет (кроме компенсации инфляции). Спустя 5 лет на одном месте зарплата может отстать от рынка на 25-50%.

⚙️ Навыки замыкаются на том, что нужно конкретной компании. Часть команды – часть корабля (с). Это делает вас “незаменимым” в рамках этой компании, но найти новое место под этот же стек и знания крайне тяжело.

📈 Сложно оценить свой реальный уровень. Почти все инженеры задаются вопросами в духе: “А точно ли я senior?”, “Хорошо ли я выполняю свои задачи?”. Работая с одними и теми же технологиями и людьми найти внешнюю валидацию сложно. Со временем это выливается в синдром самозванца. Либо обратная ситуация – рынок ушел вперед, и те знания, которых раньше хватало, чтобы называться сеньором, сейчас потянут на средненького middle разработчика.

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

Разумеется, у частой смены работы тоже есть минусы. Рекрутеры, смотря в CV с десятком мест работы, неминуемо будут задавать вопрос: “А почему так?”. Правильного ответа здесь нет, но можно сказать что-то вроде:

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

Еще один tradeoff – стресс. Общение с рекрутерами, собеседования в несколько этапов, где-то тестовые задания, испытательный срок. А в итоге может оказаться, что трава совсем не зеленее на новом месте. И тогда цикл повторяется. А еще часто работает принцип last in – first out. Не говоря о том, что сейчас в IT по прежнему рынок работодателя и найти достойную позицию не так просто.

А что думаете вы, “джоб-хоппинг” или стабильность?