Data Engineer

The Role
You own the data substrate and the batch runtime of a product we
are building from scratch. This is a data-specialist seat, not a
general backend seat. Routine application development is guided
in weekly reviews; what cannot be substituted is your depth in
data modeling, set-based computation, and pipeline correctness.
You will work self-directed, writing your own specs and decisions,
with your tests and documentation carrying the quality bar
between reviews.
Stack: Python, PostgreSQL, Django, server-rendered frontend
(htmx).

What You Will Own

• Third-party data ingestion, done deeply. Webhooks drop
silently, so reconciliation against source-of-truth totals is
not optional.
• Batch computation over large datasets as set-based SQL,
inside fixed nightly windows.
• Multi-tenant isolation as a reliability property. One tenant’s
bad data must never degrade another tenant’s run.
• Backfill and replay as designed capabilities, not emergency
scripts.
• Append-only, auditable records. Every automated decision
must be reconstructable.
• Vendor API integrations built for failure: circuit breakers,
retries, reconciliation.
• The operational substrate: alerting, partitioning, idempotent
jobs.
What We Are Looking For
Required
• Around 5 to 8 years building and operating production
systems. Years are a proxy; the points below are the bar.
• Deep Postgres: schema design, query plans, batch
performance at real scale.
• You have owned data pipelines in production: ingestion,
transformation, reconciliation, serving. Not application
CRUD against an ORM. Moving and reshaping data is the
job you have actually done, whatever your resume calls it.
• You think in sets, not loops. Multi-step SQL
transformations, window functions, statistical aggregates
(percentiles, distributions), and incremental computation
are your native mode, and you have turned raw event or
order data into cohort, retention, or funnel metrics.
• Production Python backend experience in any framework.
You keep business logic cleanly separated from framework details, which is exactly why the framework does not
matter.
• Tests are how you build, not what you add later. Batch jobs
and reconciliations especially, where a bug means silently
wrong data for weeks.
• War stories: queues backing up, webhooks silently
dropping, reconciliations catching data loss nobody
noticed.
• Strong written communication. This is a documentation-
driven team, and the way we build runs on written specs
and decisions.
• Comfortable owning outcomes and building from scratch
with minimal supervision.

Good to have
• Production Django.
• E-commerce or D2C platform experience.
• Streaming or event-architecture experience (Kafka-class
systems).
• Familiarity with probabilistic data structures (HyperLogLog,
Bloom filters, t-digest).
• Comfort building the occasional server-rendered screen.