# Рунити / Runity — скрининг ИИ-помощника hh (CTO облачного направления) Канал: чат ИИ-помощника hh.ru по отклику. Вопросы идут адаптивно, по мере ответов. Транскрипт и готовые ответы. Отвечать лучше короткими конкретными абзацами с фактурой и цифрами: ИИ-помощник вытягивает из ответов теги (роль, стек, масштаб). ## Транскрипт **ИИ-помощник:** Здравствуйте! Я ИИ-помощник hh. Спасибо за отклик на вакансию! Чтобы компания Рунити могла быстрее принять решение о следующих шагах, предлагаю ответить на несколько вопросов... **ИИ-помощник:** Расскажите, пожалуйста, какую роль вы обычно выполняете при проектировании облачной инфраструктуры? **Пользователь:** Тимлид **ИИ-помощник:** Понял, вы выступаете как тимлид. Могли бы рассказать подробнее, какие именно задачи и обязанности вы выполняли в этой роли при проектировании облачной инфраструктуры? **Пользователь:** Выработка архитектуры решения, кодревью, онбординг новых сотрудников, выстраиваете командных процессов, коммуникация с другими командами **ИИ-помощник:** Расскажите, пожалуйста, о проектах, которые вы реализовали на C++ или Go. ← **отвечаем сейчас** ## Ответ на текущий вопрос (готов к вставке) Только честная фактура: коммерческого C++ нет, путь через Go + системное образование. Сильные факты - впереди, ограничение - в конце одним предложением, без самобичевания. ``` 1) Go, Samokat.tech (2023-2025) - платформенный сервис реального времени. Спроектировал и вывел в production Go-сервис, который читал события из Kafka и раздавал их клиентам через WebSocket. Сервис стал общим транспортом для трёх потребительских продуктов, запущенных с нуля: ~500 одновременных соединений, ~50 событий/сек, 800K+ пользователей, 150 RPS на бэкенде продуктов. Моя роль: архитектура, реализация, запуск, эксплуатация. 2) Go, SeoPult (2014-2015) - высоконагруженный HTTP-краулер. Краулер на Go с RPC-доступом и обходом большого числа страниц, интеграция с внутренним ядром платформы (Ruby: Sidekiq workers, remote RPC, REST API). 3) База: МАИ, специальность "Математик, системный программист" (прикладная математика и физика) - устройство памяти, конкурентность, работа на уровне ОС. Честно скажу прямо: коммерческого C++ в опыте нет, как и глубокого уровня виртуализации/OpenStack на физических серверах. С инфраструктурой работал как инженер: Kubernetes, Docker, Prometheus, Grafana, OpenTelemetry (распределённый трейсинг на 20 сервисов), GitLab CI/CD - но не как владелец гипервизорного слоя. ``` Короткая версия (если чат ждёт 1-2 абзаца): ``` Go в production - два проекта. Samokat.tech (2023-2025): спроектировал и вывел в production платформенный Go-сервис, который читал события из Kafka и раздавал их через WebSocket - общий транспорт для трёх продуктов, запущенных с нуля (~500 соединений, ~50 событий/сек, 800K+ пользователей). SeoPult (2014-2015): высоконагруженный HTTP-краулер на Go с RPC-доступом. База - МАИ, "Математик, системный программист" (прикладная математика и физика). Коммерческого C++ нет, опыт виртуализации и OpenStack на уровне физических серверов отсутствует; с инфраструктурой работал как инженер (Kubernetes, Docker, Prometheus, Grafana, OpenTelemetry, GitLab CI/CD). ``` ## Заготовки на вероятные следующие вопросы Все ответы построены на реальной фактуре из master-резюме, без завышения. Проверять по `profile/cv.yaml`. **Про управление командами от 20 человек (ожидаемый вопрос, критичный гэп):** ``` Прямого опыта управления командой 20+ человек у меня нет - честно. Что есть: Team Lead и Product Team Lead (команды разработки, включая онбординг, кодревью, процессы, найм в свою команду) и Ruby Practice Lead - роль, где я отвечал за инженерные стандарты и развитие практики поверх нескольких команд: определил стандарты кодревью и competency matrix по Ruby, которые приняли в разных командах. В Raiffeisen как Technical Lead вёл техническое лидерство в трёх кросс-функциональных командах (C4-документация на ~50 сервисов, распределённый трейсинг на 20 сервисов, миграция до ~80%). В Samokat DDD-стандарт и процесс работы с техдолгом приняли несколько продуктовых команд. То есть строил процессы и стандарты на несколько команд - но через техническое лидерство, а не через управление 50 людьми по оргструктуре. ``` **Про SLA и надёжность платформы:** ``` Формальных SLA платформы как продукта я не держал, но отвечал за надёжность и производительность конкретных production-систем: Dixy - inventory-синхронизация 2000 магазинов, ~1000 RPS, 800 ГБ+ данных, ускорение синхронизации в 10 раз (20 мин -> 2 мин) через миграцию ClickHouse -> PostgreSQL и параллельную инкрементальную обработку; Raiffeisen - распределённый трейсинг на 20 сервисов (OpenTelemetry) и перестройка C4-документации на ~50 сервисов; Samokat - 3 продукта с нуля на 800K+ пользователей. Подход к измеримости: сначала наблюдаемость и метрики на границах, потом целевые уровни и бюджет ошибок. ``` **Про legacy и влияние на production:** ``` Практика есть: в Balance Platform вёл выделение сервисов из монолита (monolith -> microservices), в Raiffeisen работал с зависимостями между ~50 сервисами - карта зависимостей через C4, распределённый трейсинг для поиска реальных связей в рантайме, чтобы решения по устранению legacy-зависимостей опирались на факты, а не на схемы. Плюс в Samokat ввёл лёгкий процесс работы с техдолгом, который приняли несколько команд. ``` **Про архитектуру под быстрый рост числа сервисов:** ``` Опыт ближе к прикладному уровню, но релевантный: DDD-границы и event-driven подходы (Kafka), внутренний RPC-протокол и in-house framework "Core", который приняли несколько сервисных команд, микрофронт платформы на Go (Kafka -> WebSocket) как общий транспорт для нескольких продуктов. В инфраструктуре - Kubernetes, Docker, GitLab CI/CD (пайплайны ~30 мин -> ~5 мин на 2 командах), Prometheus, Grafana, OpenTelemetry. ``` **Почему интересна роль:** ``` Мне интересна облачная инфраструктура как направление: последние годы я строил системы, которые живут поверх инфраструктуры, а хочу отвечать за слой под ними - платформу, надёжность, процессы и команды. Готов честно обсудить, что низкоуровневого опыта (виртуализация, OpenStack, железо) у меня нет и эту часть придётся набирать - либо вместе с командой, либо через вход в роль на технической позиции. ``` ## Про роли в скрининге - В первом вопросе роль названа "тимлид" - это снижает профиль под вакансию CTO, но честно соответствует фактуре. Если компания позовёт дальше, расхождение ожиданий лучше снять на первом созвоне. - Не стоит дописывать себе CTO/Head of Engineering в этом чате: ИИ-помощник вытянет это как требование, и на созвоне расхождение станет явным. ## Статус - 12.09.2026 - отклик отправлен, ИИ-скрининг идёт: 2 вопроса пройдено, готов ответ по C++/Go. ⏳ Ждём следующий вопрос.