Analytics Engineer

- Dimensional modelling judgement: you can state the grain of a model, choose its keys, and place its logic in the right layer. - A git-based workflow: pull requests, CI checks, review discipline; plus Python for the tooling around the models. - Working fluency with AI-assisted engineering tooling. You set the task, review the output, and own what lands in production.

As a member of the Data Engineering team, you will own the modelling for the domains assigned to you, and the programme's cross-cutting craft: the dbt layer standards and the tooling that enforces them. This is a hands-on modelling role for someone who wants their name on the rules, not just on the tickets. You will decide what "correct" looks like for a model, prove it with numbers, and make the standard checkable by script rather than by memory. You will work in an AI-assisted engineering workflow, where agentic tooling accelerates the work but the modelling decisions: grain, layer, parity. You will work as one half of a deliberate pairing: the Data Engineering team on the technical side, Product Analysts embedded in the product pods, one per business domain on the business side. Product Analysts own what the domain means, the certified metrics and their definitions, and whether the result is right in business terms. Analytics Engineering owns the technical spectrum: modelling, layers, grain, keys, tests, parity, and the standards and tooling the models are built to. Both halves write SQL and dbt; they bring the domain, you carry the technical bar, and the two halves answer for the same number. What You Will Be Doing

- 3+ years in analytics engineering or data engineering, with production ownership of transformation models. - Expert SQL: window functions, CTEs, and multi-entity joins at warehouse scale; strong in the SQL Server / T-SQL dialect today, and fluent enough in PostgreSQL to move with the platform. - Hands-on dbt. You have built and maintained a dbt project (models, layers, refs, tests, documentation), not only run someone else's.

- A warehouse platform migration you helped carry: engine, dialect, or both. - Experience migrating stored procedures or warehouse SQL into a transformation framework such as dbt. - Airflow (or similar) orchestration experience.

The Position OPSWAT's data platform turns CRM and business-system data into governed, documented, tested tables that business teams can read without asking what a column means. It is built on dbt Core, layered source → staging → intermediate → mart, and it is migrating on two fronts: a large estate of legacy stored procedures into that model, one domain at a time, with value parity proven before anything is cut over and the warehouse platform itself, from Microsoft Fabric Warehouse to Azure PostgreSQL, potentially an Elastic Cluster. You will work across both engines while that move completes. As a member of the Data Engineering team, you will own the modelling for the domains assigned to you, and the programme's cross-cutting craft: the dbt layer standards and the tooling that enforces them. This is a hands-on modelling role for someone who wants their name on the rules, not just on the tickets. You will decide what "correct" looks like for a model, prove it with numbers, and make the standard checkable by script rather than by memory. You will work in an AI-assisted engineering workflow, where agentic tooling accelerates the work but the modelling decisions: grain, layer, parity.

What You Will Be Doing - Model the business domains you are assigned in dbt Core from their source tables through layered staging and intermediate models to tested marts; working across Microsoft Fabric and Azure PostgreSQL as the platform migrates. - Work as the technical counterpart to the Product Analysts who own each business domain: they bring the business definition and the questions the data must answer; you make the models correct, tested, and proven by parity.

It Would Be Great If You Also Have - Azure PostgreSQL (Elastic Cluster), Microsoft Fabric Warehouse, OneLake, or another Delta lakehouse in your background. - A warehouse platform migration you helped carry: engine, dialect, or both.

OPSWAT's data platform turns CRM and business-system data into governed, documented, tested tables that business teams can read without asking what a column means. It is built on dbt Core, layered source → staging → intermediate → mart, and it is migrating on two fronts: a large estate of legacy stored procedures into that model, one domain at a time, with value parity proven before anything is cut over and the warehouse platform itself, from Microsoft Fabric Warehouse to Azure PostgreSQL, potentially an Elastic Cluster. You will work across both engines while that move completes. As a member of the Data Engineering team, you will own the modelling for the domains assigned to you, and the programme's cross-cutting craft: the dbt layer standards and the tooling that enforces them. This is a hands-on modelling role for someone who wants their name on the rules, not just on the tickets. You will decide what "correct" looks like for a model, prove it with numbers, and make the standard checkable by script rather than by memory. You will work in an AI-assisted engineering workflow, where agentic tooling accelerates the work but the modelling decisions: grain, layer, parity. You will work as one half of a deliberate pairing: the Data Engineering team on the technical side, Product Analysts embedded in the product pods, one per business domain on the business side. Product Analysts own what the domain means, the certified metrics and their definitions, and whether the result is right in business terms. Analytics Engineering owns the technical spectrum: modelling, layers, grain, keys, tests, parity, and the standards and tooling the models are built to. Both halves write SQL and dbt; they bring the domain, you carry the technical bar, and the two halves answer for the same number.

- Build the tested marts that certified metrics sit on, so a Product Analyst's definition and the model beneath it never drift apart. - Prove value parity between each dbt mart and the legacy stored procedure it replaces: row counts and key aggregates recorded, not asserted, before any consumer is repointed. - Own and evolve the dbt layer standards, what belongs in each layer, where collation is normalised, one path in per source and the scripts that enforce them.

- Prove value parity between each dbt mart and the legacy stored procedure it replaces: row counts and key aggregates recorded, not asserted, before any consumer is repointed. - Own and evolve the dbt layer standards, what belongs in each layer, where collation is normalised, one path in per source and the scripts that enforce them. - Declare and test primary keys, and write tests that fail when the model breaks, not checks that pass no matter what the data does.

- Declare and test primary keys, and write tests that fail when the model breaks, not checks that pass no matter what the data does. - Repoint consumers from legacy procedure outputs to dbt models in the right order (readers before procedures), and record each cutover so the sequence is auditable. - Work with your Data Engineering teammates to keep the production dbt build on schedule, so parity is a number tracked daily rather than a measurement obtained occasionally.

- Repoint consumers from legacy procedure outputs to dbt models in the right order (readers before procedures), and record each cutover so the sequence is auditable. - Work with your Data Engineering teammates to keep the production dbt build on schedule, so parity is a number tracked daily rather than a measurement obtained occasionally. - Review pull requests on the models you own within one working day; they are production-facing, so a mistake there has no legacy fallback.

- Expert SQL: window functions, CTEs, and multi-entity joins at warehouse scale; strong in the SQL Server / T-SQL dialect today, and fluent enough in PostgreSQL to move with the platform. - Hands-on dbt. You have built and maintained a dbt project (models, layers, refs, tests, documentation), not only run someone else's. - Dimensional modelling judgement: you can state the grain of a model, choose its keys, and place its logic in the right layer.

- Experience migrating stored procedures or warehouse SQL into a transformation framework such as dbt. - Airflow (or similar) orchestration experience. - Data-quality, lineage, or parity/audit tooling in your history.