Data Engineer Job Description Template (With Screening Tips)

"Data engineer" covers at least four distinct jobs: building ingestion pipelines, modelling a warehouse for analysts, running the platform those pipelines sit on, and supporting machine learning in production. Candidates specialise, employers rarely specify, and the result is interview loops where both sides discover a mismatch in round two.

The template below forces the specificity that fixes it.

The template

Data Engineer at [Company]

Location: [City / Remote — [region] / Hybrid] Compensation: [$X – $Y] base, plus [equity / bonus] Level: [Mid-level / Senior]

About the role

[Company] collects [what data, from where] and uses it for [what purpose — customer-facing features, internal analytics, ML models, regulatory reporting]. Today that's roughly [volume: rows per day, terabytes stored, number of sources].

We're hiring a data engineer to own [the specific mandate — build our ingestion layer, model the warehouse, make our pipelines reliable enough to trust].

What this role focuses on: [Pick one and say so. For example: "This is primarily pipeline and warehouse modelling work. We have a separate ML team; you'd support them but not build models."]

What you'll do

• Build and maintain pipelines moving data from [sources] into [warehouse or lake].
• Model data for the people who consume it — [analysts, product teams, ML engineers].
• Own data quality: validation, monitoring, and being the person who knows when a number is wrong.
• Improve reliability and cost of the platform.
• Manage schema evolution without breaking downstream consumers.
• Document what each dataset means and where it came from.

What we're looking for

• [n]+ years in data engineering or a closely related role.
• Strong SQL — genuinely strong, including window functions, query plans, and performance work.
• Solid [Python / Scala / Java] for pipeline code.
• Experience with [your orchestration tool] and [your warehouse].
• Dimensional or analytical data modelling experience.
• An instinct for data quality. You've been the person who found out why a dashboard was wrong.

Nice to have

• Streaming experience with [Kafka / Kinesis / Pub-Sub].
• [dbt / Spark / your transformation stack].
• Infrastructure-as-code and cloud cost management.
• Experience in a regulated domain — [GDPR, HIPAA, financial reporting].

Our stack

[Sources, ingestion tooling, warehouse, transformation layer, orchestration, BI tool, cloud.] [One honest line about the current state — "the core pipelines are solid; the marketing data is a mess and cleaning it up is the first project."]

Who you'll work with

[Number of analysts, data scientists, product engineers, and who currently owns what.] [Say plainly whether this role is on-call for pipeline failures and what that looks like.]

Interview process

1. [30 min] Intro call.
2. [60 min] Technical conversation: a pipeline you built, a data quality incident, modelling decisions.
3. [90 min] Practical session: SQL and modelling against a realistic problem, or a paid take-home.
4. [45 min] Meet the analysts and engineers who'd depend on you.

Benefits and how to apply

[Benefits.] [Application link.] We reply to everyone.

[Company] is an equal opportunity employer.

Hiring data engineers: what's different

Say which of the four jobs it is

This is the single highest-value line in the post. Candidates who want to build streaming infrastructure and candidates who want to model a warehouse for analysts are different people with different skills, and both call themselves data engineers.

Name the primary focus, name what's adjacent, and name what's explicitly someone else's job. A pipeline specialist who discovers the role is 70% writing dashboard queries will leave, and reasonably so.

Give real volume numbers

"Big data" is meaningless. Rows per day, total storage, number of source systems, and query concurrency are all meaningful. Be honest in both directions — a candidate who joins expecting petabyte-scale streaming and finds a nightly batch job over a few million rows will be disappointed, and one who expects a modest warehouse and inherits a real-time system will struggle.

Note that modest volume is not a weak pitch. Plenty of excellent data engineers would rather solve gnarly modelling and quality problems than operate large clusters.

Describe who consumes the data

Data engineering is a service role, and the consumers define the job. Building for analysts running exploratory SQL, for a product feature with latency requirements, or for a model retraining nightly are three different sets of constraints. Say who you're serving and what they need.

Screen for data quality instincts above tooling

Tools change every couple of years; the underlying judgment doesn't. The questions that separate candidates:

• "Tell me about a time bad data reached a dashboard or a customer. How did you find out?" You want to hear monitoring and validation, not "someone complained."
• "How do you handle a schema change in an upstream source you don't control?" The everyday reality of the job.
• "How would you model [a real entity from your business] for analysts?" Uses your actual domain and reveals modelling judgment fast.
• "When would you use streaming rather than batch?" Tests whether they reach for complexity by default. "Most things should be batch" is often the senior answer.
• "How do you backfill without disrupting downstream consumers?" Practical, and everyone experienced has done it.
• "What does a pipeline failing at 3am look like for you?" Surfaces their operational expectations and yours.

Test SQL properly

SQL is the core skill and the one most under-tested. A realistic exercise — a messy schema, a genuine business question, and a follow-up asking them to make it faster — is worth more than any number of tool-familiarity questions.

What to delete

• A stack list of fifteen tools. Data tooling turns over fast; hire for fundamentals.
• "Data engineer" for a job that's really analytics or business intelligence. Title it accurately.
• "Data-driven company" with no detail. Everyone says it.
• Requiring ML experience for a role that never touches models.

The takeaway

Data engineering hiring fails on ambiguity more than on standards. Say which of the four jobs you're hiring for, publish real volumes, describe who consumes the data, and admit which parts of the pipeline are messy. Then interview for SQL depth, modelling judgment, and data-quality instincts — the skills that transfer no matter which tools you're running next year.

Hiring data engineers? Post your role on JobsList.dev and reach engineers directly.