Наша рубрика «Где работать в IT» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях.
В этом выпуске мы расскажем про компанию DatsTeam, которая разрабатывает рекламные платформы, игры, мобильные приложения и финтех-решения. В команду продуктовой разработки входят PM, PO, инфраструктура, DevOps, SecOps, QA. Основные стеки — JAVA Spring, PHP Symfony, React, iOS, Android.
А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в IT.
Кто отвечал на вопросы
Обо всех процессах в компании нам подробно рассказали:
Дмитрий Рудопысов
Java TeamLead Datsteam
Григорий Терешко
PM TeamLead Datsteam
Ирина Амирсултанова
DevRel Datsteam
Мариэтта Парсекян
HRD Datsteam
О компании
Datsteam — группа компаний, которая разрабатывает собственные продукты: рекламные и игровые платформы, мобильные приложения, платежные сервисы и финтех-решения и владеет собственным рекламным агентством в сфере партнерского маркетинга. Продукты охватывают рынок с обширной географией.
В Datsteam одна из самых успешных команд коммерческой разработки, где более 800 разработчиков смогли сделать карьеру. Средняя продолжительность работы в компании в команде разработки — 2,5 года, но лиды и техлиды работают в компании по 5, 7, 10 лет.
Публичная оценка компании на «Хабр Карьере» в 2025 году — 4,86 из 5. Сотрудники особенно ценят Datsteam за комфортные условия труда, отношения с коллегами и возможность профессионального роста. Посмотреть оценки и почитать отзывы сотрудников можно в профиле Datsteam на «Хабр Карьере».
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Ирина: Мы работаем по московскому времени, но так как команда распределена по разным ГЕО, у нас гибкие часы, чтобы было удобно каждому: сотрудники начинают работать с 8:00 до 11:00 и заканчивают с 17:00 до 21:00. Самые активные рабочие часы, когда решается большинство вопросов, — это 12:00–18:00, в это время нужно быть на связи, чтобы не подводить команду. Самое главное — чтобы сотрудник успевал выполнить свою часть задач в рабочее время, а об остальном всегда можно договориться с лидом.
Дмитрий: Переработки у нас бывают как форс-мажорные, так и по желанию сотрудника — например, вы хотите продолжить работу над проектом во время зимних каникул. В любом случае все переработки 100% оплачиваются.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Ирина: Большинство сотрудников работают удаленно — мы всегда предоставляем необходимое рабочее оборудование по запросу.
Но есть и те, кто любит приезжать в офис, и у нас есть все условия для их комфортной работы:
офис в центре Москвы;
рабочее оборудование по запросу;
комфортная кухня;
просторный опенспейс;
летняя веранда, на которой можно поиграть в настольные игры, покурить кальян, провести встречу с коллегами за пиццей;
регулярные офлайн-активности — турниры, кинопросмотры, организация праздников.
Дмитрий: Разработчики обычно сами выбирают, на чем им работать. Кто-то предпочитает MacBook, кто-то выбирает что-то на Windows/Linux. Тут у нас довольно свободно.
Есть ли возможность удаленной работы?
Ирина: Мы работаем удаленно и поддерживаем формат, при котором каждый сотрудник может работать из любого удобного места: главное, чтобы была стабильная связь и возможность эффективно взаимодействовать с командой.
Каждый сотрудник сам выбирает комфортный формат работы.
Какой социальный пакет получают сотрудники?
Ирина: У нас есть ДМС по России, рассрочка на годовые абонементы в несколько популярных сетевых фитнес-клубов, занятия йогой, клуб любителей яхтинга и бесплатное посещение одного из лучших сквош-клубов Москвы.
Помимо этого, наши сотрудники и их близкие могут воспользоваться более «досуговыми» корпоративными предложениями — от образовательных платформ и профессионального обучения («Яндекс Практикум», Skillbox) до поиска себя в новых хобби (мастер-классы по кулинарии и лепке, обучение игре на музыкальных инструментах, съемке Reels, рисованию и прочему).
На корпоративном портале постоянно проходят челленджи и активности, за которые можно получить наши внутренние баллы и потратить их на технику и мерч в корпоративном магазине. Также мы часто проводим розыгрыши ценных призов для сотрудников.
Какие бонусы, премии и компенсации предусмотрены в компании?
Ирина: Весь доход сотрудника закладывается в его оклад, эта сумма пересматривается по мере роста компетенций и повышения грейда. У нас принят непрерывный процесс performance review: это значит, что сотрудник может в любой момент при достижении определенных целей пройти оценку и претендовать на более высокий грейд и более высокий доход в соответствии с этим грейдом. Также мы анализируем рынок и индексируем зарплаты, что позволяет держать их на достойном конкурентом уровне.
Какие есть перспективы для образования и личного развития сотрудников?
Ирина: Для начала у нас есть образовательный ресурс — Академия Datsteam. Там целое море разных курсов, видео, записей встреч, аудио- и электронных книг. Мы всегда поддерживаем сотрудников, которые хотят в качестве спикера участвовать в топовых конференциях или создавать крутые проекты для IT-сообщества. Академия — самый простой путь изучить что-то новое или подтянуть свои знания.
Вообще, у нас можно расти в разных направлениях, необязательно линейно качать свой грейд. Например, многим ребятам нравится наращивать техническую экспертизу, не переходя на роль менеджера. Было много кейсов, когда сотрудники переходили в другой отдел и продолжали работу уже по смежной специальности. Ну а если хочется расти вверх — тоже не вопрос, у нас есть внутренние курсы для тимлидов от нашего CIO.
Все сотрудники разработки участвуют в performance review, на котором составляется план развития и анализируется карьерный трек в компании. Также они непрерывно получают обратную связь от коллег, лидов и СТО. Все это проходит автоматизированно на корпоративном портале. Ну и, конечно, мы проводим встречи one-to-one, на них можно обсуждать промежуточные результаты и заранее скорректировать вектор развития.
Григорий: Недавно из-за большого количества команд и различий в их процессах я столкнулся с проблемой корректного подсчета метрик. Я пришел к своему руководителю с предложением пройти курс Kanban System Design от Kanban University — и мне без лишних вопросов оплатили 50% обучения. После курса я смог выстроить грамотную систему подсчета метрик, и сразу стало ясно, над чем стоит поработать. Как итог, выиграли и команды, и весь проект.
О найме
Отвечает Мариэтта Парсекян
Во сколько этапов проходит наем и что на них ожидает соискателя?
Сейчас у нас два основных этапа, которые проходят все кандидаты. Все начинается со знакомства с рекрутером, на котором становится понятно, насколько мы мэтчимся по ценностям и ожиданиям. Мы обсуждаем стек, опыт, достижения и делаем презентацию проекта и компании. Это интервью занимает в среднем от 40 до 60 минут.
Техническое интервью проводят уже непосредственно тимлиды команд, в которых открыт поиск. Знакомятся с кандидатом, рассказывают про команду и задачи, проверяют технические знания и харды во время лайвкодинга. Все это занимает час-полтора.
Для некоторых позиций могут быть дополнительные этапы интервью. Например, в финтех-проектах для позиций senior-разработчика на этапе интервью с HR есть скрининг по culture fit, может быть назначено дополнительное интервью с СТО и инжиниринг-менеджером. Для поиска на лидовые и C-level-позиции мы добавляем дополнительные встречи с командой и руководящим составом. Все опционально. Мы стараемся не растягивать процесс поиска, при этом сохраняя качество найма.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Мы не используем практику тестовых заданий при найме разработчиков. Думаем, что с появлением ИИ эта практика изжила себя. У нас может быть скрининг из 5–8 вопросов до техинтервью. На техинтервью по ряду позиций используем лайвкодинг.
Как отличается подход к найму в зависимости от позиции и стека?
На позициях senior и выше, особенно если нужен специфичный стек или навык, поиск, конечно, более сложный, это скорее хантинг. Интервью более глубокое, если можно так сказать. Но в остальном у нас одинаковый подход для всех позиций и стека. На сложных позициях или проектах могут быть добавлены скрининги или дополнительный этап интервью, как я говорила выше. Грейд мы определяем после технического интервью. Далее сравниваем грейд с нашей вилкой по сетке грейдов, мэтчим с ожиданиями кандидата и стараемся сделать классный оффер.
Какая фраза кандидата на собеседовании точно заставит вас выкинуть его резюме?
«Давайте без этих ваших вопросов, я готов общаться дальше с тимлидом» ?
Кого последнего вы уволили и почему?
Из последнего — уволили лоуперформера. И такое тоже встречается, порой это связано с выгоранием сотрудника, а может, просто не совпали ожидания. А бывает и обман со стороны кандидата, когда накидывают себе опыта. Мы научились проверять это уже на испытательном сроке, автоматизировав и геймифицировав подтверждение грейда, который соискатель получает на этапе технического интервью.
Как происходит онбординг нового сотрудника?
Тут у нас целая система, которая включает оформление, подключение и разные welcome-активности — все эти этапы курирует менеджер по адаптации у каждого нового сотрудника лично, независимо от того, какой формат работы он выбрал — офлайн или удаленку.
Конечно, у нас есть welcome-курс, как и во многих компаниях, но у нас это целый игровой квест. Вместо «чтения и теста» новичок проходит интерактивное путешествие, знакомится с процедурами и правилами компании в формате игры. А еще у нас классный welcome-пак ?
О команде
Отвечает Григорий Терешко
Какая методология разработки у вас используется и почему?
Чаще всего мы используем гибкие методологии Scrum и Kanban, но не в их «книжном» виде. Мы берем из них только то, что действительно нужно в данный момент для команды и проекта. Например, если продукт только запускается и команда небольшая, мы начинаем со Scrum: короткие спринты, четкие цели, плотная синхронизация. Это помогает быстро разогнаться. А когда появляется MVP, продукт начинает расти, а вместе с ним и команда — тогда часто переходим на Kanban. Он позволяет гибко управлять приоритетами и меньше зависит от формальных рамок. Вообще, у нас приветствуется использование любой методологии, главное, чтобы команде было комфортно.
Каковы размеры и структуры команд?
Размер команд у нас варьируется в зависимости от проекта — где-то это 4–5 человек, а где-то 15+, если продукт масштабный. Но в целом мы стараемся не раздувать команды, чтобы не терять фокус и управляемость.
Если команда начинает разрастаться, то внутри команды органично взращиваются новые тимлиды, и впоследствии мы разделяем ее на несколько более компактных юнитов — обычно это независимые кросс-функциональные команды, которые продолжают работать над одним продуктом.
В составе каждой продуктовой команды, как правило, есть тимлиды бэкенда, фронта, QA, аналитик и продакт. Иногда добавляются дизайнеры. Также за каждым продуктом закреплена своя команда инфраструктуры, которая отвечает за стабильную работу, CI/CD, мониторинг и окружения.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и сеньоров?
Первоначальный грейд определяется на собеседовании, но это далеко не финальная точка. В процессе работы грейд может быть пересмотрен, для этого у нас проходят ежегодные performance review.
При этом необязательно ждать целый год: если человек растет, берет на себя больше ответственности, проявляет инициативу, показывает зрелость в принятии решений — он может подать заявку на пересмотр грейда в любой момент. Это абсолютно нормальная и прозрачная практика.
Также, чтобы поддерживать рост, мы развиваем внутреннюю инфраструктуру обучения. У нас есть:
записи конференций, митапов и курсов;
собственные программы обучения, например junior» и «Teamlead middle»;
карта компетенций и трек развития в портале CoDev, где можно самостоятельно развивать компетенции и мониторить свой прогресс.
Развитие у нас — это про возможность каждому самому задать комфортный темп и направление для достижения новых высот.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Команды разработки всегда возглавляет тимлид/CTO. Если говорить о кросс-функциональных продуктовых командах, где есть продакт, аналитики и дизайнеры, то там решение принимается совместно: каждый член команды может высказаться и быть услышанным. Мы вообще культивируем среду, где роль не мешает мнению и все работают на результат, а не на иерархию.
Как часто люди меняют команды?
Не скажу, что у нас переходы между командами происходят часто, но такое случается.
Причины бывают разные: кому-то интересен новый проект и хочется приложить к нему руку, кто-то чувствует, что на текущем проекте достиг потолка и ищет возможности для роста.
Чаще всего переходы происходят целыми командами, например, когда проект завершен или ушел на поддержку, а команда готова к следующему вызову.
Что важнее, софт-скилы или хард-скилы?
Мне, как проджекту, конечно, хочется сказать «софт-скилы». Но тут я бы несколько слукавил. На деле важен баланс: мы все работаем в команде, где один человек ставит задачу, другой ее описывает, третий реализует, четвертый ревьюит, а пятый тестирует. Поэтому важна совокупность навыков.
Также мы всегда поощряем развитие сотрудников. Если ты нашел курс или обучение, которое поможет прокачать твои скилы или принесет пользу команде/продукту, то можно рассчитывать на частичную компенсацию, до 50%. Главное — желание развиваться и применять новое в работе.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Это сильно зависит от роли. Если говорить о разработчиках и тестировщиках, у них в основном проходят scrum-церемонии и демо. А вот у тимлидов, СТО и проджектов встреч и созвонов, конечно, больше.
Мы не встречаемся ради галочки: когда вопрос можно решить в паре сообщений, созвон не нужен. Но если встреча все-таки проводится, то только с четкой повесткой и конкретной целью. На каждой встрече будет фасилитатор, чаще всего это проджект. Его задача — следить, чтобы разговор шел по теме, не растягивался и приносил результат. Мы уважаем и ценим время друг друга.
Как вы боретесь с выгоранием сотрудников?
Мы не ждем, пока человек выгорит, стараемся замечать такие сигналы заранее. Чтобы избежать выгорания, руководители регулярно проводят one-to-one, где обсуждают не только задачи, но и общее состояние сотрудника. Мне, например, такие встречи очень помогают ?
Если сотрудник устал или перегружен, ему всегда пойдут навстречу — мы очень гибкие в этом плане. Любые активности всегда могут подхватить коллеги, а сотрудник пойдет в заслуженный отпуск. Главное, чтобы люди не боялись говорить об этом, это мы всегда пытаемся донести до коллег.
Плюс у нас много активностей вне работы с коллегами: спорт, клубы по интересам, ивенты, тимбилдинги. Все это помогает не только переключиться, но и почувствовать, что ты часть команды, где тебя ценят и всегда ждут.
О технологиях
Отвечает Дмитрий Рудопысов
Какие языки, фреймворки и библиотеки используются на проекте?
Стек: Java + Spring, микросервисы. В качестве БД у нас MySQL. Для быстрого доступа к данным временного характера мы используем Redis. Большая часть интеграций между микросервисами у нас на RabbitMQ, но есть как внешние интеграции через Kafka, так и внутренние в той части, где необходима последовательность сообщений вкупе с возможностью автоматической балансировки.
Что вы можете рассказать об архитектуре проектов?
Наш проект больше похож на распиленный монолит, но архитектура потихоньку улучшается.
Какая у вас принята политика код-ревью?
Код-ревью носит рекомендательный характер. У нас давно нет джунов в команде, и контролировать сотрудников нет особой нужды.
Как тестируется код?
У нас есть большая часть интеграционных и юнит-тестов.
Как устроен процесс документации и ведения базы знаний на проектах?
У нас тут есть некоторая специфика. Документация находится где-то между «описано в Confluence вместе с бизнес-логикой и моделями» до «не задокументировано вообще».
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Проект по всем признакам относится к легаси, но при этом мы по возможности постоянно обновляем и версию Java до LTS-версии, и версии всех используемых библиотек. При этом у нас нет никакой священной коровы, которую нельзя трогать. Мы и интеграции изменяем, и БД перерабатываем.
Как реагируете на сообщения пользователей о багах и на просьбы по улучшению сервисов/продуктов?
Баги фиксим, для обратной связи есть product owner.
