Role Description
We are hiring a Senior Data Engineer to build, hands-on, inside a production Snowflake platform that another engineer architects. You own workstreams end-to-end, and you write the models and tests that guard them. You also work inside layer contracts you did not design, and the senior engineers who do well here tell us when one of those contracts is wrong instead of routing around it.
The placement is the BrandVue platform, a weighted consumer survey measurement product built on Snowflake, dbt, and Python. Xenoss is a boutique adtech engineering services company, and we rebuild data platforms across a rotating set of clients. We scope this seat to one engagement and hire people we expect to take onto the next one.
Every output of this platform is a population-weighted statistic, so a broken calculation produces a plausible number rather than an error. We have shipped three defects of that shape. An engineer reading code caught all three; no test caught any of them. We screen harder for an instinct about this than for anything else on the list below.
About the Project
Client: UK market-research company. Flagship product BrandVue, a brand-tracking platform measuring consumer attitudes via monthly surveys (50+ metrics: awareness, consideration, brand love, NPS). Clients buy the results as a subscription dashboard, a commercial API, and governed data shares.
Xenoss builds and supports the measurement, canonical, and delivery tiers. The original scope covered packaging only. That changed when the client’s derived layer proved unreliable, and we replaced it with our own calculation engine, which now weights every metric to national population benchmarks. When a metric is wrong, it is ours.
Where the platform stands
- Layers are built. Metric output matches the live product in the UK, US, and DE. The other four territories are in progress. You would join a working system with a known list of gaps
- Measurement tier: a closed-grammar calculation engine implemented as a Snowpark Python dbt model, plus per-month IPF weighting we reconstructed from scratch
- Canonical tier: ~2,190 metric definitions active for drinks in the registry, plus brand, geography, question, wave, and weighting registries, generated from the client’s own configuration rather than hand-typed
- Delivery tier: registry-driven code generation, so served SQL carries no per-metric logic; aggregates store additive components rather than computed ratios, so any rollup is a sum then a divide
- Open work you would pick up: weighting and validation coverage for ES, FR, IT and IE, row-level entitlement (designed, not built), and the existing test packs, which no pipeline runs
Environment reality that shapes the role
- Mono-repo working model — Xenoss can open PRs but cannot merge. Client approval required (segregation of duties)
- Two Snowflake accounts (UK + US) — a multi-account topology to work around
- Client’s team is migrating the upstream layer in parallel, so it moves under you
- Builds are namespace-parameterised: one neutral model set, many sectors. Give a build no explicit scope, and it builds the default, with no error and no warning. Silent-wrong-output is the house defect class, and it hides in configuration as often as in code
- A substantial test suite exists across all three tiers, but no pipeline runs it. Each quality gate is a local command someone has to remember
- The architect who built most of this is moving to limited hours, so self-sufficiency and written reasoning matter more here than they would on a fully staffed team
Key Responsibilities
dbt and SQL model development (the core of the job)
- Build and maintain models across all three tiers — measurement, canonical registries, and the served facts, aggregates, and dictionaries
- Work within the established contracts: a model references another database through its interface views, never its internal schemas
- Extend registry-driven code generation instead of hand-writing per-metric logic. The generated layer stays generated
- Own incremental and materialisation behaviour: rebuild what changed, and leave closed history alone
Measurement and calculation engine
- Work inside a closed-grammar calculation engine, where adding a capability means adding a grammar atom rather than a special case
- Extend and validate per-month IPF weighting reconstruction, including territories we have not yet covered
- Onboard new sectors and territories through namespace parameterisation instead of forking models
- Mark unsupported cases as unhandled, with a recorded reason, and leave the approximation out
Serving layer and data products
- Build additive aggregate structures that store the components of a ratio, so any rollup stays a sum followed by one division
- Maintain the dimensions, data dictionary and metric catalogue that consumers read
- Build and extend the serving surfaces — table functions, procedures and extract paths — used by dashboards, analysts and file exports
- Support the row-level entitlement model as we build it out across dashboard, data share and marketplace
Quality, testing and correctness
- Write coverage assertions as well as shape assertions. A partition that produces no rows should fail the build. Today it passes the suite
- Extend parity validation against the live product. A metric is finished when it reconciles
- Help move the existing test packs from local commands into enforced automation
- Prefer explicit failure over plausible approximation. Three separate defects taught us that one
Pipelines and productionisation
- Author and maintain the orchestration DAGs that run the layer builds
- Work with schema migration tooling and environment promotion across dev, test and live
- Land changes carrying the evidence an external approver needs, since we cannot merge our own work
- Watch warehouse cost. A materialisation decision carries a bill
Ways of working
- Small pod, two-week sprints, and a weekly client call. You demo your own work to the client
- Documentation is a deliverable: runbooks, dictionary entries, and the reasoning behind a decision as well as its outcome
- Take knowledge off a departing architect on a defined agenda rather than by shadowing him
Required Qualifications
Experience
- 5-8 years in data engineering, with a track record of owning what you shipped
- Built and operated analytical data models in a cloud data warehouse at scale (tens of millions of rows upward), including performance and cost work
- Worked in a codebase with consequences, data someone paid for, or on which a decision depended
- Has found and fixed a wrong number, and can describe both halves: how they caught it, and what they changed afterwards so it could not recur
- English: strong written and spoken (B2+ / C1). The role is documentation-heavy with direct client visibility
Technical Acumen (project-critical)
- SQL — expert. Window functions, complex aggregation, and the ability to reason about execution plans and query cost as well as correctness
- dbt — hands-on and fluent: models, tests, macros, incremental strategies, materialisations, lineage. Able to work inside an established project and keep to its conventions
- Snowflake — practical depth: Dynamic Tables, Streams and Tasks, clustering, warehouse sizing, cost awareness, secure views
- Python — production quality, including warehouse-side Python (Snowpark UDFs and stored procedures) as well as orchestration code
- Data testing — treats it as design work. Knows the difference between asserting the shape of the rows present and asserting that the rows you expected arrived at all
- Orchestration — Airflow: DAG authoring, dependency management, backfills, reruns
- Version control and CI — Git fluency, PR-based workflow, code review, deployment pipelines
- Data modelling — dimensional modelling, canonical and master-data concepts, versioned and slowly-changing data, lineage
Judgement & Soft Capabilities
Tooling is table-stakes here, and we can verify it in an hour. We spend the rest of the interview on something harder to check: whether you read code you did not write, notice that something does not add up, and say so instead of assuming the last person knew better. That habit has caught more in this codebase than the test suite has.
We also need self-sufficiency, because the person holding the answers works limited hours. The upstream layer changes underneath you and the specification arrives incomplete. Sometimes the right move is to ask the client and wait.
Nice to Have
- Market-research or weighted-survey data — weighting methodology, sample-size and suppression sensitivity, panel data (the closest fit to this seat)
- Semantic-layer or metric-store experience — one governed definition serving several consumers
- Snowflake governance features — row access policies, masking, classification, secure sharing, Marketplace listings
- Streamlit or similar for internal data tooling and stewardship applications
- AdTech or other high-volume event-pipeline background — programmatic, identity, measurement. Our pipeline skews adtech, so this travels beyond the current engagement
- Platform-agnostic warehouse depth — BigQuery, Databricks or Redshift alongside Snowflake
- Vendor or consulting-side experience, working inside a client’s governance rather than your own
