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

Вчера прошел супер интересный круглый стол с 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 по прежнему рынок работодателя и найти достойную позицию не так просто.

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

На этой неделе стартуем курс [Технический лидер], который поможет вам сделать серьезный шаг от Senior до Solution Architect.

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

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

Практика курса включает 4 задачи на Architecture Proposal: от уточнения требований бизнеса и ballpark estimations до system design и расчета стоимости инфраструктуры.

Кому подойдет этот курс?
• Middle+ откроет архитектуру распределённых систем, получит навыки решения архитектурных задач и улучшит способы коммуникации об архитектуре.

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

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

Записаться на бесплатную консультацию к Павлу Вейнику.

С Днем программиста!

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

Плюсы микротортов:
• Можно быстро попробовать новый вкус
• Легко делить между командами
• Каждый кусочек идеально масштабируется

Минусы микротортов:
• Крошки повсюду
• Никто не помнит, где лежит нужный кусочек
• Для полного счастья нужно съесть их все

Споры о том, что вкуснее, не утихают. А пока мы спорим, джуниоры съели все пирожные и раскрошили большой торт.

Приятного аппетита и чистого кода!

Друзья, с пятницей!

Мы продолжаем cобираться на групповые обсуждения в формате Круглого стола и 19 сентября приглашаем вас обсудить роль ТимЛидера:

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

Присылайте нам вопрос, которые вас волнуют, в форме регистрации и приходите 🚀

Как инициировать и продвигать большие изменения?

Что за большие изменения? Это что-то, что меняет процесс и культуру разработки в компании – масштабное изменение архитектуры, внедрение TDD, переход от релизов к CI/CD, упорядочивание стека в рамках Tech Radar и другие подобные по значимости вещи.

Чтобы драйвить и продавливать такие перемены нужно сделать 3 вещи (кроме, собственно, работы):

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

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

Донести ценность до бизнеса. Для бизнеса аргумент “так будет лучше” – не аргумент. Его задача – зарабатывать деньги. “Так мы сможем выпускать фичи быстрее”, “Так пользователь получит результат не за 20 секунд, а за 2”, “Так мы уменьшим затраты на инфраструктуру” – вот это аргументы, к которым бизнес прислушается. А если они еще и подкреплены документацией и POC, вероятность заручиться поддержкой кратно увеличивается.

Если вы хотите инициировать изменения в процессах, но не знаете, как довести эту инициативу до реализации, – записывайтесь на бесплатную консультацию перед курсом [Технический Лидер]. А почитать о том, как это происходит в реальности, можете в статье выпускника этого курса Павла Макула (если вдруг вы ее пропустили) – От хаоса к стандарту: создание универсального шаблона микросервисов.

Привет! В эту пятницу, 20 сентября, Павел Вейник (founder Hard&Soft Skills, Solution Architect, если вдруг кто не знает 😉) выступит в Tech Talks with Andersen.

Тема ивента: Путь от Middle до Architect: советы и подводные камни.

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

📅 20 сентября
🕢 19:30 (GMT+3)

🔗 Регистрируйтесь по ссылке!

Just a kind reminder 🤗

Сегодня ждём вас на круглом столе, посвящённому роли Тимлида.

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

Регистрацию и свои вопросы оставляйте по ссылке. Всех ждем вечером 🙌

Друзья, с пятницей 🤗

Делимся с вами записями событий этой недели:

1. В среду прошел H&S Conclave на тему Контейнеризация и CI/CD для .NET приложений с использованием Docker и Kubernetes
🎞 Запись доступна по ссылке

2. Вчера провели Круглый стол про Тимлида на проекте: как получать удовольствие от роли, приносить пользу бизнесу и не выгорать.
🎞 Смотреть на ютубе

Хорошего просмотра и классных выходных!

В чем заключается рост инженера и как опыт влияет на его мышление?

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

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

Рост Middle-разработчика – это расширение стека и углубление знаний о нем. Чем больше фреймворков и инструментов он знает, и чем лучше он ими владеет, тем выше его компетенции и ценность на рынке труда.

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

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

Но самое главное – расширять свою зону ответственности за рамки одной фичи/задачи. А для этого, кроме hard skills, нужны и другие навыки – понимание бизнеса, умение отстаивать решения и договариваться с коллегами, руководством и другими командами.

Знания, необходимые для этого перехода, мы упаковали в программу курса [Технический Лидер]. За 3 месяца вы систематизируете уже имеющийся опыт, расширите кругозор, и на практике научитесь проектировать распределенные системы исходя из потребностей бизнеса.

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