11 октября 2026
В менторстве ко мне приходят с разными задачами: разобраться в новой роли, обсудить устройство инженерной организации, выбрать следующие карьерные шаги или подготовиться к интервью. Ниже примеры встреч.
От управления командой к управлению руководителями
Николай
- Роль: Team Lead of Team Leads / Engineering Manager.
- Зоны ответственности: управление проектами, управление тимлидами, стратегическое планирование, неформальное лидерство.
- В новой должности меньше месяца.
- Около 50 человек, два департамента.
Запрос: помочь освоиться в новой должности.
Отдельный запрос касался качества. Релизы были редкими, приемочное тестирование занимало несколько недель. CTO хотел сократить объем ручных проверок и вовлечь разработчиков в обеспечение качества.
Что разобрали
У Николая были сомнения, насколько реалистично двигаться в сторону стратегии CTO и переносить ответственность за качество на разработку. Dev и QA комфортно работали каждый в своей зоне. Культура автотестов в разработке была в зачаточном состоянии: отдельные наборы оставались на усмотрение разработчиков. Одновременно готовились несколько релизов.
Разобрали, какую проблему решает запрос CTO: ускорить time to market и уменьшить изоляцию Dev и QA. В этой ситуации важно было договориться об общей ответственности за результат. Передача готового кода на отдельный этап тестирования сохраняла разделение по функциям и ожидание между ними.
Обсудили мотивацию команд и выравнивание ответственности по бизнес-границам. Команда должна отвечать за работающий пользовательский сценарий, а разработчики и QA участвовать в его подготовке и проверке с самого начала. Это не отменяет специализацию: QA помогает выявлять риски и выбирать проверки, разработчики обеспечивают проверяемость кода и поддерживают автоматические тесты.
Разобрали промежуточный вариант: разработчики пишут unit- и integration-тесты, QA развивает системные проверки. Для этого нужны общие инструменты, время на обучение и поддержка тимлидов. С руководством изменения стоит обсуждать через время доставки и качество, с инженерами через сокращение ручных повторных проверок и уверенность при изменении кода.
Предложил начать с одного бизнес-сценария и небольшой группы Dev и QA. Вместе пройти путь от требований до выпуска: заранее разобрать риски, договориться о проверках и посмотреть, где работа ждет передачи между участниками.
Автотесты внедрять постепенно. Для новых изменений и исправлений ошибок добавлять проверки в CI, начиная с критичной бизнес-логики. Разработчики пишут и поддерживают тесты своего кода, QA помогает выбирать сценарии и сохраняет исследовательское тестирование.
На переходный период закрепить QA за выбранным направлением, чтобы он участвовал в работе с самого начала. Тимлиды выделяют время на обучение и совместное написание первых тестов.
Сравнить время ожидания проверки, возвраты на доработку и длительность приемки. Если пилот дает пользу, расширять подход на другие направления. При нескольких релизных линиях отдельно договориться, какие проверки выполняются в каждой и как исправления переносятся между ними.
Инженерная стратегия и ответственность команд
Никита
Уровень: менеджер.
Запрос:
- Развитие инженерной культуры в домене.
- Построение процессов разработки в домене.
- Организация работы с вендорскими командами.
Что разобрали
Связали три вопроса: какой результат нужен бизнесу, за что отвечает инженерия и как распределить эту ответственность между командами. Стратегия помогает описать образ результата и путь к нему, а договоренности о качестве системы делают ожидания конкретнее.
Разобрали SLA/SLO/SLI как инструменты управления ожиданиями. При обсуждении стратегии важно понимать, какие обязательства берет на себя инженерия и по каким признакам можно оценить результат.
Для разговора о структуре и взаимодействии команд использовали Team Topologies: за что отвечает каждая команда, где проходят границы и как команды работают друг с другом.
Материалы для дальнейшей работы:
- Инженерная стратегия: техническая стратегия как инструмент команды, опыт Авито с написанием техстратегии, Engineering Strategies от Will Larson.
- SLA/SLO/SLI: разбор Авито, книги Google SRE, основы SLI, SLA и SLO от Google.
- Дизайн команд и ответственность: основные понятия Team Topologies.
Подготовка к System Design интервью
Антон
- Уровень в заявке: Senior.
- Роль: Staff Software Engineer.
- Опыт: мобильная и десктопная разработка.
- Контекст: подготовка к выходу на британский рынок труда.
Запрос: провести mock interview по System Design. У Антона не было опыта таких интервью, а последнее собеседование он проходил в 2018 году. При подготовке возникали трудности с алгоритмическими задачами и особенно с System Design. Хотел получить практику перед реальными интервью.
Провели пробное интервью на задаче проектирования истории действий пользователей.
Что разобрали
Основное внимание уделили переходу от требований к проектированию. Разобрали, как сначала определить пользователей, поведение системы и ограничения, а затем объяснить выбор компонентов и технологий через эти требования.
На примере истории действий прошли вопросы доступа, фильтрации, хранения и получения архивных данных. Отдельно обсудили нефункциональные требования: допустимые задержки, нагрузку и ожидаемый рост системы.
Предложил вести решение по шагам:
- Уточнить контекст, границы системы, функциональные и нефункциональные требования.
- Описать пользователей и способы взаимодействия с системой.
- Подобрать основные компоненты и объяснить, как они удовлетворяют требованиям.
- Перейти к технологиям и деталям реализации.
- Обсудить ограничения, альтернативы и последствия решений.
На переходах сверять понимание с интервьюером: правильно ли сформулирована задача, достаточно ли требований и можно ли двигаться дальше. Это помогает вести разговор и не уходить в детали раньше времени.
После интервью подготовил письменный разбор с этапами, вопросами для сверки и направлениями подготовки. Предложил сочетать разбор типовых задач с изучением принципов проектирования, чтобы уметь объяснять решения в новой задаче.
Задачу со своей стороны выбрал слишком большую для времени встречи: обычно на нее отводилось полтора часа. Мы не успели пройти весь разбор. Для следующего пробного интервью нужно было уменьшить объем и оставить время на обратную связь.
Материалы для подготовки:
- Alex Xu, System Design Interview: разбор типовых задач.
- Влад Хононов, «Изучаем DDD»: моделирование предметной области.
- Крис Ричардсон, «Микросервисы. Паттерны разработки и рефакторинга» и microservices.io.
- Martin Kleppmann, Designing Data-Intensive Applications.
- Maarten van Steen и Andrew Tanenbaum, Distributed Systems.
Обратная связь
Евгений, спасибо огромное!
Мне безумно понравилось общение с тобой!)
Пробное интервью на Engineering Manager
Денис
- Опыт управления инженерными командами.
- Возвращение к поиску работы после карьерного перерыва.
- Подготовка по темам people, product и process, без технической части.
Запрос: потренироваться в безопасной обстановке и получить честный фидбек по ответам.
Что разобрали
Разбирали продуктовые и инженерные фреймворки через практические ситуации из карьеры Дениса. Как выбрать подход под задачу, применить его в команде и объяснить, какой результат он дал.
В продуктовой части: OKR и связь работы команды с целями бизнеса, определение MVP и управление объемом задачи, оценка результата через adoption, retention и другие продуктовые метрики. Обсудили случаи, когда продуктовые цели расходились с архитектурными ограничениями и решение нужно было согласовать между участниками.
В инженерной части: Scrum и Kanban для организации доставки, WIP-лимиты и метрики потока для поиска задержек, Team Topologies для устройства команд и RACI для распределения ответственности. Обсуждали, как эти подходы работают в конкретном контексте и где требуют адаптации.
Кейсы из его карьеры раскладывали по STAR: ситуация, задача, действия и результат. Уточняли, в чем состояла собственная роль Дениса, какие ограничения влияли на решение и как он оценивал последствия. Дал обратную связь, как сделать это понятным интервьюеру.
В people management разобрали грейды, матрицу компетенций, ответственность и самостоятельность инженеров. Обсудили практики 1:1, обратной связи и 360 review, индивидуальные планы развития, менторство и делегирование задач для роста.
Отдельно прошли случаи роста и увольнения людей: какие ожидания были согласованы, как оценивался результат, какую поддержку получал человек и когда руководитель принимал решение. Для работы с недостаточной результативностью обсудили последовательность от конкретного фидбека и плана поддержки до PIP и итогового решения.
По отзыву Дениса, разбор помог ему отточить кейсы.
Обратная связь
Провели отличное mock interview с Евгением. Он копал оч глубоко и по всем важным для позиции темам - как раз то, что мне было нужно. Его фидбек помог мне отточить мои кейсы. Однозначно доволен и рекомендую 👍
Переход в Engineering Manager и подготовка к интервью
Артем
- Опыт тимлида, Scrum Master и работы с Agile-процессами.
- Был OKR-коучем на уровне компании, но инициативу свернули.
- На текущем месте не было интересных ему нетехнических задач и запроса на эту работу. Культурное несовпадение с компанией влияло на мотивацию.
Запрос: определить дальнейший карьерный путь. Артема интересовал менеджмент, а роль Engineering Manager казалась подходящей, но он узнал о ней недавно и хотел разобраться в ожиданиях.
Что разобрали
Посмотрели резюме и обсудили, как имеющийся опыт соотносится с ролями Tech Lead, Team Lead и Engineering Manager. Важно было понять, какие задачи Артем хочет решать и где этот опыт будет востребован.
Разобрали подготовку к интервью: техническая часть, System Design и менеджмент. Для System Design предложил сочетать разбор типовых интервью-задач с изучением архитектурных подходов. Дал материалы по C4, DDD, паттернам микросервисов и инженерному менеджменту.
Позже Артем вернулся с уточняющим запросом о менеджерском интервью. Он уже готовился к технической части и System Design, но хотел понять, как готовить управленческие примеры. Разложили этот этап на четыре области:
- Delivery management: цели, приоритизация, декомпозиция, фокус, контроль прогресса и риски. Как действовать при задержках и балансировать скорость с качеством.
- People management: мотивация, развитие, обратная связь, конфликты и вовлеченность. Как работать с демотивацией и помогать расти инженерам.
- Process management: выбор и адаптация процессов, устранение узких мест, метрики и организация команд.
- Soft skills: аргументация при несогласии, признание ошибок, доверие и ответственность за общий результат.
В последующей переписке Артем рассказал, что прочитал Alex Xu, изучил статьи и видео пробных интервью. По его словам, появилась уверенность, что он сможет справиться с System Design. Также начал составлять вопросники и конспекты для технической подготовки.
Материалы для подготовки:
- Alex Xu, System Design Interview.
- C4 Model, microservices.io и книга Криса Ричардсона о паттернах микросервисов.
- Влад Хононов, «Изучаем DDD».
- Martin Kleppmann, Designing Data-Intensive Applications.
- Джеймс Стэниер, «Карьера Software Engineering Manager».
- «Эволюционная архитектура на практике».
Обратная связь
Всё понравилось. Взглянул незамыленным взглядом на моё резюме, высказал своё мнение по дальнейшим шагам, рассказал примерно о перспективах, скинул литературу для дальнейшего развития. Выслушал и ответил на все мои вопросы. Наверно, обращусь ещё как переварю эту порцию информации
Devcast о стартапе с AI harness для SDLC
Анастасия
Стартап разрабатывает и продает AI harness для SDLC софтверным компаниям.
Запрос: провести devcast с Анастасией о стартапе и его продукте.
Что разобрали
Встреча в основном проходила как интервью со мной. Обсудили направления развития AI SDLC на рынке, имеет ли смысл конкурировать с Jira и Linear и как стартапу отличаться от существующих решений.
Рассказал, как мы строили внутренний AI harness: адаптировали SDD-фреймворки под свои процессы и запускали автономных агентов. Сопоставили этот опыт с возможностями продукта стартапа.
По обсужденному набору функций наш внутренний сетап уже закрывал то, что стартап предлагал как готовое решение. Это стало конкретной точкой для разговора о позиционировании: какую дополнительную ценность дает коробочный продукт компании, которая уже умеет собирать такие инструменты сама.
Обратная связь
Отличная встреча с ментором и сразу целевая и полезная информация. Приятная коммуникация. Точно рекомендую.
Рост до Head of Development
Вера
Уровень: менеджер менеджеров.
Запрос: как вырасти на позицию Head of Development.
Что разобрали
Основной разбор был про hard skills: чего ожидают от Head of Development и как готовиться к этой роли.
В контексте ее карьерного запроса определили System Design как базовое ожидание. Глубокая экспертиза в узкой технологии нужна прежде всего там, где руководителю предстоит закрывать конкретные технические проблемы. Для остальных задач важнее широкая архитектурная насмотренность: понимать варианты решений, задавать уточняющие вопросы и проверять ограничения и последствия предложенного подхода.
Отдельно разобрали работу с технической стратегией. Нужно уметь связать ее с задачами бизнеса, определить принципы принятия решений и добиваться их применения в работе команд.
Подготовку обсудили через разбор архитектурных кейсов: какие требования определяют решение, какие альтернативы есть и чем приходится жертвовать. Это помогает развивать System Design и умение содержательно обсуждать решения с техническими лидерами.
От Tech Lead к Engineering Manager и CTO
Максим
- Роль: Tech Lead.
- Контекст: разработка мобильного банковского приложения.
- Горизонт развития: 3-5 лет.
Запрос: разобраться в переходе на роль Engineering Manager и дальнейшем развитии в сторону CTO. Интересовали мой путь к Head of Development и рекомендации по следующим карьерным шагам для человека с похожим опытом.
Что разобрали
Обсудили рост внутри компании через решение задач бизнеса и своего руководителя. Сначала нужно понимать ожидания от текущей роли и надежно их закрывать: за какой результат отвечаешь, какие решения принимаешь самостоятельно и где от тебя ждут большего.
Следующий шаг - разобраться в проблемах руководителя и найти те, которые можешь помочь решить. Так можно расширять ответственность и показывать готовность к следующему уровню на конкретных задачах.
Разобрали и внутреннюю политику. Даже если компания отрицает ее существование, на решения влияют отношения, доверие и видимость результатов. Личный бренд внутри компании и участие в важных обсуждениях помогают другим замечать твой вклад и понимать, какую ответственность тебе можно доверить.
Важно учитывать положение и перспективы своего руководителя: где он находится в иерархии, как может развиваться его роль и какие возможности это открывает для команды. Вертикальный рост зависит и от того, появляется ли в организации место для новой ответственности.
Обсудили горизонтальные переходы и развитие смежных компетенций под конкретные потребности компании. Переход в другое направление или работа над общей проблемой нескольких команд может дать нужный опыт и возможности, которых нет в текущей роли.
Для следующего шага предложил сопоставить ожидания от своей роли, задачи руководителя и потребности бизнеса. На этой основе выбирать, какую проблему взять на себя и какие навыки для этого развивать.
Связанные материалы: грейды и competency matrix, инженерная стратегия и C4 Model.