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

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

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

Сергей: Учиться параллельно, насколько это возможно. Понимаю, что это может быть в ущерб времени, проведенному с семьей. Лично я столкнулся с похожей ситуацией и научился вставать каждый день в 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 по прежнему рынок работодателя и найти достойную позицию не так просто.

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

На этой неделе стартуем курс [Технический лидер], который поможет вам сделать серьезный шаг от 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)

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