Как привлечь сильных специалистов, если вы не в топе IT-брендов

В условиях, когда бренд не работает на вас, а сильные специалисты уже заняты в крупных компаниях, важно уметь "продавать возможности". На примере отдела клиентской разработки в RUTUBE расскажу, как с нуля выстроить сильную команду и создать мотивацию для талантов присоединиться к проекту. Подробно разберем:

▪Зачем нанимающим менеджерам работать в тандеме с рекрутерами?
▪Как готовить собеседующих, чтобы определить грейд за один этап?
▪Почему найм не завершается после подписания оффера?
▪Как давать обратную связь, чтобы кандидаты рекомендовали вас другим?
▪Зачем инвестировать в онбординг и карьерное развитие?

Skillaz — это российская HCM-платформа (Human Capital Management), предназначенная для автоматизации и управления HR-процессами в средних и крупных компаниях. Она охватывает полный цикл работы с персоналом: от подбора и адаптации до обучения, развития и оффбординга.

3 года назад мы полностью пересобирали всю техническую команду RUTUBE, а в месте с ней все ключевые сервисы и перепридумывали архитектуру систем под задачи бизнеса. Мы выросли с 60 тысяч ежедневных пользователей в 2021-м, до 17,7 млн пользователей в сутки на сегодняшний день. И когда нам нужна аргегация данных, любой клиент сейчас может получить новую ручку с API и быть уверенным, что данное решение точно будет работать стабильно и держать нагрузку. Но так было не всегда.

В этом докладе я расскажу:

- В каком виде мы получили сервисы от старой команды и как 3 месяца не могли выкатить АБ-тест;
- Какой была архитектура легси решения и почему мы выбрали Nest.js;
- Почему решили отказаться от идеи переписать все на GraphQL;
- Как продали свое решение и почему именно наше решение теперь является единым BFF;
- Какая архитектура в итоге получилась в результате интеграций с Web, Mobile и SmartTV приложениями;
- Как выстраивать процессы и обеспечивать SLA для большого количества клиентов в высоконагруженных сервисах.

Когда мы пришли 3 года назад, архитектура плеера RUTUBE оставляла желать лучшего.
Первое время мы пытались приводить в порядок и развивать то что было, но быстро стало понятно, что нам не удастся двигать вперед и реализовать поставленные цели без полной переработки.

В это докладе я расскажу:
- Зачем нужна сложная архитектура для плеера, а не просто тег video.
- Как старая реализация на redux и супер-компоненте тормозила разработку, убивала возможности развития и масштабирования
- Какие задачи окончательно заставили выделить ресурсы на тотальный рефакторинг.
- Каким образом мы переписали плеер на Mobx, распилили на модули, внедрили DI и интегрировали плеер в другие проекты холдинга