company_banner

Где работать в ИТ в 2020: Mindbox

    Герой нового выпуска «Где работать в ИТ» — платформа автоматизации маркетинга Майндбокс. На наши каверзные вопросы ответили технический директор Никита Прудников и директор по информационным технологиям Игорь Кудрин. Ребята рассказали об эволюционном развитии команд, о том, как нанимают спецов и какие условия работы для них создают. А ещё о том, что вся компания (а не только разработка) работает по принципам эджайла и самоуправления.

    На Хабр Карьере сотрудники оценили Майндбокс на 4,6 из пяти, и у компании есть неплохие шансы попасть в наш ежегодный рейтинг лучших работодателей, который выйдет в начале следующего года.

    Оценивайте своих работодателей на Хабр Карьере, чтобы поделиться мнением с теми, кто ищет работу в ИТ. Ваша оценка останется анонимной.

    оценить компанию

    Навигация по статье:


    О Mindbox

    Компания с 2006 года занимается автоматизацией маркетинга для электронной коммерции, ритейла и других B2C-компаний с десятками и сотнями тысяч клиентов. В 2020 году доросли до 115 человек, из которых половина — разработчики. 

    Вы точно сталкивались с услугами Майндбокс, если делали покупки в издательстве «МИФ», в Ситилинке, в аптеках «Ригла», в «Детском Мире» или в Связном; ели в Burger King, «Додо Пицце» или KFC; брали машину или самокат в Делимобиле… Список можно продолжать довольно долго — ребята входят в десятку крупнейших SaaS-сервисов для бизнеса России.

    Если посмотреть подробнее на оценку на Хабр Карьере, увидим три лидирующие качества, за которые сотрудники так любят Майндбокс: комфортные условия работы, профессиональный и карьерный рост. Вот ссылка на подробную оценку компании в 2020 году.

    Текущая оценка Mindbox на Хабр Карьере
    Текущая оценка Mindbox на Хабр Карьере

    Про условия работы

    Какой в вашей компании сложился рабочий график и какое отношение к переработкам?

    Никита (технический директор): У нас свободный рабочий график: мы не следим за рабочими часами, а смотрим на результат. Начинать можно хоть в 8:00, хоть в 13:00. Главное, договориться с командой, чтобы была комфортная точка пересечения для статуса. Особенно на этапе онбординга, когда надо много коммуницировать с ведущими, иначе будет сложно влиться в команду.

    Никита Прудников, CTO Mindbox
    Никита Прудников, CTO Mindbox

    Игорь (директор по ИТ): Стратегически мы не одобряем переработки, потому что в итоге они приводят к снижению производительности у сотрудников — хуже и им, и компании. Но бывает, что новичок ставит себе амбициозные цели или работа просто «не идет» в рабочее время, и в итоге человек старается нагнать вечером или в выходные. Такие переработки весьма логичны и хорошо стыкуются с принципом работы на результат.

    Плюс у нас есть публичная фиксация переработок: простая Google-форма, где нужно указать причину. В этом случае мы оплачиваем дополнительное время в соответствии с ТК: по двойной часовой ставке. Обычно оплачиваемые переработки — это поддержка, то есть задачи, которые можно сделать только в нерабочее время. А если на выходных вдруг выходит сотрудник, чьи обязанности этого не предусматривают, — это хороший повод поговорить о нагрузке, пообщаться с лидом. Мы всегда стараемся понять причины переработок и починить их.

    Какие бытовые условия ждут нового сотрудника на рабочем месте?

    Игорь: Мы стараемся создать комфортные условия: бизнес-центр класса А со Старбаксом, панорамное остекление с шикарным видом на Москву, свежий ремонт. Можно попросить стол с регулировкой высоты. Чай, кофе, сладости, закуски — это само собой.

    Игорь Кудрин, CIO Mindbox
    Игорь Кудрин, CIO Mindbox

    У разработчиков есть выбор: топовый MacBook или Intel Core i7, i9 плюс монитор 4K, выдаем наушники с шумопоглощением. Покупаем нужный софт даже за рамками стандартного пакета. Еще из интересного — есть игровой компьютер с беспроводным VR-шлемом HTC Vive Pro. Ребята собираются по вечерам и играют в SUPERHOT и прочие VR-игры. 

    Есть ли возможность удаленной работы?

    Никита: Еще до пандемии на уровне инфраструктуры мы хорошо поддерживали удаленную работу. То есть у нас считалось нормальным, когда человек какое-то время работает из дома, потому что надо встретить курьера или он просто заболел: без больничного можно брать до трех дней. За время самоизоляции мы оборудовали Zoom Rooms: дают возможность собираться большими группами людей в одном месте и подключать удаленщиков, чтобы они видели нас, а мы видели их.

    У каждой команды разработки своя комната
    У каждой команды разработки своя комната

    Сейчас у нас около 60% разработчиков работают удаленно. Процессы так построены, что, если ты разработчик, для работы достаточно Гитхаба. Доступ к пайплайну есть, не нужно сложных VPN, только двухфакторная авторизация включена для безопасности. Всё общение в Slack, Trello, Google Docs — никакой почты и Microsoft офиса. То есть ты открываешь сайт, авторизуешься через Google и работаешь.

    Если хороший разработчик живет в другом городе и не хочет переезжать в Москву, он с большой долей вероятности попадет в компанию: мы и технически подготовились, и процессы позволяют. Если раньше статусы проводились очно и скрам-мастера были заточены под живое общение и трекинг, то сейчас процессы более асинхронные. Например некоторые команды коммитят результаты дейли-статуса в Гитхаб для прозрачности.

    Какой социальный пакет получают сотрудники?

    Игорь: У нас предусмотрено софинансирование обучения, спорта и лечения. В год выделяется 100 тысяч рублей на каждого сотрудника. И пока сотрудник их не превысил, компания оплачивает до 80%. После 100 тысяч процент падает, но не бывает такого, что этих денег не хватает. Еще у нас есть библиотека — книги закупаются за счет компании, в том числе электронные

    Какие бонусы, премии и компенсации предусмотрены в компании?

    Никита: У нас есть квартальная премия: половину прибыли мы делим внутри компании. На разработку приходится примерно 40% этих денег. В разных командах сумма распределяется по-разному, но решение всегда принимают сами сотрудники. Ожидать премии, сопоставимой с зарплатой, не стоит, но чем прибыльнее становится компания, тем больше суммы.

    Какие есть перспективы для образования и личного развития у сотрудников?

    Игорь: Сотрудник может пойти на любое обучение по профессии. У нас также есть целый перечень курсов по развитию софт-скиллов и против выгорания. Каждому разработчику составляется индивидуальный план обучения: там и курсы, и книги, и лекции на YouTube.

    О найме в Mindbox

    Во сколько этапов проходит найм и что на них ожидает соискателя?

    Никита: Найм проходит в два этапа: техническое и командное собеседование. На техническом этапе мы проверяем пересечение между навыками кандидата и тем, что нам нужно. Пример вопроса на этом этапе: нужен ли индекс по гендеру в базе? Командное собеседование — это проверка на соответствие ценностей кандидата и команды. В этот момент мы понимаем, насколько подходим друг другу. 

    Даете ли вы тестовое задание кандидатам? Как оно устроено?

    Никита: Сейчас у нас нет технического задания, вместо него просто просим прислать пример кода.

    Как отличается подход к найму в зависимости от позиции и стека?

    Никита: Команды сами нанимают себе сотрудников и обычно сами размещают вакансии. Исключение — C#, тут за найм отвечает CTO. В зависимости от уровня кандидата на собеседовании присутствуют либо только члены команды (для джунов и мидлов), либо дополнительно СТО (для синьоров и тимлидов). А если нанимаем тимлида, то перед этим прескриним его, чтобы понять опыт и ускорить собеседование.

    Карта офиса Майндбокс
    Карта офиса Майндбокс

    Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?

    Игорь: Никакая, у любой фразы есть контекст. Но иногда бывает, что по каким-то признакам мы сразу понимаем, что кандидат не подходит. Например, если видим пренебрежение к деталям, безответственность. Если на вопрос о том, кто после его ухода будет поддерживать то, что он разрабатывал, кандидат отвечает: «Мне плевать!». Но в любом случае мы стараемся провести собеседование до конца, просто потому, что человек дошел до этого этапа и потратил свое время. Идем дальше, пытаемся с разных сторон посмотреть. 

    Кого последнего вы уволили и почему?

    Игорь: SRE-разработчика. У него были сложности с онбордингом в команде, раз за разом, в течение полугода, были большие проблемы с качеством кода. К сожалению, у нас иногда не очень четко сформулированы ожидания — мы с этим сейчас активно работаем. Стараемся подбирать более изолированные задачи, чтобы посмотреть, как человек покажет себя в разных подходах. 

    Как происходит онбординг нового сотрудника?

    Никита: У нас всех есть ведущий — это человек, который в каком-то смысле отвечает за твой рост. У человека, которого мы нанимаем, конечно, тоже есть ведущий, который всегда доступен и которому можно задать любой вопрос. Мы стараемся выделить для новичка короткий бэклог задач на испытательный срок, чтобы он мог его сам взять и сделать. Плюс есть туториал — очень быстрый набор заданий для онбординга. То есть в контролируемых условиях человек пишет код в разных частях продукта и на этом учится. 

    О команде

    Какая методология разработки у вас используется и почему?

    Игорь: Смесь Scrum, Kanban с примесью всяких веселых штук в духе социократии. Мы регулярно находим новые идеи, интегрируем то, что кажется нам правильным, ошибаемся, пробуем дальше. Как и в любой компании, которая практикует гибкие процессы разработки, у нас микс из практик, уникальный набор процессов, которые мы сами вырабатываем. Работаем по спринтам, но это скорее отсечки, потому что у нас непрерывный роадмап. 

    Каковы размеры и структуры команд?

    Никита: Восемь-десять человек разного уровня, от джуна до тимлида. Если говорить о структуре команды, то есть три ключевые роли: стейкхолдер, техлид / архитектор и скрам-мастер. Ни одна из них не является ролью начальника. В некоторых командах могут быть, например, два продакт-оунера, в некоторых — SRE или фронтенд-разработчик. 

    Стейкхолдер отвечает за выручку продукта, над которым работает команда. Это, по сути, продакт-менеджер, который точно знает, что нужно рынку. Он управляет 70% бизнес-роадмапа команды и генерирует его.

    Техлид (или архитектор) отвечает за надежность продукта команды и совместно со стейкхолдером работает над роадмапом. Помогает оценить технические риски, экономику, понимает, как масштабироваться дальше, формулирует оценки. Плюс, он детализирует истории до момента, когда они подъезжают к пулу команды, чтобы команда могла сама их запулить. Техлидом обычно становится член команды, который постепенно берет ответственность за части продукта.

    Скрам-мастер отвечает за то, чтобы команда была функциональной. Улучшает процессы, чтобы команда предсказуемо и постепенно улучшала производительность. Эта роль выбирается командой. 

    Надо понимать, что мы не нанимаем разом восемь человек в новую команду, а подбираем людей в уже существующие. Выделение новой команды происходит эволюционно, через деление. Как в живом организме: из разных команд собираются какие-то роли. То есть появляются люди, которым интересно пилить какой-то продукт, и они объединяются для этого. 

    По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?

    Игорь: Формальной разбивки у нас нет, чаще всего подразумевается уровень ответственности за выпускаемые фичи и ожидания по зарплате. Мы оцениваем человека на собеседовании относительно рынка. И если он хочет зарплату больше, чем, по нашим оценкам, то мы готовы пойти ему навстречу, но с ожиданием, что через полгода он достигнет нужного уровня.

    Кто чаще возглавляет команды — продуктовый специалист или технический?

    Никита: Если говорить о том, кто принимает больше бизнес-решений, то это, конечно, продакт. Но при этом внутри команды нет такого, что он главный. Если архитектор говорит, что надо сделать надежно, а продакт говорит, что бизнесу надо быстрее, то ситуация эскалируется до других коллег. Решение конфликта происходит на общей вето-встрече.

    Офисная библиотека с книгами и настолками
    Офисная библиотека с книгами и настолками

    Как часто люди меняют команды?

    Игорь: Горизонтальная мобильность у нас достаточно высокая, можно даже посидеть на гостевом месте в другой команде. Бывает, что человек устал работать в каком-то подпродукте и хочет попробовать что-то новое. Или у команд меняются цели, например нужно инвестировать в роадмап, — и члены команды решают, насколько им это интересно. Или у команды появляется новая задача, но не хватает экспертизы — тогда можно переманить эксперта из другой команды. 

    Что важнее, софт-скиллы или хард-скиллы?

    Игорь: Зависит от роли: архитекторам, продактам и скрам-мастерам надо уметь договариваться, здесь отсутствие софт-скиллов ограничивает рост. А при наличии софт-скиллов и непрерывного желания и умения обучаться, хард-скиллы очень быстро разовьются. Но при этом есть люди, которые не очень эффективно умеют разрешать рабочие конфликты или не любят общаться, просто спокойно пишут код. Они себя тоже комфортно чувствуют: у нас команды очень хорошо умеют интегрировать таких людей.

    Как много собраний у вас проводится? Есть ли особые подходы к ним?

    Никита: Мы проводим еженедельные статусы и ежемесячные демо, где команда рассказывает, что сделано. Есть архитекторские встречи, потому что нам нужно много синхронизироваться между командами. Если ты просто код пишешь, тебя никто трогать не будет, но если ты хочешь расти, брать ответственность за какие-то куски продукта, то тебе придется чаще синхронизироваться на встречах. 

    Как вы боретесь с выгоранием сотрудников?

    Игорь: При малейших признаках проводим встречи один на один: стараемся вывести человека на какие-то шаги, которые помогут предотвратить выгорание. Предлагаем почитать книги, сходить на курсы. У нас также есть саббатикал: три месяца оплачиваемого отпуска спустя несколько лет работы в компании. За это время можно перезапуститься, отпустить гнетущее состояние, которое бывает при выгорании, и потом вернуться со свежими силами. 

    О технологиях

    Какие языки, фреймворки и библиотеки используются на проекте?

    Никита: .NET, С#. Фронтенд — React. База данных на SQL (суммарно 50 ТБ баз под большой нагрузкой), Кассандра. Часть продакшена на наших серверах в одном из московских дата-центров, часть — в Яндекс.Облаке. Соответственно, там .NET Core под Linux в Kubernetes-кластере. Инфраструктура: Terraform, Ansible. Deployment через Octopus Deploy + Helm 3. За мониторинг отвечают Prometheus, Grafana.

    Что вы можете рассказать об архитектуре проектов?

    Никита: Она крайне высоконагруженная и микросервисная: 300 тысяч бизнес-транзакций в минуту. Это сложные распределенные транзакции нескольких микросервисов. А базах данных у нас 20 тысяч транзакций в секунду в каждом инстансе. Внутри системы бизнес-событий у нас порядка 2 миллионов событий в минуту, отправляем полтора миллиарда имейлов в месяц. У нас очень сложный процесс надежности, чтобы поддерживать доступность 24/7 и при этом выкладывать новые изменения несколько раз в день на всех клиентов. 

    Какая у вас принята политика код-ревью?

    Никита: Ревью добровольное, но в целом принято, что все просят друг у друга ревью. Процесс работы с бранчами у нас Trunk-based Development, то есть разработка в бранчах, но живут они меньше дня. Это хорошо укладывается в культуру ревью. Если попросишь большое ревью (+/- 1000) — могут и отказать.

    Как тестируется код?

    Никита: Код тестируется автоматически: у нас пирамида тестов, порядка 20 тысяч. Они автоматически прогоняются на каждый коммит в каждом бранче, проходят за примерно 20 минут.

    Мы используем статус-чеки в гитхабе, если тесты в бранче не прошли, мержить в мастер нельзя. На мастере еще раз прогоняют пирамиду тестов, и дальше конвейер едет через другие инструменты контроля качества, например канарейку.

    Как устроен процесс документации и ведения базы знаний на проектах?

    Никита: У нас самодокументируемый код. Текстовую документацию стараемся писать только для критичных решений в виде ADR. Они хранятся в репозитории прямо рядом с кодом по строгому заведенному шаблону. Мы стараемся минимизировать количество текста, потому что текстовое описание имеет свойство быстро устаревать, так как не связано с кодом. Для клиентов Mindbox документация к API автогенерируемая, то есть создается автоматически под код.

    «Семейное» фото команды
    «Семейное» фото команды

    Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?

    Никита: 30% времени всех команд инвестируется в надежность, масштабируемость, поддержку и обновление кодовой базы. Архитектор совместно с командой решает, как приоритизировать, чтобы можно было дальше с прежней скоростью разрабатывать и масштабироваться. Команда напрямую вместе с архитектором управляет этой полосой. Бывает, что там едут рефакторинги, бывает что-то другое.

    Помимо этого, у нас выделены две команды, которые работают с важными целями в кодовой базе. Одна мигрирует нас на другое реляционное хранилище. Вторая сильно меняет стек-приложения, мигрирует рантайм в Kubernetes-кластер на .NET Core.


    Оценивайте своих работодателей на Хабр Карьере, а если понравилась компания Майндбокс и хочется узнать о ней побольше — пишите вопросы в комментах, мы призовем кого-нибудь из ребят отвечать.

    оценить работодателя

    Хабр Карьера
    Сервис развития карьеры в IT

    Комментарии 9

      0
      Былу ребят на онлайн-собеседовании (неудачном для меня) — и это было лучшее собеседование за все мое время работы вообще. За два часа «потогонки» — создали о себе крайне хорошее впечатление.
        –1
        Спасибо! Найм у нас открыт непрерывно, если захотите через год попытать сил с новым опытом, мы это приветствуем.
          +2
          На мой вкус жутковатые они. Настораживает, например, библиотека с Кнутом и Чего-то там интроверта.

          Но я доволен что ходил к ним на собеседование. Во первых они знают что хотят спросить, а не по опроснику из интернета вопрошают. Во вторых некоторые вопросы вскрыли мои белые пятна, задели самолюбие и в итоге инициировали повышение уровня.
          Всем рекомендую к ним сходить.
          +1
          На мастере еще раз прогоняют пирамиду тестов, и дальше конвейер едет через другие инструменты контроля качества, например канарейку.
          То есть ручных тестировщиков у вас нет, и вместо них вы используете сторонних пользователей?

          Мы стараемся минимизировать количество текста, потому что текстовое описание имеет свойство быстро устаревать, так как не связано с кодом.
          Текстовое описание действительно может быть не связано с кодом, но только в одном случае: если его не обновлять.
            0
            Конечно нет, вместо ручного тестирования у нас автотесты, в том числе UI/UX (puppeteer). Ручные тесты по сценарию не поспевали бы за нашим релизным циклом (несколько десятков выкладок в день, в том числе несколько выкладок основного монолита).

            С текстовой спецификацией ситуация похожая: код проверяется компилятором, тестами, людьми, работающими на стейджингах и продакшне. Текстовую спецификацию можно проверить только глазами, сравнив с кодом. Начиная с определенной скорости поставки такой подход работать перестает и заменяется другими, например spec-by-example либо автоматической генерацией спецификации кодом.
              +1
              Благодарю за ответ.
              Жаль, что в угоду скорости разработки вы жертвуете качеством.
              Отсутствие ручного тестирования как класса и комментариев в коде разочаровало.
                0
                Скорость не достигается ценой качества, это частое заблуждение.

                Некачественный продукт отнимает на свою поддержку все больше времени до тех пор пока все время разработиков не занимает поддержка и разработка остановлена.

                Цель успешной продуктовой разработки — зафиксировать качество и раз за разом убирать препятствия чтобы уменьшить time-to-market новых гипотез. Часто по пути меняются инструменты и роли: в нашем случае изоляция контекстов, самоописывающий код, фиксация контрактов автотестами показали себя лучше текстовых комментариев, а исключение человека из конвеера доставки позволило выкладывать изменения малыми инкрементами. В купе с blue-green deployment, покрывающим мониторингом, канарейкой, механизмом быстрого отката через это контролируются ситуации, которые не протестировать руками.

                В статье в блоге мы детальнее рассказываем про эволюцию разработки и процессов качества у нас.

                Если вам интересно глубже разобраться в подобных процессах, хочу порекомендовать хорошие книги Accelerate и Google SRE book — про современные процессы devops и поддержки, метрики и инструменты качества.
            0
            Мне кажется, что год в названии поста ошибочный. Не 2021 имелось в виду?

            PS. Понял. Это серия статей такая была. Тогда вопрос снимается. Но выглядит немного странно :)

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое