Job description Sr.

Data / ETL Engineer Punch List Digital is hiring a Senior Data / ETL Engineer to own the data foundation of its AI platform: the pipelines that pull marketing performance data from partner APIs, the storage layer that receives it, and the transformation layer that produces the trusted KPI feed behind every chat answer and report the platform delivers.

We are looking for someone who has operated production pipelines against rate-limited third-party APIs, treats idempotent and recoverable synchronization as table stakes, and is as comfortable writing up a storage decision as implementing it.

In this system, an undetected data failure becomes an incorrect figure in front of a client.

That is the standard the engineering is held to.

Both surfaces are only as credible as the data beneath them.

That data originates in the marketing platforms our clients use — Google Analytics 4, Google Ads, SEMrush, Monday.com, and What

Converts, with more sources to follow — and reaches the product exclusively through the integrations this role builds.

You own the path from those platforms to a single, trusted view of client performance — the inbound flow of data, the foundation it rests on, and the contract that lets the rest of the platform depend on it with confidence.

The questions that define that foundation are yours: What a trustworthy data foundation for this product looks like, and how to get there without over-engineering.

How every source stays current, complete, and consistent as the client base and the number of integrated platforms grow.

What guarantees the rest of the platform needs from the data layer, and how those guarantees are made explicit and kept stable.

How a problem is caught before anyone downstream feels it.

This is a senior, hands-on position on a small team that is still taking shape.

Every figure that reaches a client passes through the foundation you build.

The opportunity Build the foundation.

The data layer the rest of the product rests on, designed from the ground up rather than inherited.

Production data at scale.

Live performance data across five marketing product lines and several hundred clients.

Users who depend on the output daily.

Strategists, client success, sales, and external clients act on figures this layer produces.

Meaningful consequences. A gap in the data does not stay internal; it becomes an incorrect figure in a client conversation.

Genuine ownership.

The architecture, the tooling, and the shape of the data contract are open decisions — yours to make, document, and defend.

The perspective we expect The role takes more than strong implementation.

The engineer we hire will: Understand how each pipeline affects clients and internal teams — retention, expansion, time returned — and let that understanding set priorities.

See the system end to end: how a missed backfill shows up in a monthly report, how an unannounced schema change in a partner API becomes an incorrect KPI, and how an expedient shortcut becomes a future incident.

Treat a stale or double-counted figure reaching a client as the most expensive defect the pipeline can produce, and design freshness checks, reconciliation, and alerting accordingly.

Explain storage and pipeline trade-offs clearly to engineers outside the data discipline and to strategists who only ever see the finished report.

Measure their own success by the freshness, completeness, and correctness of the KPI feed — and by how rarely anyone downstream has to question the data.

Key responsibilities Per-source ETL pipelines.

Scheduled and incremental extraction from each marketing platform, with retry and backoff, rate-limit-aware scheduling, idempotent upserts, and backfills that re-run safely for any client and date range.



API integrations.

The production integration with each source: Google Analytics 4, Google Ads, SEMrush, Monday.com, and What

Converts today, with new platforms added as the product grows.

The craft here is authentication (OAuth flows, service accounts, API keys, token refresh and rotation), pagination and cursor handling, per-source rate limits and quota budgeting, schema-drift detection so an upstream field change never silently corrupts a KPI, contract tests against recorded API fixtures, and observability on every call — request volume, latency, error class, and quota consumed per source and client.

You should be able to pick up a new REST API quickly, understand its limits, and design around its failure modes.

The raw and staging data store.

Both the decision and the implementation: the same Postgres instance the application runs on, or a separate analytical engine such as Click

House or Big

Query, sized to absorb write-heavy ingestion without constraining the reporting layer.

The outcome is a documented trade-off with the alternatives considered.

The transformation layer.

The models that turn raw source data into the KPI outputs feeding the PostgreSQL report tables the application reads.

This is the contract with the application layer — defined early, documented, and versioned, because both the chat and report surfaces depend on it.

Pipeline monitoring and alerting.

Freshness checks per source and client, row-count and reconciliation checks against the source API, quota tracking per source, and alerts that fire before a stale or partial dataset reaches a client-facing surface.

Source documentation.

For every API: authentication method, rate limits, refresh cadence, known behaviors, and the downstream effect of unavailability — written down so the platform can be operated by more than one person.

