Data Engineers Job Description Template (Copy-Paste Ready)

Data engineer job descriptions fail before a single candidate reads them when they list 20 tools, confuse data engineering with data analysis, and give no clarity on whether the role is batch or streaming, Snowflake or Databricks, greenfield or maintenance-heavy. The result is an unfocused applicant pool that takes weeks to screen down to viable candidates.

A well-written data engineer JD does three things: it specifies your exact stack so candidates self-select accurately, it communicates what ownership actually looks like in this role, and it signals the engineering culture in enough detail that qualified engineers want to apply. This guide breaks down what to include and gives you a copy-paste template ready for your next search.

What Makes a Strong Data Engineer JD

The best data engineering JDs share four characteristics. First, they name specific tools rather than generic categories. "Experience with data orchestration tools" is useless signal. "3+ years of production Apache Airflow experience including DAG design, task dependency management, and MWAA operations" is precise enough to be useful. Second, they distinguish between the transformation layer and the infrastructure layer. Are you hiring someone to own dbt models and data quality, or someone to build and maintain the Spark cluster and data lake architecture? These are different roles. Third, they specify the cloud platform and version where relevant. Snowflake and BigQuery have meaningfully different SQL dialects, cost models, and optimization levers. Fourth, they communicate whether this role is greenfield or legacy-heavy. Engineers optimize for different things depending on whether they are building from scratch or maintaining existing production systems.

Length and Format

Effective data engineer JDs run 400 to 600 words. Long enough to be specific, short enough to be read. Structure them with three sections: About the Role (2-3 sentences on the team and context), Responsibilities (8-12 bullet points), and Requirements (split into must-have and nice-to-have). Avoid "About Us" sections longer than 3 sentences. Engineers read those last and they rarely influence apply decisions.

Full JD Template (Copy-Paste)

Customize the bracketed sections for your stack and context. Remove requirements that do not apply and add any platform-specific tools your team uses.

Responsibilities Breakdown

Not every responsibility applies to every data engineering role. Use this breakdown to select what is actually in scope for your hire rather than listing everything and inflating the JD.

Pipeline Development and Ownership

This is the core of most data engineering roles: designing, building, and maintaining the pipelines that move and transform data. Be specific about whether your pipelines are batch (daily or hourly Airflow DAGs), micro-batch (10-minute intervals), or streaming (sub-second Kafka consumers). The operational model is completely different across these three paradigms and candidates who have only done batch work will struggle immediately in a streaming environment.

Transformation Layer (dbt)

If dbt is central to your stack, dedicate at least two responsibility bullets to it. Most data teams want their data engineer to both write and maintain dbt models and to enforce modeling standards (grain definitions, naming conventions, test coverage) across the project. If your dbt project has technical debt, say so. "Refactor and document existing dbt models" is a realistic and honest responsibility that senior engineers will actually appreciate because it signals you have room for impactful work.

Data Quality and Observability

Data quality ownership is what separates senior data engineers from pipeline builders. If you want an engineer who will own the reliability of your data, not just the uptime of your pipelines, include explicit responsibility bullets for data quality: writing tests, defining freshness SLAs, building alerting for anomalies, and communicating data incidents to business stakeholders. Candidates who have owned this in production will recognize it immediately and self-select in.

Requirements: Must-Have vs. Nice-to-Have

Splitting requirements into must-have and nice-to-have is one of the highest-leverage things you can do in a data engineering JD. It immediately narrows the screening pool, reduces time spent on candidates who are close but not quite right, and communicates to senior candidates that you have thought carefully about what this role actually needs.

Must-Have: Production Experience, Not Just Familiarity

Every requirement in the must-have list should have "in production" implied. "Familiarity with dbt" is a nice-to-have. "Hands-on experience with dbt Core or dbt Cloud including model design, macros, and production deployment" is a must-have for a role where dbt ownership is central. The distinction matters because candidates with only tutorial or side-project experience with a tool will take significantly longer to be productive in a role where it is a daily responsibility.

Nice-to-Have: Adjacent Skills That Accelerate Ramp

Nice-to-have requirements should represent skills that make a candidate more immediately productive or valuable in your context without being blocking. Streaming experience is a legitimate nice-to-have for a predominantly batch-focused team that has plans to add streaming later. MLOps familiarity is a nice-to-have for a team that collaborates closely with data scientists but does not own the ML infrastructure. Keep the nice-to-have list short: more than five items signals you are not clear on what you actually need.

Adapting for Nearshore Candidates

A nearshore-adapted data engineer JD makes two additions. First, a clear statement on working hours: "This role works US business hours (Eastern or Central Time). Candidates in Latin America time zones are strongly preferred." This removes ambiguity for candidates and ensures the staffing partner filters for geographic fit. Second, an explicit English fluency requirement with the expected collaboration contexts: "Strong written and spoken English required for daily collaboration with US-based data analysts, analytics engineers, and business stakeholders." Data engineers in nearshore roles spend significant time in stakeholder-facing communication, not just heads-down pipeline work, and English fluency at the collaboration level needs to be stated explicitly.

Avoid adding requirements that are not actually relevant to nearshore data engineering work. Certifications, US degree requirements, and in-person availability requirements are common additions that reduce the qualified pool without improving hire quality for remote roles. If certifications are genuinely required for compliance or client-facing contexts, include them in the must-have section with an explanation.

Common JD Mistakes

Listing every data tool your company has ever used. A JD that requires Spark, dbt, Airflow, Kafka, Flink, Databricks, Snowflake, BigQuery, Redshift, and Python proficiency in one role is not describing a real position. It signals that you have not thought carefully about the role and will attract candidates who exaggerate their experience across all of them. Pick the tools that are actually central to day-one responsibilities.

Confusing data engineering with data science or analytics. Data engineering is about pipelines, orchestration, data quality, and modeling infrastructure. If your JD asks for machine learning experience, statistical analysis, or data visualization skills as requirements for a data engineering role, you are either hiring two roles at once or you are not clear on which role you need. This confusion leads to mismatched expectations and early attrition.

Omitting compensation range. Senior data engineers in Latin America know what market rates look like. A JD without a compensation range will generate applications from candidates across a wide salary spectrum, and mismatches discovered late in the process waste both parties' time. Include a range. It improves application quality and reduces time-to-offer.

Writing responsibilities as requirements. "Must have experience building dbt models" belongs in requirements. "Design and maintain our dbt models" belongs in responsibilities. Mixing them creates a confusing read and makes it harder for candidates to assess fit quickly.

Frequently Asked Questions