Hire Data Engineers remotely from our vetted global talent

A data engineer owns the path data takes from operational systems into the warehouse, the lakehouse, and the downstream products that consume it: the ingestion connectors, the transformation models, the orchestration that schedules them, and the contracts that keep producers and consumers from breaking each other. The role exists because moving data reliably at scale is its own discipline, distinct from the backend engineer who writes to operational stores and the data scientist who reads from the warehouse. At Terminal, data engineering hires are the engineers product and analytics teams reach for when the pipeline is the bottleneck.

Ingestion and ELT: How data leaves the source system and lands in the warehouse.

• Managed connectors via Fivetran, Airbyte, or Stitch for SaaS sources and operational databases

• Custom Python ingestion when the source is a webhook, an obscure API, or a vendor without a connector

• Change data capture from Postgres, MySQL, or MongoDB into the warehouse without dragging the source

• ELT as the default pattern: land raw, transform in the warehouse, version every step

Transformation and modeling: The work that turns raw landings into trusted tables.

• dbt as the default for SQL-based transformations, with models, sources, snapshots, and tests in version control

• Kimball dimensional modeling, data vault, or One Big Table chosen for the actual access patterns

• Slowly-changing dimensions, late-arriving facts, and the rest of the modeling vocabulary used deliberately

• Semantic layer definitions (dbt Semantic Layer, Cube, LookML) so analysts and LLMs ask the same question the same way

Orchestration and scheduling: What runs which job, when, and what happens when it fails.

• Airflow for the dominant install base, with DAGs that are testable and idempotent

• Dagster for asset-centric pipelines where lineage and partitions are first-class

• Prefect for teams that prefer Python-first workflow definitions

• Argo Workflows for Kubernetes-native teams that want orchestration co-located with compute

Warehouse and lakehouse platforms: Where the data actually lives.

• Snowflake, BigQuery, Databricks, or Redshift chosen for cost shape, query patterns, and team familiarity

• Lakehouse architectures on Delta Lake, Apache Iceberg, or Apache Hudi when storage cost and open formats matter

• EMR, Glue, and Dataflow for batch jobs that need to live outside the warehouse

• Storage and compute separation: an opinion on when to materialize, when to query in place, and when to copy

Streaming and real-time data: The path that does not wait for the nightly run.

• Kafka, Kinesis, or Pub/Sub as the transport, with schema registry discipline

• Flink, Spark Streaming, or Kafka Streams for stateful processing

• Materialize, RisingWave, or ksqlDB for streaming SQL on hot paths

• An opinion on when streaming earns its operational cost and when micro-batch is the honest answer

The case for a data engineer is almost always a leverage argument. When analysts cannot trust the numbers, when the dashboard breaks every Monday, or when the ML team is rebuilding the same ingestion logic for the third time, hiring a data engineer who owns the pipeline full-time pays back fast. The case against shows up on small teams where simple analytics and a backend engineer with dbt are still enough.

Trust in the numbers is the product: When the business runs on the warehouse.

• Finance, ops, and exec dashboards where a wrong number costs a meeting at minimum

• Investor-reported metrics that have to reconcile to the operational system every quarter

• Pricing, billing, and revenue recognition where the math has to be auditable

• Data contracts and tests that catch a schema change in CI, not in a Monday standup

Volume and velocity demand specialization: Anywhere the pipeline cannot be a cron job and a Python script anymore.

• Event volumes that overwhelm a generalist's mental model of throughput and cost

• Multi-source ingestion with non-trivial joins, deduplication, and identity resolution

• Real-time or near-real-time use cases where freshness is a product KPI

• Warehouse cost curves that need a specialist to read and tune

Downstream teams stop reinventing the wheel: When analytics, ML, and product all need the same data.

• A single source of truth for customer, account, and event entities that every team can query

• Reverse ETL from the warehouse back into operational systems (Hightouch, Census) without bespoke scripts

• Feature stores and ML platform integration that share definitions with the analytics layer

• RAG and AI application data pipelines that reuse the warehouse instead of building a parallel one

