What Makes a Good Data Engineer vs. a Great One

If you are hiring your first data engineer — or evaluating whether your current one is performing — the difference between good and great is not what most people think.

A good data engineer can build a pipeline. A great one builds a pipeline that the business actually trusts and uses six months later. The gap between those two outcomes is enormous.

The Three Dimensions

1. Technical Depth

This is the dimension everyone screens for. Can they write SQL? Do they know Python? Have they used Airflow, dbt, Snowflake?

A good data engineer checks these boxes. They can ingest data, transform it, and load it into a warehouse. They understand schemas, indexing, and query performance.

A great data engineer also thinks about maintainability. They write code that someone else can debug at 2 AM. They build pipelines that fail gracefully and alert clearly. They document not just what they built, but why.

2. Business Sense

This is where the gap starts to widen. A good data engineer builds what you ask for. A great one asks "why do you need this?" before writing a single line of code.

Great data engineers understand the business model. They know that when the VP of Sales asks for a "pipeline dashboard," what they actually need is a way to forecast whether the team will hit quota. They translate business questions into data architecture — not the other way around.

Practical signs of business sense: - They ask about how the data will be used before building - They push back on vanity metrics - They can explain trade-offs in business terms ("this approach costs 3x more but updates hourly instead of daily — do you need hourly?") - They proactively flag data quality issues that affect business decisions

3. Communication

This is the most underweighted dimension and arguably the most important for companies under $50M where the data engineer is often the only data person in the room.

A great data engineer can sit in a leadership meeting, hear the discussion about churn, and translate that into a concrete data project with clear deliverables. They can explain to a non-technical CFO why the numbers in two reports don't match without making anyone feel stupid.

They write status updates that say "the revenue dashboard now reflects contract start dates instead of signature dates — expect Q1 numbers to shift by about 4%" instead of "updated the date logic in the dim_contracts model."

Why This Matters for Hiring

Most job postings for data engineers list 15 technical requirements and zero business or communication requirements. The result: companies hire technically competent people who build technically sound systems that nobody uses.

When you are writing the job description, weight it like this: - 40% technical — Can they build reliable pipelines? - 30% business sense — Do they understand what matters and why? - 30% communication — Can they make data accessible to non-technical stakeholders?

The Interview Test

Give candidates a real scenario from your business. Not a LeetCode problem. Something like: "Our CEO wants to understand why revenue grew 15% but profit only grew 3%. What data would you need, where would you look, and how would you present your findings?"

The good candidate will talk about tables and joins. The great candidate will talk about cost categories, margin analysis, and how they would walk the CEO through the answer.

Hire for all three dimensions. Your data will actually get used.