Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Наша рубрика «Где работать в ИТ» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях.
Участником этого выпуска стала компания Flowwow — маркетплейс, на котором локальные магазины продают свои товары.
А ещё в выпусках мы рассказываем об оценках компаний на Хабр Карьере, чтобы вы были в курсе, за что их любят (или нет?) сотрудники. Кстати, если вы тоже оцените своего работодателя, то это поможет тем, кто ищет работу в ИТ.
→ оценить работодателя
Кто отвечал на вопросы
Обо всех процессах в Flowwow нам подробно рассказали:
Дмитрий Шестернин
CTO
Оксана Клементьева
HR-директор
Андрей Боярчук
Тимлид команды курьеров
Виталий Перятин
Тимлид команды Android
Павел Кузьмин
Тимлид команды iOS
Иван Могилат
Тимлид команды бэкенда
Артем Гамбицкий
Тимлид команды фронтенда, сооснователь компании
О компании
Flowwow — онлайн-платформа для продавцов и покупателей, на которой собрано более 6000 магазинов из 950 городов мира. Магазины размещают на Flowwow товары из разных категорий: цветы, кондитерские изделия, игрушки, украшения, продукты и многое другое. С 2020 года компания является резидентом «Сколково». А еще вы могли слышать про нее от друзей и блогеров.
Публичная оценка компании на Хабр Карьере в 2021 году — 4,77 из пяти. Сотрудники особенно ценят Flowwow за интересные задачи, связь с топ-менеджментом, отношения с коллегами, профессиональный рост, а также за то, что компания делает мир лучше. Увидеть оценку в деталях и почитать комменты сотрудников можно в профиле Flowwow на Хабр Карьере.
А еще компания ведет блог на Хабре. В последней статье аналитик по закупке трафика Flowwow рассказал, как они рассчитывают спрос на подарки с помощью ML.
Об условиях работы
Какой рабочий график сложился в вашей компании и какое отношение к переработкам?
Дмитрий Шестернин: Наша компания изначально строилась как удаленная и «международная». Мы работаем из разных городов и стран, живем в разных часовых поясах, поэтому каждый сотрудник разработки сам организует свой рабочий график. Свои часы работы анонсируем в личной карточке в Slack: так все знают, когда кого можно застать за работой.
Желательно всем быть на связи с 9.00 до 16.00 по московскому времени: это «командное» время, когда у нас возникает больше всего оперативных вопросов, бывает, нужно созвониться и что-то быстро решить.
По личному опыту, мало кто может работать с одинаковой продуктивностью 8 часов в день. Поэтому мы не логгируем старт и окончание рабочего дня: не так важно, сколько часов вы потратили, главное — результат.
Тогда как ведется контроль? Очень просто: если какое-то время ваши задачи лежат без положительной динамики, «тогда мы идем к вам» — спросить, как дела, в чем затык, и что мешает показать результат.
Наш главный инструмент контроля — ежедневный план. В начале рабочего дня проводим получасовой дейли-митинг, после чего каждый пишет в канал, что планирует делать. В середине рабочего дня пишем, как успехи и куда продвинулись. Этого достаточно для того, чтобы координировать действия команды!
О переработках
Дмитрий: Переработки — это не наш стиль: слишком дорого стоит потом эмоциональное выгорание сотрудников. Компания, конечно, оплачивает переработки, но в большинстве случаев коллеги берут себе выходные. Эту позицию мы одобряем и всегда даем людям отдохнуть.
К счастью, в нашем бизнесе есть предсказуемый и понятный график сезонных пиков. На мобильную разработку основная предпраздничная нагрузка ложится за 2-3 недели до пикового дня (14 февраля, 8 марта, день Матери в конце ноября). Для бэкендеров, фронта, админки и девопс — максимальная нагрузка приходится на сами праздники. За 7 лет работы мы научились готовиться к пиковым дням и распределять нагрузку, чтобы пики были максимально безболезненными.
Оксана Клементьева: Пиковые дни — важная часть работы всей команды. Мы обговариваем это еще на этапе собеседования. Нам еще ни разу не приходилось вынуждать или уговаривать кого-то выходить на работу в пики: команда настолько заряжена, что почти всегда мы не сговариваясь участвуем в общем деле (даже те, для кого это необязательно).
Мы остаемся онлайн в течение всего дня и с азартом следим за тем, как работает сервис, выдерживают ли сервера. Все это напоминает скорее командную азартную игру, когда мы вместе смотрим, сколько «очков» заработали и насколько хорошо подготовились к ответственному дню. После пика ребята спокойно используют отработанные дни для отдыха и восстановления баланса.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Оксана: Офис располагается в Москве, ровно в 1 минуте от метро Сухаревская. Здесь светло, уютно, самый громкий сотрудник — кофемашина. Летом открыт выход на веранду. Каждый день там можно встретить сотрудников бухгалтерии и команду клиентского саппорта, часто операционного директора и двух из трех сооснователей компании. Остальные сотрудники команды работают удаленно.
Если вы решите работать в офисе, мы подготовим вам рабочее место ко дню выхода: обсудим вместе с вами, какая вам нужна техника, все закупим и подключим. Если выходите работать с завтрашнего дня — дадим технику, которая есть в активе, и за 2-3 дня подготовим рабочее место по вашему запросу.
Еще о технике! Как правило, наши сотрудники предпочитают работать на своей привычной технике, но спустя 6 месяцев работы в Flowwow могут обновить ее по собственному желанию (выбираете все, что вам нужно) и получить от нас компенсацию в 50 тысяч рублей. Техника при этом остается вашей собственностью. Компенсируем по необходимости, как правило — один раз в три года.
Нам неважно, на чем вы работаете, если ваша техника тянет наш стек.
Есть ли возможность удаленной работы?
Дмитрий: С 2015 года вся команда разработки Flowwow работает удаленно: сейчас это 30+ человек из разных городов России и других стран.
Какой социальный пакет получают сотрудники?
Оксана: ДМС. Каждому сотруднику после прохождения испытательного срока мы оформляем полис ДМС («Альфастрахование»). Полис включает амбулаторное, экстренное и плановое стационарное лечение, неотложную и скорую помощь, услуги стоматолога. Бонусы:
Возможность раз в год пройти чек-ап здоровья без наличия страхового случая;
Полис страхования жизни и здоровья при поездке за рубеж.
Корпоративная скидка на Flowwow. Составляет 15%, она бессрочная, действует на весь ассортимент магазинов, входящих в программу лояльности WowPass (более 2000 магазинов в 950 городах России).
Приветственный промокод. В день оформления на работу каждый сотрудник получает промокод на 3000 рублей, с которым мы предлагаем ему протестировать наш сервис и сделать заказ.
Праздники. 3-4 раза в году (на 8 марта, день Матери и т.д.) сотрудники получают от фирмы промокоды на фиксированную сумму — чтобы заказать подарки себе или близким.
Какие бонусы, премии и компенсации предусмотрены в компании?
Оксана Клементьева: Чтобы закрыть формальности: у нас все строго по ТК. Белая зарплата, ежегодная индексация, оплачиваемые отпуска, больничные. Есть еще 10 дней в году, которые вы можете поболеть, не открывая больничный: используются в случае, когда понятно, что нужно просто отлежаться день-два для того, чтобы быть снова в строю.
Ежегодная премия — выплачивается команде вместе с мартовской зарплатой, ее размер определяется руководителями подразделений.
Оплата командировок. Мы поддерживаем желание съездить на важную отраслевую конференцию. Само собой, компенсируем дорогу, билет, проживание, если вы готовите доклад — поможем написать речь и сделать красивую презентацию. После мероприятия ждем, что сотрудник расскажет, что было интересного, и как мы можем это применить в работе.
Регулярный пересмотр размера заработной платы. Нам хватает «бирюзовости», чтобы видеть и ценить успехи каждого сотрудника. В 2021 году пересматривали зарплаты 2-3 раза в год; в результате вырос заработок у всех сотрудников.
Благодарности. У нас есть добрая традиция: в конце каждого месяца каждый сотрудник выбирает одного коллегу, который ему очень помог или с которым они круто поработали в этом месяце, и оставляет ему благодарность. За каждую благодарность в свой адрес ребята получают по 3000 рублей от компании. Максимальное количество благодарностей, полученных одним человеком за месяц — 7. Но ограничений здесь нет.
Какие есть перспективы для образования и личного развития у сотрудников?
Дмитрий: Как правило, сотрудник сам понимает, что у него есть какие-то «слепые пятна» или неосвоенные скиллы, или ему нужно прокачиваться в связи с ростом и расширением круга обязанностей. Тогда он приходит к своему руководителю, ко мне или напрямую к Оксане — либо с созревшим пониманием того, что ему нужно изучить, либо просто с запросом на обучение.
Вместе с руководителем сотрудника мы оцениваем необходимость обучения (почти всегда оказывается, что в этом есть резон), а дальше остается только выбрать наиболее подходящий курс обучения из моря предложений, представленных на рынке.
Оксана: Иногда мы предлагаем сотруднику равноценную альтернативу курсу, который он выбрал, а порой и более интересный вариант. Затем оплачиваем 100% стоимости обучения. Возможны ситуации, когда мы сами рекомендуем сотруднику пройти какой-нибудь хороший курс — и здесь решение остается за ним.
Дмитрий: В конце обучения сотрудник по традиции презентует заинтересованным коллегам результаты своего обучения: что узнал, что освоил, чем готов с нами поделиться и как будет применять полученные знания.
С середины 2021 года практикуем развитие команды разработки через привлечение внешних консультантов. Начали строить новую вертикаль — пригласили экспертов на аутсорсе, что позволило прокачать всю команду, а отличившимся повысили ЗП.
О найме
Во сколько этапов проходит наём и что на них ожидает соискателя?
Дмитрий: В 2021 году мы почти полностью перешли на формат One-day offer: по итогам отбора резюме проводим единственное собеседование. Оно совмещает в себе и техническое, и мотивационное интервью. С нашей стороны участвуют IT-рекрутер, технический специалист и тимлид, который выбирает человека к себе в команду.
Собеседование длится в среднем 60 минут. Если кандидат нам нравится, мы запрашиваем фрагмент боевого кода и в тот же день делаем оффер.
На собеседовании мы в равной степени презентуем продукт, компанию и команду. Рассказываем, как и чем собираемся мотивировать сотрудника. Со своей стороны, обязательно спросим о том, чего человек ждет от работы. Тем, кто говорит о жажде развития, задаем уточняющий вопрос: что было с развитием на предыдущем месте работы? Очень ценим, если кандидат честно расскажет, что побудило его уйти с предыдущего места работы.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Дмитрий: Тестовых не даем, но просим показать примеры кода, с которым человек работал в последнее время. Мы уважаем NDA, но еще больше нам нравится, когда человек блюрит то, что показывать нельзя, меняет переменные, названия классов — и все равно находит возможность познакомить нас со своим боевым кодом. А вот код из тестовых заданий мы не очень любим: 2-3 странички боевого кода, пусть не такого красивого, но живого, скажут о вас гораздо больше.
Как отличается подход к найму в зависимости от позиции и стека?
Оксана: Подход един для всех. Единственный нюанс: если беседуем с соискателем на руководящую должность (тимлид, сеньор), обязательно спросим об опыте управления командой в отрасли, может быть, обсудим вместе пару кейсов, посмотрим, как кандидат мыслит и как решает задачи.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Оксана: Никто на собеседовании не говорит таких фраз напрямую. Но по некоторым косвенным признакам мы можем заподозрить, что человек пришел к нам не за долгосрочным сотрудничеством, совместным ростом и драйвом, а, например, просто перекантоваться. Или он ищет тихую гавань, где можно числиться, параллельно пилить свои проекты и быть в команде примерно на пару часов в неделю.
В этих случаях мы откажем соискателю.
Дмитрий: Зато никогда не выбросим резюме человека, который гордится тем, что он сделал на предыдущем месте работы, которому важно, чтобы результат его трудов быстро вышел в бой и изменил этот мир. Это прямо знак, что человек наш.
Кого последнего вы уволили и почему?
Дмитрий: Вообще увольнение разработчика для нас — нечастая история. Уходят либо в начале испытательного срока, поняв, что мы в чем-то не совпадаем, либо остаются на годы. Но вот в 2021 году пришлось расстаться с сотрудником: он проработал у нас более года и остался на прежнем уровне скиллов, несмотря на ряд пройденных курсов. Обидно было, что на собеседовании он ратовал за саморазвитие. У нас тут принцип открытой ладони, свободная среда, постоянное обновление стека — можно запросто добиваться своих амбициозных целей. Но когда сотрудник хочет делать что-то на словах, а не на деле, значит нам не по пути.
Как происходит онбординг нового сотрудника?
Оксана: Во-первых, каждый сотрудник Flowwow в первый момент работы у нас получает подробный велкам-бук: в нем все о наших правилах, традициях, экскурсия по нашим ценностям, приветственный промокод на заказ, контакты самых нужных людей и даже правила эффективного общения в SLACK — в общем, все что нужно.
Для разработчиков у нас есть еще один емкий и короткий документ, в котором четко написано, что в какой последовательности включить, куда зайти и как начать работать. Уже в первый день разработчик может показать, на что он способен (но мы настаиваем, чтобы в первый день он осмотрелся, прочитал мануал и вник в продукт).
Каждый новичок в команде разработки закрепляется за одним из тимлидов, который помогает ему быстро погрузиться в проект и начать продуктивно работать. Также за состоянием новых сотрудников следят эйчары компании, в этом нам помогает взаимодействие с новичком и статистика slack. Согласно внутреннему опросу, у 70% сотрудников онбординг занимает около месяца, а некоторые отмечают, что «как будто работали здесь всю жизнь».
О команде
Какая методология разработки у вас используется и почему?
Дмитрий: У нас нет скрама или ватерфола в классическом виде, так как ключевая метрика нашей эффективности — time to market. Под эту метрику и адаптирован весь процесс разработки.
У нас темпераментная, скоростная разработка: можем выкатывать микрорелизы по 20-30 раз в день. Главный риск при таком темпе — ошибки, поэтому у нас жестко выстроены процессы автоматизации деплоев, сбора ошибок и код ревью. Это позволяет контролировать число багов на разумном уровне.
А вот безошибочная, гладкая работа нас скорее насторожит: мы считаем, что если мы мало ошибаемся, значит, слишком медленно развиваемся. Такой методологии придерживаемся везде, кроме мобильной разработки: там действует адаптированный скрам. Есть спринты, релизы и другие атрибуты гибкой методологии.
Каковы размеры и структуры команд?
Дмитрий: Вся команда разработки — это 30 человек. Команды прямо сейчас активно формируются: до 2021 года мы справлялись как единое целое, но сейчас оно естественным образом распалось на структурные элементы:
iOS,
Android,
Фронтэнд,
Админка,
Несколько команд на бэкенде: API, команда нагрузок и т.д.
Каждая команда — не больше 4-х человек, включая тимлида. Все тимлиды у нас «играющие»: участвуют в написании кода и инициируют основные изменения.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Дмитрий: Придерживаемся стандартных критериев: джун для нас — это тот, кто может делать поток небольших типовых задач в короткий промежуток времени. Мидл самостоятельно планирует, оценивает задачу, за 2-3 дня ее решает и с первой-второй попытки проходит код ревью. Со временем он у нас становится мидлом+, то есть получает свою зону ответственности (например финансы, очереди, нагрузки, API для приложения и т.д.). Он берет на себя весь фидбек по этой сфере и работает с ней самостоятельно. Синьор — в нашем случае это уже тимлид, у которого есть не только зона ответственности, но и пара падаванов, которых он постепенно прокачивает.
Оксана: Мы редко берем на работу джунов — только в том случае, если нам вдруг нужен человек под постоянный поток мелких коротких задач (например, верстка имейлов). В остальных случаях предпочитаем брать мидл специалистов.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Дмитрий: Прямо сейчас продуктовых спецов в чистом виде у нас нет, инициатива о новой фиче может прийти от самых разных людей. Пока нам удается ориентироваться не на жесткую структуру, а на то, кто фактический заказчик. Возглавить фича-команду, которая решает конкретную бизнес-задачу, может и веб-дизайнер, и руководитель бизнес-направления. Микрокоманда собирается гибко и мобильно из тех, к кому относится задача и кто заинтересован в релизе.
При этом практически все наши сотрудники шарят в технике (в ДНК мы IT-компания!) — это базовое требование. Например, все, кто хоть чуть-чуть работает с данными, обучены sql, сами себе делают выгрузки и не приходят к разработке с такими задачами.
Как часто люди меняют команды?
Дмитрий: Как правило, разработчики у нас растут вглубь, внутри своей технологии. Хотя есть примеры, когда люди меняют по ходу даже стек технологии, не то что команду.
Что важнее, софт-скиллы или хард-скиллы?
Дмитрий: Я бы отдал 45% хард-скиллам и 55% софт-скиллам — учитывая, что мы удаленная команда и каждый должен быть себе хорошим менеджером. Организовать рабочий процесс, наладить коммуникацию с командой, спланировать свой день. Бывало, мы отказывали очень крутым специалистам с низким уровнем коммуникативного навыка.
С другой стороны, у ребят с высоким уровнем софт скиллс харды, как правило, тоже бывают на хорошем уровне. Поэтому хардам отдаем не менее 45%.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Дмитрий:
Дейли митинг на 30 минут в начале каждого рабочего дня (время выбираем удобное для всех, смотря по часовым поясам);
Обязательный созвон по девопс делам раз в 2 недели: обзор нововведений по серверной схеме, разработчики задают вопросы девопсу и обозначают приоритеты;
Тимлидский созвон с CTO раз в неделю: обсуждаем управленческие и административные вопросы.
По всем остальным вопросам созваниваемся оперативно в течение рабочего дня.
Подход у нас очень простой: задачи, которые требуют вовлечения других людей, всегда имеют приоритет над твоими автономными задачами.
И еще — мы не приветствуем дискуссии в личках. Лучше выбирать открытые каналы, чтобы все были в курсе дела и могли подключиться к обсуждению.
Как вы боретесь с выгоранием сотрудников?
Оксана: Во-первых, наша корпоративная культура отвечает всем требованиям work-life balance. Мы даем людям возможность отдыхать, самоорганизовываться, брать паузы — это уже важная часть профилактики выгорания.
Во-вторых, мы чутко следим за самочувствием тех, с кем работаем бок о бок. У нас сквозная система коммуникации: повышение эмоционального градуса или, наоборот, снижение активности сразу становятся заметны. Если что-то идет не так, я могу аккуратно обратиться к сотруднику в личке: постараемся вместе понять причины проблем и найти решение. Чаще всего, человеку нужно просто немного отдохнуть или сменить фокус — и он снова возвращает себе баланс.
Дмитрий: С командой разработки все еще проще: на горизонте двух недель по результатам работы вдруг становится ясно, что человек немного (или много) перегрелся. Растет число багов, больше возвратов от тестировщиков… Первое, что я делаю, это предлагаю взять неделю отпуска. Почти всегда это работает. За последние 2 года минимум четверых сотрудников я отправлял в такой вот профилактический отпуск — и один из них был я сам. Просто понял, что начал косячить, и ушел на перезагрузку.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте? Что вы можете рассказать об архитектуре проектов?
Андрей Боярчук, тимлид команды курьеров: Используем бэк-стек php8, серверный стек yii2, mysql, rabbitmq, redis, graphhopper, supervisor, docker. Представление на js, vue. Приложение kotlin. Из yii2 mvc, rest, patterns, corecept, swagger, github ci/cd.
Виталий Перятин, тимлид команды Android: Наш язык — Kotlin. Библиотеки — GSON, Retrofit, Glide, Firebase, Kotlinx Coroutines, Koin.
В Android используется архитектура MVVM на базе ViewModel от Google и корутин + флоу от команды Kotlin. Благодаря гибким возможностям флоу получается отправлять данные и подписываться на данные из View без лишних костылей. А с ViewModel от Google легко обрабатываем все корнер-кейсы от Android по смене конфигурации и сохранению данных.
Павел Кузьмин, тимлид команды iOS: Используем язык swift. Из фреймворков у нас Moya, netfox, Swinject, Firebase, GoogleMaps, SwiftLint, Periphery, а также другие для локальных потребностей: DeviceKit, Agrume, Shimmer, FaveButton, lottie-ios. Всё подключено через CocoaPods.
Что касается архитектуры, мы используем MVVM+Coordinator паттерн и для удобства бьём всё на модули.
Иван Могилат, тимлид команды бэкенда: Проект написан на PHP (7.4, прямо сейчас мигрируем на 8.0). Основная база данных — Mysql8. Также используем RabbitMq, Redis, Clickhouse, Firebase.
Мы выросли из стартапа, у нас никогда не было возможности переписать все заново, поэтому проект сменил несколько фреймворков. На основном проекте — модифицированный под современные требования Yii1, на сайд-проектах — Yii2. Стараемся писать независимый от фреймворка код, чтобы в дальнейшем миграция давалась легче.
В данный момент мы в процессе разделения основного монолитного проекта на отдельные сервисы, что позволит использовать более релевантные и современные технологии.
Инфраструктура построена на Amazon, она хорошо масштабируется (а нам это важно — с ростом нагрузки х30 во время пиков). Используем master-slave репликацию Mysql, кластер RabbitMQ, группы серверов под различные траффики с балансировщиками. После праздничных дней легко уменьшить количество и размеры серверов и экономить значительные суммы.
Артем Гамбицкий, тимлид команды фронтенда, сооснователь компании: Фронтенд на текущем этапе развития использует Vue.js с Nuxt, покрытые TypeScript'ом, и сдобренные Cypress-тестами.
К этой схеме мы пришли не так давно, прямо сейчас пересматриваем старый фронт и переписываем его, используя упомянутые инструменты. Поэтому присоединившимся сейчас будет доступна уникальная опция внесения своего вклада в архитектуру проекта.
Какая у вас принята политика код-ревью?
Дмитрий: Главное золотое правило — непроверенный код не уезжает в продакшн (см. пункт про разумное количество ошибок). Даже если внутренний заказчик сучит ногами.
Мы используем статистические анализаторы кода (на бэке это Phan).
У нас принят единый стандарт форматирования кода, который применяется автоматически: это позволяет сохранять единообразие кода, независимо от того, кто его пишет.
Как тестируется код?
Дмитрий: У нас принята трехзвенная система: есть микро-окружение разработчика (тестируем на своих локальных машинах), окружение девелоперское (дев-сайт, дев сборки приложений) и последний рубеж — продакшн (тестируем и фиксим максимально оперативно).
В команде четыре тестировщика, и их число будет расти пропорционально числу разработчиков. На бэкенде и фронтэнде есть автоматические тесты, но их мы внедряем при условии, что стоимость их написания и поддержания ниже стоимости аналогичной ручной работы. Тесты ради тестов стараемся не внедрять.
Как устроен процесс документации и ведения базы знаний на проектах?
Дмитрий: Документация тоже ведется на трех уровнях:
1. Комментарии прямо в коде;
2. Уровень в конфлюенс (Jira): здесь прописываем уже на нативном языке, как устроен тот или иной модуль, функционал, сервис и т.д;
3. Уровень бизнес-документации. ТЗ ставится через написание этой документации — в фигме.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Дмитрий: Мы — компания почти с 8-летней историей и бурным темпераментом: естественно, легаси-кода у нас достаточно. Адекватно относимся к рефакторингу: у нас собственный продукт и кодовая база, с которой мы будем работать сегодня, завтра и через год. Нам важно содержать ее в порядке.
Разработка нового модуля или плановая переработка старых модулей начинается с переписывания старого кода. Задачи по рефакторингу появляются по мере необходимости. Никто не будет перелопачивать что-то только ради процесса: мы готовы выделять время и ресурсы только на необходимые задачи по рефакторингу.
Естественная ситуация, когда сами разработчики формулируют запрос: много багов, нет возможности наладить новый функционал и т.д. Тогда пишется план, одобряется лидом — и мы обновляем код. Рефакторинг всегда предшествует решению актуальной бизнес-задачи.
Оценивайте компании на Хабр Карьере и делитесь мнением о них с теми, кто сейчас ищет работу в ИТ. Это анонимно.
→ оценить работодателя
