Ведущий Data Engineer (архитектор решений)

Что предстоит делать

<p>Мы нанимаем <strong>Lead Data Engineer</strong>, который работает как <strong>hands-on Solution Architect</strong> — старший инженер, который проектирует архитектуру и пишет код, способен отстаивать свою позицию в прямом техническом споре со старшим архитектором со стороны клиента и проводит discovery по неоднозначным, частично определенным брифам. Это технический центр тяжести для небольшой delivery-команды, а не отстраненная надзорная роль.</p><p>Непосредственное размещение — на проекте по созданию корпоративной data-платформы с использованием Snowflake, dbt и Azure DevOps, но это, по сути, найм с двойной перспективой. Xenoss — это бутиковая adtech-сервисная компания, которая создает, масштабирует и перестраивает data-платформы с нуля для разных клиентов и стеков. Правильный кандидат должен соответствовать жестким техническим требованиям текущего проекта И обладать более широким профилем компетенций, чтобы возглавлять будущие проекты, которые в основном относятся к adtech. Глубокое понимание adtech-платформ — самый сильный сигнал такого потенциала для будущих проектов.</p><p>В этом поиске особенно высоко ценятся две компетенции, отражающие области, в которых мы хотим получить больше глубины, чем было у уходящего архитектора:</p><ol><li>Более глубокий опыт в adtech — programmatic, DSP/SSP/DMP/CDP, измерение рекламы, разрешение идентификаторов;</li><li>Современное мастерство в облачной data-инженерии, конкретно на стеке Snowflake + dbt + Azure.</li></ol><h3>О проекте</h3><p>Клиент: британская компания, занимающаяся маркетинговыми исследованиями. Ее флагманский продукт — платформа для отслеживания брендов, которая измеряет потребительские предпочтения с помощью ежемесячных взвешенных опросов по более чем 50 метрикам, включая осведомленность, рассмотрение, лояльность к бренду и NPS. Продукт является частью более широкой аналитической экосистемы, поэтому все, что создается, должно быть совместимо с общей платформой, а не с отдельным приложением.</p><p>Xenoss строит Gold-слой — слой управления и упаковки на Snowflake, расположенный поверх существующего Silver-слоя клиента. Руководящий принцип — «создай один раз, используй многократно»: один управляемый слой, питающий дашборды, коммерческий API, Snowflake Marketplace и прямые корпоративные общие данные (data shares) через единые механизмы контроля доступа.<br><br></p><h3>Реальная среда, формирующая роль</h3><ul><li><b>Среда Snowflake «с нуля» на старте</b> — нет CI/CD, тестов, контрольных точек качества (quality gates), версионирования, при этом работа ведется с живым бизнес-критичным набором данных. Архитектор проектирует основы production-инфраструктуры с нуля.</li><li><b>Модель работы с единым репозиторием (mono-repo)</b> — Xenoss может открывать PR, но не может делать merge. Требуется одобрение клиента (разделение обязанностей).</li><li><b>Два аккаунта Snowflake (UK + US)</b> — необходимо проектировать архитектуру для мульти-аккаунтной топологии.</li><li><b>Silver-слой — движущаяся цель, активно мигрируется параллельно</b> — архитектор проектирует, имея дело с неполными, изменяющимися входящими данными.</li><li><b>Архитектура через переговоры</b> — большинство важных решений принимаются совместно со старшим инженером-архитектором клиента, который владеет ~70% технических зависимостей со стороны клиента.</li></ul><h3>Ключевые обязанности</h3><p><strong>Решение архитектурных задач (hands-on):</strong></p><ul><li><b>Владеть сквозной архитектурой Gold-слоя Snowflake</b> — и лично создавать его, а не просто рисовать диаграммы.</li><li><b>Проектировать управляемые слои потребления по принципу «создай один раз, используй многократно» (один упакованный слой, питающий):</b></li><ul><li>Дашборды платформы клиента,</li><li>Snowflake Marketplace,</li><li>Прямые общие данные (Direct shares)</li></ul><li><b>Принимать и отстаивать важные структурные решения</b> (например, топология dbt-проекта, каноническая модель идентификации, размерность, дизайн цепочки происхождения данных (lineage)).</li><li><b>Уважать границы вышестоящих источников истины</b> — упаковывать и управлять, не пересчитывая бизнес-логику, принадлежащую другим.</li><li><b>Обеспечивать перспективность схемы для известных будущих потребностей</b> (связывание идентификаторов, clean-room), не создавая избыточных решений сегодня.</li></ul><p><strong>Инженерия Snowflake &amp; dbt:</strong></p><ul><li><b>Проектировать и реализовывать в масштабе миллиардов строк</b> — Dynamic Tables, Streams + Tasks, стратегия кластеризации и материализации, управление p95 latency.</li><li><b>Создавать многотенантные права доступа на основе Row Access Policy (RAP)</b>, маскирующие макросы, политики классификации и подавления.</li><li><b>Проектировать Secure Shares и продукты данных для Marketplace:</b> версионированные, управляемые, документированные, с примерами запросов.</li><li><b>Определять стратегию трансформации dbt для среды</b> — структура mesh / multi-project, контракты, материализация, тесты, происхождение (lineage) и версионирование моделей данных для управляемых контрактов на наборы данных.</li><li><b>Создавать Snowpark UDF/процедуры</b> на Python, где это необходимо.</li></ul><p><strong>Перевод в production в незрелой среде (Azure):</strong></p><ul><li><b>Настроить CI/CD для Snowflake на Azure DevOps с нуля</b> (не GitHub Actions — решено на воркшопе с клиентом).</li><li><b>Проектировать с учетом тестируемости, версионирования и возможности продвижения (promotability)</b> — чисто работать в рамках ограничений PR-процесса без права merge и разделения обязанностей.</li><li><b>Внедрить</b> контрольные точки качества (quality gates), мониторинг/оповещение и управление затратами Snowflake там, где их не было.</li><li><b>Спроектировать blue/green развертывание</b> для слоя управления.</li></ul><p><strong>Discovery, Оценка объема работ и Взаимодействие с клиентом по архитектуре</strong></p><ul><li><b>Проводить discovery по расплывчатым или частично определенным брифами</b> — отделять реальный объем работ от предполагаемого и защищать маржу проекта.</li><li><b>Отстаивать свою позицию в прямом техническом споре</b> со старшим архитектором клиента — корректно признавать неправоту, когда ошибаешься, и в идеале самостоятельно приходить к тому же решению.</li><li><b>Гибко менять регистр общения в зависимости от аудитории:</b> коммерческой (Head of Data Products), технической (архитектор клиента), delivery (PO) и аналитики (конечные пользователи).</li><li><b>Относиться к документации как к результату работы</b> — разделы PRD, контракты на наборы данных, словарь данных, обоснование в стиле ADR, проверяемые инженерами и продукт-менеджерами клиента.</li></ul><p><strong>Лидерство в команде и Delivery</strong></p><ul><li><b>Выступать техническим центром тяжести для команды из 3 FTE</b> (формирование архитектуры и delivery, а не управление людьми).</li><li><b>Вести 2-недельный спринт</b> — планирование, демо, еженедельные статус-коллы, проверки go/no-go по этапам.</li><li><b>Принимать и доводить до завершения текущие архитектурные решения</b> — фиксировать обоснование, а не только результаты.</li></ul><h3>Требуемая квалификация</h3><ul><li><b>12+ лет в разработке ПО / data-инженерии</b> с солидным опытом в решении архитектурных задач И продолжением практической hands-on работы.</li><li><b>Подтвержденный опыт проектирования и создания production data-платформ в большом масштабе</b> (миллиарды строк; умение рассуждать о таблицах с миллиардами строк).</li><li><b>Продемонстрированная ответственность за архитектуру в контексте работы с клиентом или консалтинга</b> — опыт отстаивания архитектурной линии перед старшими инженерами клиента.</li><li><b>Опыт внедрения production-дисциплины</b> (CI/CD, тестирование, управление) в незрелой среде или среде «с нуля».</li><li><b>Английский язык:</b> уверенный письменный и устный (эффективно C1+) — это роль, предполагающая работу с клиентом, обильную документацию и общение в разных регистрах.</li></ul><p><strong>Технические знания (критически важные для проекта)</strong></p><ul><li><b>Snowflake — глубокие, практические знания:</b></li><ul><li>Dynamic Tables,</li><li>Streams + Tasks,</li><li>Кластеризация/оптимизация,</li><li>Производительность в масштабе миллиардов строк,</li><li>Понимание стоимости</li></ul><li><b>Row Access Policies (композиция + производительность)</b>, secure views/shares, мульти-аккаунтная топология</li><li><b>dbt</b> — структура mesh / multi-project, контракты, материализация, тесты, происхождение (lineage); способность определять стратегию фреймворка трансформации для новой среды, а не просто эксплуатировать существующую</li><li><b>Azure</b> — Azure DevOps для CI/CD пайплайнов (развертывание Snowflake) и уверенная работа в более широкой экосистеме данных Azure</li><li><b>Python</b> — production-код для data-инженерии; Snowpark UDF/процедуры; API-сервисы (FastAPI или эквивалент: JWT-аутентификация, фильтрованный экспорт, presigned URLs)</li><li><b>SQL</b> — экспертный уровень, включая проектирование и оптимизацию запросов в масштабе хранилища данных</li><li><b>Оркестрация</b> — Airflow (или эквивалент) для планирования пайплайнов и управления зависимостями</li><li><b>Моделирование данных</b> — проектирование канонической идентификации / мастер-данных, размерное моделирование, медленно меняющиеся / версионированные данные, дизайн происхождения (lineage)</li><li><b>Управление данными (Data governance)</b> — многотенантный контроль доступа, маскирование, классификация, подавление, упаковка коммерческих продуктов данных</li></ul><p><strong>Суждения и Soft Skills</strong></p><p>Ключевые моменты в этой роли — это звонки по определению объема работ и независимое сближение архитектурных решений с клиентом, а не просто «знание Snowflake».</p><h3>Желательно</h3><p><b>Переносимые / перспективные компетенции</b> — фактор, который отличает того, кто может вести наш следующий проект, от того, кто может только заполнить эту позицию. Поскольку портфель проектов Xenoss в основном состоит из adtech-проектов, реальная глубина в adtech здесь является самым сильным сигналом, а не просто опциональным дополнением.</p><ul><li><b>Глубокое понимание AdTech-платформ</b> — programmatic, DSP / SSP / DMP / CDP, измерение/атрибуция рекламы, конвейеры событий с высоким объемом, разрешение идентификаторов, clean rooms. (Оценивается высоко — решающий фактор для будущих проектов.)</li><li><b>Глубокое понимание облачных DW, независимое от платформы</b> — способность повторить те же рассуждения на BigQuery / Databricks / Redshift, если будущий клиент будет использовать другой стек.</li><li><b>Коммерческое чутье в области продуктов данных / DaaS</b> — контракты на версионированные продукты данных, упаковка листингов Marketplace, Snowflake Native Apps.</li><li><b>Опыт руководства миграцией баз данных</b> — например, SQL Server -> Postgres в масштабе миллиардов строк (сопоставление схем, параллельная выгрузка, переключение с dual-write).</li><li><b>Знакомство с данными маркетинговых исследований / взвешенных опросов</b> — чувствительность к выборке/подавлению (актуально конкретно для текущей позиции).</li><li><b>Опыт работы с MarTech / CRM платформами (Salesforce Marketing/Service Cloud)</b> — смежная область с основным adtech-направлением.</li><li><b>Опыт пресейла / инициации проектов</b> — создание клиентских архитектурных артефактов и предложений.</li></ul><h3>Профиль идеального кандидата</h3><p><br><b>Правильный кандидат — это практикующий архитектор (hands-on architect)</b> — достаточно широкого профиля, чтобы отвечать за архитектуру, форму delivery и доверие клиента; и достаточно глубокого, чтобы быть неоспоримо компетентным в глазах старшего инженера клиента. Он провел свою карьеру, создавая реальные платформы, которые работают в production в масштабе, и он все еще пишет код. Он не «слайд-дечный» архитектор.<br><b>Он мыслит категориями производительности на миллиардах строк</b>, может определить стратегию dbt для новой среды и знает, как настроить CI/CD и управление (governance) в незрелой среде Snowflake, не нарушая работу живого бизнес-критичного набора данных. Snowflake, dbt и Azure DevOps — это действительно его инструменты, а не просто строки в резюме.<br><b>Критически важно, что он обладает способностью принимать решения в условиях неопределенности:</b> он проводит discovery по расплывчатому брифу, отделяет реальный объем работ от предполагаемого и формирует обоснованное архитектурное видение, которое может отстаивать — и пересматривать — в живом споре со старшим архитектором клиента. Он естественно переключает регистр общения между коммерческой, технической, продуктовой и аналитической аудиториями и относится к документации как к результату работы первого класса.<br><b>Самые сильные кандидаты обладают реальной глубиной в adtech</b> — они проектировали высоконагруженные programmatic-, identity- или измерительные data-системы. Для Xenoss это напрямую соотносится с будущим портфелем проектов гораздо сильнее, чем предметно-нейтральный data-архитектор равной технической силы, и это самый четкий сигнал того, что этот человек сможет возглавить следующий проект, а не просто выполнить текущий.</p> <div> <a href="https://jobs.dou.ua/companies/xenoss/vacancies/362234/#reply-btn-id">Откликнуться на вакансию</a> </div>