Вакансии twinby: работа в IT и digital

О роли

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

Это инженерная роль, а не «оформление хотелок в тикеты». Ты владеешь требованиями и контрактами целиком: достраиваешь то, что недодали в постановке, проектируешь, как сервисы договариваются друг с другом, и держишь спеку, по которой команда уверенно пишет код, тесты и приёмку. У нас спека — закон и единый источник правды: код, тесты и приёмка идут именно по ней.

Чем предстоит заниматься

• Достраивать требования там, где их недодали: ловить пробелы, противоречия и edge-cases до того, как они доедут до прода — это и есть основная ценность роли.

• Проектировать API-контракты (REST/OpenAPI, gRPC) и интеграции между сервисами: поля, коды ошибок, идемпотентность, лимиты, обратная совместимость со старыми клиентами.

• Строить модель домена и жизненные циклы сущностей (матч, лайк, подписка, платёж): состояния, инварианты, запрещённые переходы — чтобы система не оказывалась в невозможном состоянии.

• Держать спеку-закон в Confluence: оформлять требования и сценарии так, чтобы бэкенд, QE и аналитика читали один и тот же источник истины, а спека была пригодна для DoR/DoD.

• Работать с моделью данных (PostgreSQL): читать и проектировать схемы, видеть, где контракт расходится с данными, проверять гипотезы SQL — а не на словах.

• Спорить по существу с бэкендом и продуктом: отстаивать решение по контракту и модели, а не фиксировать чужое.

Что мы ждём

• Умеешь проектировать контракт, а не только описывать фичу: торгуешься про требования (что обязательно, что при повторе, какие коды ошибок — 200 vs 409 vs 4xx), мыслишь идемпотентностью, лимитами и версионированием.

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

• Читаешь чужую схему и контракт как родной текст: OpenAPI/Swagger, DDL, модель данных — замечаешь nullable, который сломает джойн, и поле в ответе, которого нет в модели.

• Видишь распределённые эффекты: рассинхрон источников истины, потерянные и задвоенные колбэки, обратную совместимость — и держишь это в голове без напоминания.

• Различаешь «требование бизнеса» и «как мы это технически реализуем», и аргументируешь решения по модели, а не оформляешь их по диктовку.

• Опыт в домене со сложными интеграциями, где ошибка в контракте стоит дорого, — финтех, биллинг, госинтеграции, сложный e-com.

Будет плюсом

• Опыт проектирования событийных и асинхронных интеграций (очереди, outbox/saga), а не только синхронных вызовов.

• Привычка писать ADR и аргументировать решения по модели; выступления на профильных конференциях или свой канал по системному анализу.

• Знакомство с дейтингом или другим реалтайм-продуктом с деньгами — приятный бонус, но не обязателен.

Чего НЕ требуем

Знания нотаций наизусть (BPMN/UML/IDEF) и «правильности» диаграмм, заученных шаблонов ТЗ и методологий, идеального оформления именно в нашем инструменте, знания именно домена дейтинга. Нам важнее системное мышление и инстинкт на контракты и противоречия — стек и предметную область добираешь по ходу.

Окружение и инструменты

Требования и спеки, контракты REST/OpenAPI и gRPC, интеграции между сервисами, модели данных в PostgreSQL. Документация и спека-закон — в Confluence, задачи — в Jira; диаграммы (UML, sequence) — как инструмент, а не самоцель; SQL — чтобы проверять гипотезы по данным. Бэкенд, с которым работаешь, — монолит на Django и Go-сервисы; инфраструктура — российское облако (Yandex Cloud).

Что предлагаем

• Владение моделью домена и контрактами — ты проектируешь, как устроены интеграции, а не переписываешь чужие постановки в тикеты.

• Настоящая инженерная система, а не лозунги: спека-закон как единый источник правды, OpenAPI как контракт, замкнутый цикл доставки и DoR/DoD вместо устных постановок.

• Влияние с нуля: команды собираются заново, контракты и модель домена ещё не застыли — ты задаёшь, как они будут устроены.

• Прямой контакт с бэкендом, продуктом и аналитикой; масштаб и реалтайм, где цена ошибки в контракте высока.

• Формат: удалёнка, РФ.

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, бусты, покупки), антифрод и модерация. Мы перестраиваем инженерную систему Twinby CIS и собираем команды практически с нуля. Ищем сильного Data Analyst (аналитика-разработчика) в департамент Data & ML — человека, который берёт мутный вопрос о продукте и сам доводит его до проверенного ответа на сырых данных.

Это не роль «пришли ТЗ — посчитаю». Ты сам ставишь гипотезу, сам лезешь в сырые события, сам решаешь, какой глубины разбор нужен, и доводишь до решения, на котором можно действовать — а если вопрос повторяется, закрепляешь ответ в виде DAG, витрины или алерта.

Чем предстоит заниматься

• Фрод и скам-аналитика: боты, мультиаккаунты, накрутки лайков, скам-схемы в чате, платёжный фрод, качество модерации — искать аномалии там, где схема постоянно меняется.

• Реклама и трафик: качество когорт по каналам и креативам, аномалии в закупке, подозрение на фрод трафика, окупаемость.

• Качество продукта и поведение пользователей: пути в матчинге и чате, где рвётся онбординг, поведение когорт, разбор просадок.

• Adhoc-задачи: «почему вчера просело», «правда ли, что…», «сколько мы теряем на…» — с горизонтом от часа до недели.

• Доводить расследования до регулярки: превращать разовый анализ в DAG, витрину под свои находки или алерт на аномалию, когда вопрос стал повторяющимся.

• Отдавать результат в продукт: выводы и регулярные расчёты в Yandex DataLens, на которые опираются команды в цикле «нашли — поправили — проверили».

