Наша рубрика «Где работать в 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% легаси-кода, но цифра отличается от команды к команде.

Как реагируете на сообщения пользователей о багах и просьбы по улучшению сервисов/продуктов?

У нас есть команда, которая создает задачи, оценивает их срочность и помогает определить, какая команда отвечает за конкретный функционал.

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