Orchestration.

The scheduling mechanism — cron, queues, or a workflow tool — selected, justified in writing, and observable.

Production reliability.

Quota exhaustion, expired credentials, partial extractions, late-arriving data, upstream outages, and the backfills that follow.

Instrumentation precedes conjecture, and decisions are recorded in writing.

Qualifications 4–6 years of data engineering experience , including ETL pipeline design in production and accountability for the outcome when pipelines failed. A record of production third-party and partner API integrations. OAuth and service-account authentication, pagination, rate limiting with backoff and quota budgeting, incremental sync design, weathering schema and contract changes without silent corruption, contract or fixture-based testing, and instrumentation that flags a degraded source before users notice.

Learning new REST APIs quickly is essential; direct experience with Google Analytics 4, Google Ads, SEMrush, Monday.com, or What

Converts helps but is not required.

Strong SQL and schema design for analytical workloads.

Dimensional and incremental modeling, partitioning, indexing, and query-plan analysis.

The KPI layer lives in PostgreSQL, and the reporting queries against it must stay correct and performant as data volumes grow.

Judgment in choosing the right store for write-heavy and analytical data, and the ability to defend that choice in a concise written trade-off.

Command of idempotent sync, retry and backoff,



and quota management.

Pipelines that re-run safely and fail visibly — and a clear answer for how double-counting is avoided when an extraction is retried partway through.

Clear written communication.

Source documentation, design notes, and trade-off analyses that a backend engineer, a strategist, and a CTO can each read and act on.

Sound judgment on data accuracy. A stale or double-counted figure reaching a client is the most expensive defect this pipeline can produce, and the design of monitoring and freshness gates should show that you believe it.

Preferred qualifications The marketing or advertising data domain: attribution, campaign metrics, keyword and ranking data, or call tracking.

Workflow orchestration tools such as Airflow, Dagster, Prefect, or n8n.

Production experience with a separate analytical engine such as Click

House or Big

Query — and the judgment to recognize when Postgres is enough. dbt or a comparable transformation framework.

Pipelines whose consumers are AI or LLM systems, where data quality directly determines answer quality.

Multi-tenant client data and the access-control patterns that come with it.

How we work We write things down.

Big decisions — storage, orchestration, schema — get a short write-up of what we chose and why, so the next person (or you, six months later) doesn't have to reverse-engineer the reasoning. A page is usually enough.

We build checks in from the start.

Freshness and reconciliation checks ship with the pipeline, not after the first incident.

It's far cheaper to catch a gap in monitoring than in a client meeting.

We agree on interfaces early.

The KPI feed is the handshake between the data layer and the product, so we define it together and talk before changing it — which frees you to work independently everywhere behind it.

We learn from corrections.

When someone on the team spots and fixes a wrong figure, that's valuable signal: we feed it back into the checks so the same issue can't slip through twice.

Pace follows risk.

Experiments and internal tooling move fast and loose; anything on the path to a client-facing figure gets more care.

You'll have room to try things without ceremony where mistakes are cheap.

How success is measured Success shows up in the freshness and completeness of the KPI feed against each source API, in the absence of quota incidents and undetected sync failures, in a stable KPI contract the product surfaces can depend on, and in the absence of incorrect figures reaching a client.

Hiring process Culture Index assessment (5 minutes) - short questionnaire to help determine culture fit Introductory call (30 minutes).

Mutual fit, background, and questions.

Technical deep dive (60–90 minutes). A walkthrough of one production data platform you owned end to end, covering: an external API that changed unexpectedly — a rate limit, an authentication change, a schema change — how it was detected, and what changed as a result; a quota or throttling incident and how extraction was re-planned afterwards; a backfill executed safely against live data, and how you verified the absence of double-counting; a storage decision — shared database or separate engine — and the business reasoning behind it.

Working session with the team. A representative problem from our domain, worked through together.

Offer.

Candidates who can speak to those four experiences in concrete terms can expect the process to move quickly.

Company Braintrust is a global talent network that connects top independent professionals with leading companies for high-quality, versátil work.

We help organizations hire skilled talent faster while giving professionals access to vetted opportunities with innovative teams.

📌 Sr. Data / ETL Engineer (LATAM - Remote) (México)
🏢 Braintrust
📍 México