AI Fluency multiplier: Agentic AI workflows have changed how data engineers ship pipelines, and the gains compound on transformation work.

• An AI Enabled engineer running Cursor or Claude Code with human-in-the-loop review can scaffold a dbt model, its tests, its documentation, and its downstream exposures in a single session

• An AI Native engineer orchestrates parallel agents to investigate a data quality incident, propose the fix, and land the contract update in the same pull request

• Semantic layer plus LLM access turns business questions into governed queries instead of one-off Slack threads

• Terminal classifies every engineer in AI Assisted, AI Enabled, or AI Native tiers and surfaces those signals at hire time

When not to hire a data engineer: Generalists win on small data and simple stacks.

• Pre-product-market-fit startups where the data volume does not justify the role

• Teams whose entire analytics surface is a handful of dbt models a backend engineer maintains in an afternoon a week

• Companies on a single SaaS source where the vendor's reporting is already sufficient

• Hire a backend engineer with dbt fluency when the warehouse is small and the questions are simple

A senior data engineer's job description is broader than the job posting suggests, but the day-to-day is concrete. Here is what they actually own.

Pipeline delivery, end-to-end: The default unit of work.

• Design the ingestion, write the dbt models, configure the orchestrator, ship the tests, monitor the first runs

• Roll out behind a staging schema or environment before pointing dashboards at the new tables

• Own the change from kickoff to monitoring after deploy, including the downstream stakeholders

• Pair with the producing team on the data contract before writing the loader, not after

Data modeling and warehouse design: The schema is the engineer's most consequential decision.

• Pick the modeling style (Kimball, data vault, One Big Table, wide marts) that matches the actual query patterns

• Design slowly-changing dimensions, snapshots, and bridge tables when history matters

• Partition, cluster, and sort keys chosen against real workload data, not defaults

• Know when to denormalize for query speed and when to refuse the request to denormalize

Reliability, SLOs, and incident response: The senior bar is designing pipelines that assume failure.

• Define freshness, completeness, and accuracy SLOs per dataset, then instrument against them

• Handle late-arriving data, schema drift, and source-side breakage without silent corruption

• Run on-call for the pipelines they own, with runbooks that survive the engineer who wrote them

• Write the post-incident review in plain English and ship the fix in the same week

Data quality and contracts: Catch bad data before the dashboard does.

• dbt tests, Great Expectations, or Soda checks wired into CI and the orchestrator

• Anomaly detection with Monte Carlo, Anomalo, or in-house checks on row counts, freshness, and value distributions

• Producer-consumer data contracts that block a breaking schema change at the source, not after the fact

• Triage discipline for noisy checks: tune, mute, or delete the ones that no longer earn their alert

Performance and cost: Senior data engineers read the bill.

• Query optimization at depth: window functions, CTEs, predicate pushdown, partition pruning, materialization choices

• Warehouse cost monitoring with native tools (Snowflake Resource Monitors, BigQuery slot reservations) plus SELECT, Bluesky, or comparable

• Right-size the warehouse, batch the small queries, and refuse the request for a real-time dashboard that nobody watches

• Storage strategy: when to keep raw history, when to archive to object storage, when to drop

Production operations: Senior data engineers run their pipelines in production.

• Infrastructure-as-code for the data platform (Terraform for warehouse roles, dbt Cloud or self-hosted Airflow setup)

• CI for dbt with slim CI, state comparison, and PR-level model previews

• Observability for pipelines: structured logs, metrics, and lineage exposed in OpenLineage, dbt Cloud, or Dagster

• Take on-call rotations for the platform and the critical dashboards downstream of it

Cross-team collaboration: A lot of the work happens outside the editor.

• Partner with analytics engineers and analysts on the model layer and what a column actually means

• Partner with backend engineers on event schemas and change data capture contracts before they freeze

• Partner with ML and AI teams on feature pipelines, training data exports, and RAG data preparation

• Mentor junior data engineers and analytics engineers through code review and pairing on real incidents

The skill bar separating a senior data engineer from a generalist is depth in a few areas, not breadth across all of them. Terminal screens for both. Only the top 7% pass our screening, and the skills below are the ones that come up in technical interviews.

