Data engineer screening questions for recruiters

Data engineers are judged on pipelines other people depend on, so a first screen should confirm they have built some, know SQL well, and have a plan for when data arrives late, broken or twice. Give it about 20 minutes. Tool lists in this field are long, so ask about one real pipeline and follow it end to end.

What does a data engineer do?

A data engineer builds and runs the systems that move data from where it's created (apps, databases, outside services, files) to where it's used, such as a data warehouse that analysts and data scientists query. That means writing pipelines, cleaning and reshaping data, scheduling jobs and making sure the numbers are right and on time. The Bureau of Labor Statistics has no separate data engineering occupation. Its closest is database administrators and architects, who "create or organize systems to store and secure data."

Which skills should you check at each level?

What screening questions should you ask a data engineer?

These are our own examples, written for this page. Swap in the client's tools.

Describe a pipeline you built: where the data came from, what you did to it, and who used it.

One concrete pipeline tells you more than a list of tools.

Strong answer: names the source (for example a Postgres database or a Salesforce export), the tools, how often it ran, the main transformations, where the data landed and which team relied on it.

Weak answer: "I built ETL pipelines using Spark, Airflow and Snowflake."

A nightly job failed, and this morning's dashboards are wrong. What do you do?

A failed overnight job is routine in this work, and the answer shows how they handle it.

Strong answer: finds the failed step in the orchestrator's logs, fixes the cause, reruns the job in a way that doesn't create duplicate rows, tells the people who use the dashboards, and adds a test or alert so it's caught earlier.

Weak answer: "I'd just rerun it."

How do you load only new or changed records instead of reloading everything?

Incremental loading is how pipelines stay fast and affordable as data grows.

Strong answer: uses a last-updated timestamp or change data capture, merges new rows into the target table on a key, and has a plan for records that arrive late or get deleted.

Weak answer: "We reload the whole table every night," for large tables, with no reason given.

How do you check data quality before analysts see it?

Bad data that reaches a dashboard costs trust quickly.

Strong answer: automated tests for missing values, duplicates, row counts and freshness (for example dbt tests or Great Expectations), alerts when a test fails, and a way to hold back bad data.

Weak answer: "The analysts tell us if something looks wrong."

How would you model sales data so analysts can report by product, region and month?

Data modeling shows whether they think about the people who use the data.

Strong answer: a central table of sales transactions with separate tables for products, regions and dates (often called a star schema), a clear statement of what one row means, and how they'd handle a product that changes category.

Weak answer: "One big table with everything in it," with no trade-offs. (Wide tables can be a reasonable choice; listen for a reason.)

When would you use Spark instead of SQL inside the warehouse?

This checks whether they pick tools for a reason.

Strong answer: Spark for very large or messy data, files that aren't tables, or heavy Python processing; SQL in the warehouse (often with dbt) when the data is already there and fits. They mention cost.

Weak answer: "Spark is always faster."

Have you worked with streaming data? What did you use, and why not batch?

Streaming often appears on resumes, and this checks what's behind it. An honest "mostly batch" is a good sign.

Strong answer: names a tool (Kafka, Kinesis, Event Hubs, Spark Structured Streaming or Flink) and a reason the data had to arrive within seconds, such as fraud checks, or says plainly that their work was batch.

Weak answer: "Everything we did was real time," with no example.

What red flags should you note?

• They can't describe a SQL join out loud in plain words.
• Hadoop, Spark, Kafka, Snowflake, Databricks and Airflow all listed at the same level, with one shallow project.
• Dashboard-building described as data engineering. That's analyst work; note the mismatch.
• No sense of data size: "big data" with no idea of rows, gigabytes or run times.
• For a mid-level or senior role, no pipeline they built that other people relied on.

Probe these in your own call, and keep how to spot a proxy interview handy if the candidate is remote.

How do you run this screen with Simplehire?

Put the client's stack in as the role's required skills, for example SQL, Python, Airflow, dbt and Snowflake, then send the interview link. The candidate's conversation with our AI interviewer happens in the browser, and the screening report follows when they finish.

A long tool list is normal on data engineering resumes, and the tiers differ in how hard they test it. Basic ($2 per screen, about 15 minutes) asks role-based questions about the skills you listed and handles junior or high-volume first screens. Adaptive ($3, about 20 minutes) adds follow-up questions that dig deeper into the candidate's answers, plus a per-answer AI assessment, and is the one we'd use before submitting. Advanced ($5, about 30 minutes) is for senior or client-critical roles: it goes deeper on strong answers, and its optional coding round is scored separately from the conversation.

The report opens with a verdict and shows Skills demonstrated X/Y, Strengths and Areas to probe. If Areas to probe names the orchestrator or warehouse the client cares about, that's where your own call should go. You decide who moves forward. Proctoring is on for every screen, and each month's first 25 Basic screens are free, no credit card required (pricing).

Related pages: data analyst questions, Python developer questions and AWS cloud engineer questions.