Наша рубрика «Где работать в IT» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях.
Сегодня мы расскажем о Garage Eight — международной продуктовой IT-компании, которая с 2011 года разрабатывает экосистему инвестиционных продуктов. За 15 лет на рынке Garage Eight выросла из стартапа до компании с командой 370+ человек, сохранив дух свободы и умение быстро принимать решения. 25+ продуктовых команд разрабатывают финансовые продукты экосистемы Garage Eight, у которой в 2026 году сотни тысяч активных пользователей в 183 странах.
А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в IT.
Кто отвечал на вопросы
Обо всех процессах в компании нам подробно рассказали:
Полина Боровская, HR-маркетолог
Денис Радченко, Frontend Lead
Ирина Руттенберг, Recruitment Lead
Ирина Морозова, HR BP Functional Leads & Teams
Об условиях работы
На вопросы отвечала Полина Боровская
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
У нас стандартный график 5/2, начало дня гибкое: можно выбрать комфортное время, главное — быть на связи в общий слот с 12:00 до 17:00, чтобы у команд было время для встреч и совместной работы.
У нас нет культуры переработок. Для нас сильный результат — это не когда человек героически живет в ноутбуке и делает большой объем задач по принципу «лишь бы сделать», а когда команда предлагает ценные для бизнеса, продукта или пользователей идеи и доводит их до подтвержденного результата
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Наши видовые офисы находятся в Санкт-Петербурге и Москве. Мы хотели создать пространства, куда комфортно приходить: поработать, обсудить идеи, быстро синкануться с командой и поймать рабочий настрой. Поэтому в офисах есть всё необходимое: рабочие опенспейс-зоны, переговорки, креативные пространства, кухни и кофе-поинты, зоны отдыха, спортивные уголки и душевые.
Для дофаминового буста добавили детали: свежие цветовые акценты, стильные элементы интерьера, живые цветы и хороший свет. С первого дня выдаем современную рабочую технику на выбор, чтобы можно было быстро включиться в работу.
И да, мы подумали не только о комфорте в офисе, но и о дороге до него. Нашим сотрудникам в питерском офисе доступен бонус на выбор: корпоративное такси до офиса, денежная компенсация или парковка. Ну а начинаем мы офисный день в питерском офисе с бесплатных завтраков от нашего повара Олега!
Есть ли возможность удалённой работы?
Полностью удалённого формата у нас нет. Мы работаем в гибридном формате: три дня в неделю в офисе, два дня можно удалённо. Это один из наших принципов эффективной работы: живое взаимодействие помогает командам быстро обмениваться контекстом, обсуждать гипотезы, смотреть на данные, вместе принимать решения и в конечном счёте сокращать time-to-market и поставку ценности пользователям.
Какой социальный пакет получают сотрудники?
В наш соцпакет входит ДМС «ультра всё включено» — со стоматологией, подключением родственников, чекапом организма, КТ, ведением беременности и другими радостями взрослой жизни. Также компенсируем психотерапию и больничные.
Поддерживаем обучение и развитие: в компании есть групповые занятия английским, штатный преподаватель и разговорные клубы. Отправляем на внешние курсы и поддерживаем тех, кто хочет развивать личный бренд: выступать, писать статьи и делиться экспертизой. Спорт тоже не забыли: частично компенсируем занятия, играем в волейбол, футбол и настольный теннис, участвуем в забегах и sup-сплавах.
Для сотрудников, которые переезжают, есть релокационный пакет с покрытием перелета и первого месяца проживания для сотрудника и его семьи.
А ещё у нас активная корпоративная жизнь: два раза в год собираемся на масштабные корпоративы, а каждый месяц проводим «Гаражную пятницу» — с караоке, мастер-классами и тематическими активностями. Придумываем свои креативные форматы: Garage Creative Awards — конкурс креативных идей, Light Night Ad — наша версия «Ночи пожирателей рекламы», Fuckup Night — встреча, где делимся своими рабочими ошибками и выводами.
По внутренним и внешним исследованиям мы видим, что соцпакет у нас и правда топовый. В рейтинге IT-компаний, который проводили Хабр и «Экопси», сотрудники оценили наши бенефиты, страховку, корпоративную культуру выше рынка. А по внутреннему опросу вовлеченности 95% ребят довольны атмосферой в компании.
Для нас это важный сигнал: значит, «плюшки» работают не только в оффере, а действительно делают жизнь сотрудников удобнее и помогают получать больше от работы, чем просто зарплату.
Какие бонусы, премии и компенсации предусмотрены в компании?
Ежегодно мы проводим анализ рынка зарплат и сверяемся с ним, чтобы оставаться конкурентными. Также проводим оценку эффективности: ретроспективно смотрим, какие команды действительно повлияли на бизнес-метрики и достигли амбициозных результатов.
По итогам оценки выплачиваем бонус. Его размер зависит от результатов команды и финансовых результатов компании.
Еще дарим подарки к рабочим юбилеям — мы ценим, когда люди остаются с нами надолго, растут вместе с компанией и помогают делать общий результат.
Какие есть перспективы для образования и личного развития у сотрудников?
Наши сотрудники растут внутри компании: меняют роли, усиливают экспертизу за счет индивидуальных планов развития, берут на себя более сложные задачи, и развивают личный бренд через выступления, статьи и профессиональные мероприятия. Например, за прошлый год 10% сотрудников получили повышение или сменили роль.
Для повышения квалификации оплачиваем внешние курсы и программы — в том числе в MADS, Британской высшей школе дизайна, «Икре» и Bang Bang Education. Если видим связь с задачами бизнеса, поддерживаем и более масштабное обучение: например, уже оплачивали нашим ребятам MBA и зарубежную программу в Miami Ad School. Также, отправляем наших сотрудников на топовые отраслевые конференции уровня HighLoad.
Для нас важно, чтобы сотрудники не просто закрывали задачи из бэклога, а понимали продукт, его ценность и свое влияние на результат. Поэтому в работе много внимания уделяем исследованиям, экспериментам, метрикам и OKR. Идея может звучать амбициозно, но по-настоящему успешной она становится только тогда, когда приносит подтвержденную пользу бизнесу, продукту или пользователям.
О найме
На вопросы отвечала Ирина Руттенберг
Во сколько этапов проходит наём и что на них ожидает соискателя?
Процесс найма зависит от конкретной позиции и уровня роли, но обычно включает 3–4 этапа: HR-скрининг, техническое интервью, тестовое задание (если необходимо) и знакомство с командой или топ-менеджментом. На всех этапах кандидата сопровождает рекрутер, чтобы процесс был максимально комфортным и прозрачным.
1. HR-скрининг.
На первом этапе рекрутер подробнее изучает опыт кандидата, его мотивацию, задачи, с которыми он работал, а также интересующие предметные области. Обязательно обсуждается технический стек: с какими технологиями работал кандидат, какие версии использовал и какие задачи решал в рамках этого стека. Иногда уже на этом этапе могут задаваться некоторые технические вопросы.
2. Техническое интервью.
На техническом интервью более глубоко оцениваются hard skills кандидата и его практический опыт работы. На этом этапе обязательно присутствуют технические эксперты с нашей стороны, а также сопровождающий рекрутер. Здесь же могут быть проверены менеджерские компетенции и не только. И конечно мы даем детальное представление о своей предметной области, проектах, которые в настоящий момент ведет, задачах роли, на которую мы ищем человека и возможных направлениях развития для кандидата в будущем.
3. Тестовое задание (ТЗ).
Тестовое задание используется не для всех ролей. Чаще всего оно актуально для дизайнеров, копирайтеров, motion-дизайнеров и других специалистов, которым важно показать практические навыки. Особенно это полезно в случаях, когда кандидат не может предоставить релевантное портфолио из-за NDA.
Тестовое может выдаваться как до, так и после технического интервью. Часто мы выдаем ТЗ после технического интервью, что позволяет сократить объем задания и проверить только те навыки, которые не удалось полноценно оценить на интервью. Обычно тестовое включает примеры задач, максимально приближенные к реальной работе и будущему функционалу для данной роли, чтобы кандидат мог лучше понять контекст и специфику позиции.
4. Live coding.
Для разработчиков и аналитиков на интервью может использоваться live coding — решение задачи при помощи написания кода в реальном времени. Это помогает оценить подход кандидата к решению задач, техническое мышление и практические навыки.
Как отличается подход к найму в зависимости от позиции и стека?
Подход к оценке кандидатов зависит от типа позиции. Для менеджерских ролей основной акцент делается на софт скилах, умении работать с командой и управленческих компетенциях. Для технических специалистов приоритетнее hard skills и глубина экспертизы.
Также в зависимости от уровня позиции может меняться количество этапов и глубина оценки. Например, при найме лидов и топ-менеджеров добавляются встречи с руководством компании для передачи бизнес-контекста и дополнительной оценки кандидата.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Мы не разбрасываемся талантами, поэтому всегда используем индивидуальный подход к каждому соискателю. Но, безусловно, нужен мэтч кандидатов с нашей корпоративной культурой и процессами, которые существуют в компании.
Как происходит онбординг нового сотрудника?
Онбординг начинается задолго до выхода сотрудника в компанию. После принятия оффера кандидатом, внутри команды формируется его будущий план адаптации. Этот процесс сопровождает нанимающая команда, будущий онбордер сотрудника, HR и рекрутер, который осуществлял подбор. В рамках создания плана адаптации определяются задачи на испытательный срок, критерии его успешного прохождения, а также ключевые ожидания от роли.
В нашей компании выстроена полноценная система онбординга с чек-поинтами и регулярной синхронизацией сотрудника с командой. В процессе адаптации сотрудника сопровождают HR и его непосредственная команда, включая онбордера, а часть процессов поддерживается автоматизированными системами. Автоматизация процесса не дает забыть о ключевых встречах в рамках этого процесса, регулярном сборе фидбеков со всех участников процесса, а также своевременной корректировке плана, если требуется.
О команде
Какая методология разработки у вас используется и почему?
Денис: Мы работаем по Agile-методологии. Для нас это способ быстрее договариваться, проверять гипотезы и адаптироваться под условия рынка.
Главный фокус — на людях и взаимодействии: внутри команд, между командами и со стейкхолдерами. Мы используем спринты, планирование, ретро, регулярные синки и OKR — это часть нашего подхода к современному управлению проектами. Так команды понимают не только что делать, но и зачем: какой результат задача даст продукту, бизнесу и пользователям.
У команд есть пространство для инициативы. Мы приветствуем проверку разных фреймворков и подходов, если они помогают работать лучше. При этом у нас есть стандарты, которые комьюнити регулярно пересматривает и обновляет. Так сохраняем баланс между творчеством, скоростью и прозрачными процессами.
Каковы размеры и структуры команд?
Денис: В среднем в команде 5-6 человек. Обычно в составе есть PO + Backend-, Frontend-разработчики и QA. Часто к команде подключаются Android- и iOS-разработчики, дизайнеры, иногда — аналитики.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Денис: У нас есть технические матрицы компетенций. В них описано, какие навыки, уровень самостоятельности, зона ответственности и масштаб задач соответствуют каждому грейду.
Такой подход помогает смотреть не только на технические навыки, но и на масштаб влияния: какие задачи человек берет, как принимает решения, насколько автономно работает и какой результат дает команде и продукту.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Денис: В большинстве случаев у команды есть PO — и это в первую очередь продуктовый специалист. Он отвечает за продуктовый фокус, приоритеты и ценность решений для пользователей и бизнеса.
Как часто люди меняют команды?
Денис: Смена команды у нас скорее редкое явление, но ротации все же случаются. Обычно это связано с развитием: хочется попробовать другие задачи, усилить компетенции или перейти туда, где сейчас больше возможностей для роста. Иногда переход помогает аккуратно решить сложную ситуацию в команде или пересобрать нагрузку.
В целом люди чаще остаются в одной команде до ее переформирования, но карьерные движения внутри компании происходят регулярно — например, когда сотрудник вырастает из линейной роли в менеджерскую.
Что важнее, софт-скиллы или хард-скиллы?
Денис: Если говорить про разработчиков, то харды — база. Без сильной технической экспертизы сложно качественно делать основную работу.
Но софты идут совсем рядом. Для нас важно, как человек взаимодействует с командой, принимает обратную связь, договаривается и относится к общему результату. Даже очень сильная экспертиза раскрывается лучше, когда с человеком можно спокойно обсуждать решения, спорить по делу и вместе двигать продукт вперед.
Поэтому мы смотрим на баланс: важны и профессиональные навыки, и умение работать в команде.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Денис: В зависимости от роли около трети рабочего дня может уходить на встречи: командные синки, обсуждения со стейкхолдерами, внешние встречи. Во фронтенд комьюнити у нас параллельно идет примерно 5-7-м встреч в спринте.
Полина: У нас есть внутренние гайды, которые помогают делать встречи более эффективными — например, разделяем обязательных и опциональных участников, стараемся завершать встречи чуть раньше, чтобы не ставить их вплотную друг к другу. Плюс у нас принято давать фидбек, если встреча прошла неэффективно, и не подключаться, если непонятна повестка или ваша роль.
Как вы боретесь с выгоранием сотрудников?
Ирина Морозова: Мы обращаем внимание на состояние сотрудников, поэтому регулярно сверяемся с командами по нагрузке, задачам и фидбеку. Например, четыре раза в год проводим квартальные перформанс встречи — это помогает вовремя заметить, если человеку стало тяжело, скучно или он уперся в потолок.
Также составляем PDP и карьерные треки, запускаем HR-проекты для поддержки сотрудников и развития команд.
Если видим, что человек устал или потерял интерес, разбираемся в причине. Иногда помогает сменить фокус, взять новые задачи, перейти в другую команду или пересобрать зону ответственности.
Дополнительно поддерживаем через бенефиты: ДМС, психолога и компенсацию спорта. Видим, что эта поддержка работает: в рейтинге IT-компаний от Хабра и Экопси сотрудники оценили нашу заботу о физическом и ментальном здоровье выше рынка.
А еще мы против переработок и за регулярные отпуска — иногда человека правда нужно не сильнее мотивировать, а просто отправить отдыхать.
О технологиях
На вопросы отвечал Денис Радченко
Какие языки, фреймворки и библиотеки используются на проекте?
Мы ценим инновации и работаем с сильным технологическим стеком и выбираем инструменты под задачу.
Если смотреть на весь код, больше всего у нас написано на PHP — примерно 70%. Это основной язык для значительной части backend-разработки, и он по-прежнему хорошо закрывает много продуктовых задач.
В backend также используем Golang, C++, Symfony, Percona, PostgreSQL, RabbitMQ, Python и Node.js — выбираем инструмент под конкретную задачу, нагрузку и контекст сервиса.
На frontend работаем с JavaScript, TypeScript (React/Vue). В мобильной разработке используем Kotlin, Coroutines/Flow, Koin, MVVM/MVP для Android и Swift, Combine, MVVM, Fastlane для iOS.
Что вы можете рассказать об архитектуре проектов?
У нас микросервисная архитектура: сейчас в системе 350+ микросервисов. Такой подход помогает командам быстрее развивать отдельные части продукта и масштабировать решения. Много внимания уделяем архитектурным договоренностям, стабильности и понятным зонам ответственности команд.
Какая у вас принята политика код-ревью?
У нас в комьюнити есть общие договоренности по правилам ревью. На merge request назначаются минимум два ревьюера на MP, нужно получить не менее 2-х апрувов от фронтенд разрабочиков.
Если у ревьюера не получается посмотреть код вовремя, он пишет об этом в треде, чтобы задача не зависала.
Обратная связь должна быть конкретной: если есть замечание, важно объяснить, в чем проблема и как ее можно исправить. Дизлайк ставим только в серьезных случаях — например, если пропала бизнес-ценность функционала или код сильно расходится с нашими архитектурными и инфраструктурными договоренностями.
Если по решению не получается договориться, подключаем второго ревьюера или выносим вопрос в комьюнити. Еще следим, чтобы merge request был адекватного размера и не содержал лишней функциональности. Ну и базовое: на ревью спорим про код, а не друг с другом.
Как тестируется код?
Перед передачей задачи разработчик делает self-review и авторское тестирование. Это помогает поймать очевидные ошибки еще до того, как фича уйдет в QA.
Дальше функциональность передается команде QA и разворачивается на dev-стендах, которые максимально приближены к продакшену.
Как устроен процесс документации и ведения базы знаний на проектах?
Большая часть документации живет прямо в проектах — рядом с кодом и процессами, к которым она относится. Так проще поддерживать ее в актуальном состоянии.
Для общих материалов, архитектурных договоренностей и ADR у нас есть внутренняя база знаний. Сейчас также работаем над автогенерацией документации с помощью ИИ — хотим, чтобы она обновлялась быстрее и меньше зависела от ручного труда.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Все зависит от проекта и от того, что именно считать легаси. В новых проектах легаси нет, чем дольше живет проект, тем больше накапливает легаси. В среднем можно ориентироваться примерно на 30% легаси-кода, но цифра отличается от команды к команде.
Как реагируете на сообщения пользователей о багах и просьбы по улучшению сервисов/продуктов?
У нас есть команда, которая создает задачи, оценивает их срочность и помогает определить, какая команда отвечает за конкретный функционал.
Если проблема критичная, ее могут быстро подсветить нужной команде и передать в работу в приоритетном порядке. Дальше команда сама оценивает, когда и как лучше исправить баг или доработать сервис: смотрит на влияние на пользователей, продукт и бизнес.