SQL fluency at depth: Strong SQL is the floor, not the ceiling.

• Window functions, common table expressions, lateral joins, and recursive queries written without a reference

• Query plan reading and optimization on the team's warehouse (Snowflake, BigQuery, Databricks, Redshift)

• Indexing, clustering, partitioning, and sort key strategy applied against real workload data

• Comfort writing the same logic in dbt models, raw SQL, and pandas or polars when the right tool changes

Python for data engineering: Real depth in Python where the warehouse cannot reach.

• pandas, polars, and pyarrow for in-process transforms and custom loaders

• Async Python and connection pooling for high-throughput ingestion

• Packaging, dependency management, and testing discipline for orchestrator-deployed code

• Comfort writing operators, sensors, or assets for Airflow, Dagster, or Prefect

Modern data stack fluency: Production experience across the layers, not bullet-point familiarity.

• dbt at depth: macros, packages, exposures, snapshots, tests, and the discipline to keep models DRY without overengineering

• Fivetran, Airbyte, or Stitch for managed ingestion plus a custom path when the connector does not exist

• Looker, Mode, Hex, Lightdash, or Metabase fluency at the BI layer, with an opinion on semantic-layer ownership

• Reverse ETL via Hightouch or Census when the warehouse feeds operational systems

Warehouse and lakehouse platforms: Senior data engineers go deep on at least one platform.

• Snowflake including warehouses, resource monitors, dynamic tables, Snowpark, and cost tuning

• BigQuery including slot reservations, partitioned tables, BigLake, and Dataform integration

• Databricks including Delta Lake, Unity Catalog, Photon, and Databricks Workflows

• Lakehouse formats (Apache Iceberg, Apache Hudi, Delta) and an opinion on when open formats earn their operational cost

Orchestration and streaming: Familiarity with the trade-offs across batch and real-time.

• Airflow at depth, including TaskFlow, deferrable operators, and an opinion on KubernetesExecutor versus CeleryExecutor

• Dagster or Prefect for asset-aware or Python-native orchestration

• Kafka, Kinesis, or Pub/Sub on the transport side, with schema registry and Avro or Protobuf discipline

• Flink, Spark Streaming, or Kafka Streams when stateful processing is the right answer

Data quality and observability: Knowing what to test is as important as knowing how.

• dbt tests, Great Expectations, or Soda wired into CI and the orchestrator

• Data observability tooling: Monte Carlo, Anomalo, Bigeye, or in-house anomaly detection

• Contract testing between producers and consumers, with schema registry or dbt contracts enforcing it

• An opinion on coverage as a metric versus coverage as a goal

Cloud and DevOps fluency: Senior data engineers ship to a real platform.

• AWS, GCP, or Azure familiarity including IAM, managed warehouses, object storage, and serverless compute (Lambda, Cloud Functions, Glue)

• Terraform or Pulumi for the data platform, not just clickops in the warehouse console

• Docker for local development and reproducible pipeline environments

• CI/CD pipelines configured deliberately, with slim CI for dbt and integration tests for orchestrator code

AI Fluency: The capability shift that is reshaping engineering output.

• Daily use of Claude Code, Cursor, GitHub Copilot, or comparable AI coding assistants

• Comfort orchestrating agents for dbt model generation, data quality investigation, and pipeline refactors, with human-in-the-loop review

• Working knowledge of RAG data pipelines, vector stores, and semantic layers exposed to LLMs

• AI Enabled or AI Native tier per Terminal's standard. The engineer either uses AI tools to compound their output significantly, or builds agentic workflows directly

Soft skills that matter: The non-technical bar is real.

• Clear written communication. Most data engineering work happens in pull requests, design docs, and async threads with non-engineers

• Pragmatism on scope. Knowing when to ship the OBT and when to invest in the dimensional model

• Mentorship instinct. Senior engineers raise the floor of the whole team, including the analytics engineers and analysts they unblock

• Calm under production pressure. The bad backfill, the silent schema drift, the dashboard that lied for a week