Для кого статья: для техлидов и системных аналитиков (SA), архитекторов ПО.
О чём статья: об использовании некоторых удобных, современных подходов к проектированию ПО на стеке Java-Spring в enterprise в условиях большого количества команд и большой неопределенности. 
Об авторе: лид стрима в облачном провайдере, в 2024-2025 гг. с коллегами разрабатывавший подходы к архитектуре микросервисов.

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

Для кого статья: для собеседующих в первую очередь, и для кандидатов.
О чём статья: о задачах, разработанных мною для технических интервью бэкенд-разработчиков уровня middle и выше.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью.

В прошлой статье я рассказывал об этапах проводимых мною собеседований. Рассказывал об особенностях найма в IT в 2024-25. Были немного обрисованы задачи, мотивация их особенностей, специальные подходы. Теперь пора уделить внимание хардскиловой составляющей. В этой статье подробнее расскажу о задачах и разберу сходные вариации.

Для кого статья: для тех, кто набирает разработчиков в свою команду и понимает в технологиях.
О чём статья: о проблемах найма в IT, о нарисованных резюме и зазубренных уроках.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью.

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

Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулся с настоящими вызовами, некоторые процессы пришлось выстраивать.

Когда первый раз мне HR`ы сообщили, что наш оффер принят, я столкнулся с тем, что хоть про онбординг‑адаптацию и говорят, конкретных гайдов и статей нет. На мысль о том, что «что‑то надо с этим делать» меня натолкнула коллега с другого направления, которая постоянно жаловалась на трудности адаптации и отсутствие информации. У нас, конечно, информации было достаточно в конфлюенсе, но, она не была структурирована для быстрого погружения нового сотрудника. Это был тревожный звоночек. Мы тратили месяцы на сложный технический отбор (воронка в 2-3% от кандидатов), находили сильных специалистов, а затем рисковали потерять их в первые же недели из‑за некачественных процессов и информационного голода.

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

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