Что мы ждём

• Уверенный SQL и Python для работы с сырыми данными на масштабе: не «беру готовую таблицу и группирую», а лезешь в события, ловишь дубли, поздние данные, краевые случаи.

• Сильное аналитическое мышление: сам превращаешь размытый вопрос в проверяемую гипотезу, строишь дерево альтернативных объяснений, отличаешь причину от корреляции, ловишь ловушки атрибуции и парадокса Симпсона.

• Опыт работы на масштабе: данные, где наивный запрос либо ляжет, либо честно соврёт — десятки-сотни миллионов строк, событийные потоки.

• Умение работать без готовой витрины: когда данных «как надо» нет, а есть только сырые логи.

• Доведение до результата: заканчиваешь не графиком, а рекомендацией с оценкой уверенности; при необходимости сам пишешь DAG для оркестратора.

• Комфортно с тем, что твои выводы оспаривают и проверяют коллеги — и готовность делать то же самое с чужими.

Будет плюсом

• Опыт антифрода, риск-аналитики, Trust & Safety, экономики/античита в играх или борьбы за качество платного трафика.

• dbt, ClickHouse, Airflow, событийные потоки и работа с поздними событиями.

• Домен дейтинга или другого двустороннего рынка — приятный бонус, но не обязателен.

Чего НЕ требуем

Идеального синтаксиса SQL наизусть и гочей конкретного диалекта, заученных формул статтестов без понимания, когда они врут, скорости письма «у доски», знания именно нашего стека. Если ты умел находить правду в данных на масштабе в другом стеке — перенесёшь.

Технический стек

SQL, Python, ClickHouse как хранилище, Airflow для оркестрации, dbt для закрепления повторяющихся расчётов, Yandex DataLens для отдачи результата. Источники — PostgreSQL (OLTP) и событийные потоки. Инфраструктура — российское облако (Yandex Cloud, managed ClickHouse).

Что предлагаем

• Реальное владение расследованием: от постановки вопроса до решения, которое меняет продукт или правило — а не выгрузка по чужому ТЗ.

• Масштаб и богатая фактура дейтинга: фрод, скам, качество трафика, поведение в матчинге и чате — где ошибка видна, а находка — заметна.

• Автономию в том, какие вопросы копать и какой глубины разбор нужен; направление обсуждаешь с архитектором и CTO.

• Настоящую инженерную систему, а не лозунги: доверие к данным и доведение расследования до результата — часть культуры, а не то, о чём напоминают.

• Формат: удалёнка, РФ.

О роли

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

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

За что ты отвечаешь

• Захват и доставку данных из продуктовых источников в аналитический контур: потоковый и пакетный ingestion, изменения и удаления, а не только «снимок на вчера».

• Надёжность доставки: идемпотентность и дедупликация, обработка поздних и переупорядоченных событий, воспроизводимый пересчёт после сбоя.

• Оркестрацию пайплайнов: запуск по готовности источников, а не по таймеру; зависимости, ретраи, бэкфиллы без даунтайма и без задвоения.

• Качество данных: тесты данных, проверки свежести и полноты, сверки с источниками, обнаружение аномалий — так, чтобы расхождение было видно раньше, чем его заметит потребитель.

• Наблюдаемость пайплайнов: метрики доставки, лаг, алерты на разрыв; разбор инцидентов данных до причины и защита от повтора.

• Контракты и эволюцию схемы: изменения источника не должны молча ломать поток; обратная совместимость и понятные границы ответственности.

Ты работаешь в связке с командой аналитики: ты отвечаешь за то, что данные доезжают надёжно, аналитика — за модель и метрики поверх них.

Кого мы ищем

Data Engineer, который владел движением данных целиком, а не писал разовые выгрузки. Для этого направления это значит:

• Инженерия доставки. Ты думаешь про гарантии доставки, идемпотентность и дедуп на рефлексе; перезапуск пайплайна для тебя не повод бояться дублей.

• Поток, а не только снапшот. Тебе близок захват изменений из меняющихся под тобой баз, поздние и out-of-order события, инкрементальная загрузка на больших объёмах.

• Качество как часть инженерии. Ты сам ставишь тесты данных, проверки свежести и сверки, а не ждёшь, пока кто-то заметит, что данных не хватает.

• Надёжность пайплайнов. SLA на свежесть, наблюдаемость, разбор инцидентов без поиска виноватого — для тебя это обычная инженерная гигиена.

• Зрелость в выборе. Ты решаешь, где достаточно at-least-once с дедупом, а где нужна более строгая семантика, и не усложняешь там, где не нужно.

Мы смотрим на доказанную глубину владения движением данных, а не на длину списка инструментов.

Будет плюсом

• Опыт построения потоковой доставки или захвата изменений с продуктовых баз на масштабе.

• Опыт бэкафилла большой истории и миграции хранилища без остановки потока.

• Опыт работы с платёжными или иными потоками, где дубль и потеря стоят дорого.

Чего НЕ требуем

Заученного синтаксиса конкретного оркестратора, сертификатов, знания именно нашего стека или домена дейтинга. Важнее инженерная зрелость и то, что данные у тебя доезжают надёжно и предсказуемо.

Технический стек

Потоковая и пакетная обработка данных, захват изменений (CDC), оркестрация пайплайнов, аналитические хранилища, Python и SQL.

Clickhouse, Apache Airflow

Что предлагаем

• Планку с нуля: команда данных собирается заново — то, что ты заложишь в надёжность и качество данных, станет стандартом.

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

• Автономию владельца — ты решаешь «как» движется поток данных; цели и направление обсуждаешь с командой и руководителем.

• Масштаб и большие данные, где инженерия движения имеет вес.

• Формат: удалёнка, РФ.