🚀 Друзья, через час стартуем с Кабанчиком. Сегодня обсуждаем 11 главу Stream Processing. Присоединяйтесь!

Продолжаем рассказывать о наших выпускниках. Николай Яснов закончил 9-ый поток [Технического Лидера].

До курса:
* 13+ лет опыта. C#, Ruby
* Пришел в новую компанию как Senior developer
* Не хватает знаний в архитектуре, из-за чего проваливал собеседования

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

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

Сейчас у меня закончился probation и скоро начнется рост внутри компании. Я знаю, что можно предложить и как это сделать.

Павел Вейник, Преподаватель курса, Solution Architect, Staff Engineer:

“В быстрорастущих компаниях всегда есть спрос на тех, кто выше senior – staff-инженеров, техлидов, архитекторов. Если показывать, что можешь брать на себя ответственность, быстрый карьерный рост и более интересные задачи обеспечены”.

Подробнее о курсе [Технический Лидер] читайте на сайте или записывайтесь на бесплатную консультацию.

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

Синдром самозванца – это неспособность объективно оценивать свои способности и достижения. “Мне просто повезло”, “Это все команда, я только внес небольшой вклад”, “Если я задам глупый вопрос, все поймут, что я ничего не умею”.

Почему этот синдром так распространен в ИТ?

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

Сомневаться в себе – это нормально. Синдром самозванца – это когда сомнения начинают управлять тем, как человек себя ведет. Постепенно эти сомнения зацикливаются и подкрепляют себя:

Я сомневаюсь при решении задачи ➡️ я ищу решение ➡️ мне повезло/я скопировал чужое решение/мне помогли ➡️ я ничего не умею/обо мне слишком хорошо думают ➡️ я еще больше сомневаюсь при решении следующей задачи

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

🏆 Признавать усилия и достижения. Вы находитесь на своей позиции не просто так. У вас есть коллеги и начальство – специалисты, обмануть которых разом невозможно. А если у вас это получилось, то, вероятно, вы гениальный актер 😉
🫵 Опираться на свою оценку. Если вам кажется, что работа сделана хорошо, и нет крепких аргументов, почему это не так, – значит работа сделана хорошо.
🏄 Относиться к работе проще. Кроме нее в жизни есть много интересного. Успехи и неудачи в работе не характеризуют вас как человека.
🗣 Пообщаться с коллегами. Общение в кругу профессионалов помогает избавиться от завышенных ожиданий от себя.

За последним пунктом приходите на наши мероприятия

Друзья, напоминаем что сегодня вечером собираемся на технический доклад  и обсуждение темы: "Минусы и оверхэды микросервисов: как с ними бороться?".

Докладчик: Cергей Ткачев, Lead Software Engineer, 17+ лет в IT, из них 5+ лет опыта в коммерческой разработке на Java и Kotlin

Начало в 20.00 GMT+3

Регистрация по ссылке. До вечера!

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

Работа техлида и архитектора – про принятие технических решений. Использовать ту или иную базу данных, применять тот или иной фреймворк, фокусироваться на performance или availability.

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

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

Как сделать, чтобы это происходило реже? Архитектуру можно разделить на логическую и физическую:

🧠 Логическая архитектура – то, как устроена доменная область бизнеса, и как конкретная компания оперирует в этом домене.

Доменная область меняется медленно – если это ресторан, то 100% будет закупка и доставка продуктов, официанты принимают и доставляют заказы, повара готовят эти заказы в соответствии с меню. Эта логика скорее всего не изменится, и систему, которая ее обслуживает, можно сделать негибкой.

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

⚙️ Физическая архитектура – модули и взаимодействие между ними – микросервисы, базы данных, кэши, API, фреймворки и т.д. Здесь нужно опираться на то, насколько конкретный инструмент соответствует бизнес-потребностям, и ресурсам бизнеса и команды.

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

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

Научитесь принимать правильные архитектурные решения в масштабах команды или всей организации на курсах [Технический Лидер] и [Solution Architecture in the Wild]. Записывайтесь на следующий поток!

Вчера прошел четвертый H&S Conclave на тему "Минусы и оверхэды микросервисов — как с ними бороться?"

🎞 Запись доклада уже доступна на нашем ютуб канале

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

Зачем разработчику публичные выступления?

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

😎 Прокачать личный бренд и повысить свой авторитет. Личный бренд сильно помогает продавать себя как специалиста в нынешнем рынке труда.

🎓 Научиться объяснять сложные вещи простым языком. Этот навык пригодится и в менторстве менее опытных коллег, и в переговорах с менеджерами и бизнесом.

🤝 Завести полезные и приятные знакомства. В IT, особенно работая на удаленке, сложно расширять круг знакомств даже внутри компании, а тем более за ее пределами. Публичные мероприятия, особенно оффлайн, – лучший способ пообщаться с коллегами.

Модерируйте Архитектурные Трепы – выберите интересную вам тему и обсудите ее с опытными разработчиками, лидами и другими IT-специалистами из нашего комьюнити. Без камер, без четкого регламента, с уважением друг к другу.

Подготовьте технический доклад для H&S Conclave – короткое выступление на 30 минут с обсуждением в конце. Мы поможем вам сформулировать тему, подготовить презентацию и проанализировать выступление.

Поделитесь опытом развития карьеры, прохождения собеседований и выстраивания профессиональных связей в Карьерном Навигаторе.

Оставляйте заявку и прокачивайтесь с нами!

🧨 Напоминаем, что через 30 мин собираемся обсуждать драйверы изменений в архитектуре. Залетайте на Архитектурный Треп 119. Подробности

Друзья, 29 октбяря по случаю завершения Кабанчика мы организуем Круглый стол на тему "The Future of Data Systems". Будем говорить о настоящем и будущем рапределенных систем. Участники стола - модератора Кабанчика:

Ася Воробьева, Senior Software Developer
Антон Норко, Solution Architect
Александр Кохно, Lead Data Engineer

И приглашенный гость - Дима Королев, AuthZ Architect at Miro. Чтобы познакомиться с Димой поближе можно посмотреть его доклад про Event Sourcing на нашем ютубе.

🔗 Подробная программа и регистрация на круглый стол по ссылке. До встречи!

Говорим о деньгах так, чтобы их становилось больше

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

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

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

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

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

А как говорить о повышении ЗП на текущем месте?

Принцип тот же самый – показывать свою ценность для компании:

- Достижения за период с прошлого повышения
- Рост знаний и компетенций
- Готовность взять больше ответственности и драйвить масштабные процессы

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

Еще один способ повысить ЗП – контр-офферы. “Здесь мне предлагают столько-то, давайте что-то с этим делать”. Опасность контр-оффера в том, что руководитель может воспринять его как шантаж. Поэтому пользоваться этим методом стоит только если вы действительно готовы сменить место работы.

Друзья, just a kind reminder!

Cегодня встречаемся на круглом столе на тему "The Future of Data Systems". Обсудим темы:

1. Будущее базы данных и форматов хранения данных
2. Обработка больших данных: какие новые подходы появятся?
3. Искусственный интеллект и машинное обучение в обработке данных
4. Системы стриминговой обработки данных и их будущее
5. Системы данных на облачных платформах и edge computing и многое другое!

Успевайте зарегистрироваться и приходите. До встречи вечером 🙌