Junior Data Engineer Interview
Questions, Rounds & Prep (2026)
A junior data engineer interview is a technical screen followed by 3 or 4 interviews. They test SQL under a clock and plain Python for reshaping records, along with basic data modeling and behavioral answers about learning and ownership. The loop rarely asks for system design. Junior candidates win or lose it on pacing and edge cases, and on having 1 well-built project.
What a junior data engineer interview tests
A junior data engineer interview tests fundamentals at speed: SQL you can write correctly under a clock, plain Python that reshapes records, enough data modeling to name a table's grain and keys, and behavioral answers that show you learn fast and own your work. It rarely asks for a platform design, and when it does, the question is a small batch job, not an architecture.
The bar is fluency, not breadth. An interviewer at this level has little work history to weigh, so the loop leans on what you can show in the room: a query that handles the tie and the NULL without being prompted, a function that survives a missing key, and a project you can explain down to why each table exists.
The questions on this page are ones asked in real data engineering interviews, answered the way a strong junior candidate would answer them: correct first, then the edge case, then the trade-off in 1 sentence.
Know Junior data engineer interview the way the interviewer who asks it knows it.
How the junior data engineer loop is structured
Most loops run in 2 stages: a technical screen, then a set of interviews on 1 day. Amazon publishes the format for data roles hired from university: 1 first-round interview, then 3 to 4 interviews, each 45 to 60 minutes. Its data engineers are expected to know ETL and data modeling and to be proficient in SQL plus at least 1 scripting or programming language. Each interviewer typically asks 2 or 3 behavioral questions as well.
The screen is almost always SQL, sometimes with a short Python problem, on a shared editor with sample rows. The later interviews split into a SQL round, a Python round, a data modeling conversation and a behavioral round; smaller companies fold these into 2 or 3 sessions or replace 1 with a take-home assignment of a few hours.
Read the job description before anything else. Its basic qualifications name what the loop will test, and its preferred qualifications name what earns extra credit. Amazon states that missing some preferred qualifications does not rule a candidate out. The data engineer interview prep guide walks through each round of the full loop in depth.
How to pace a 45 minute SQL round
The SQL round is where junior candidates most often run out of time, and the arithmetic is unforgiving. Take a 45 minute round with 3 questions. About 5 minutes go to introductions and reading the schema, and the last 4 to your questions for the interviewer, which leaves 12 minutes per question.
Spend 25 minutes on the first question and the round is over before you know it: the overrun of 13 minutes comes straight out of the last question, which gets 3 minutes, and the closing questions disappear. Interviewers often hold the harder follow-ups for the third question, so a slow start costs the part of the round where a strong candidate separates from the rest.
Pace yourself against the clock. Say the plan in 1 sentence, write the query that works, run it on the sample rows, then state the edge cases you would handle next. At 12 minutes a question, a correct query with 1 named gap beats an elegant one that is still unfinished.
The SQL questions junior candidates are asked
A junior SQL round usually gives a prompt and a few sample rows per table, then asks for 3 to 5 queries that build on each other. The patterns repeat. You join 2 or 3 tables and aggregate, then filter groups with HAVING. A window function finds the latest or top N row per key, and LAG compares each row with the previous one. The last regular is counting distinct users by day or week.
Interviewers probe the edge cases hardest. A LEFT JOIN whose right table is filtered in the WHERE clause behaves like an inner join, and nothing warns you. COUNT(column) skips NULLs where COUNT(*) does not. A join on a key that repeats on both sides multiplies rows and inflates every sum. Name these before the interviewer does, and a correct query reads as a careful one.
Deduplication deserves its own practice, because nearly every data engineering loop asks for it in some form. Usually that means keeping the latest record per customer or dropping repeated events. The load version asks you to write a table without creating duplicates. The SQL interview questions for data engineers cover each of these patterns with worked answers.
Keep the latest row per customer in SQL
SELECT customer_id, email, updated_at
FROM (
SELECT
customer_id,
email,
updated_at,
ROW_NUMBER() OVER (
PARTITION BY customer_id
ORDER BY updated_at DESC, update_id DESC
) AS rn
FROM customer_updates
) latest
WHERE rn = 1
ORDER BY customer_id;6 updates for 3 customers. Customer 101 has 2 updates at the same latest time, so the tiebreaker on update_id decides which survives. Swap ROW_NUMBER for RANK and drop the tiebreaker to see customer 101 come back twice.
ROW_NUMBER vs RANK when timestamps tie
The most common follow-up to a dedupe question is what happens on a tie. The PostgreSQL documentation on window functions defines the difference precisely: row_number numbers each row in its partition from 1, while rank gives the same rank to all rows that are equal on the ORDER BY columns, which the docs call a peer group, and leaves a gap after them. dense_rank does the same without the gap.
So when customer 101 has 2 updates stamped 09:30, filtering on rank = 1 keeps 2 rows and the table still holds a duplicate, while row_number = 1 keeps 1.
ROW_NUMBER alone is not the whole answer either. Without a tiebreaker it picks 1 of the tied rows arbitrarily, and a rerun may pick the other, so the output changes between runs of the same query on the same data. Add a column that is unique per row, such as an update id or an ingestion time, as the last ORDER BY key, and say out loud why it's there.
The Python round: plain Python before pandas
Junior Python rounds test whether you can move and reshape records with the standard library. A typical problem parses a list of JSON events and counts or sums values per key. Others merge 2 lists of records on an id or flatten a nested field, and a CSV with malformed rows to drop shows up as well. The problems are short, and the interviewer watches how you handle the input nobody mentioned.
Reach for dict and set first, along with collections.Counter and collections.defaultdict. Importing pandas to sum a value per key in 10 lines of data hides the logic the interviewer came to see, and some interviewers stop you. Use pandas when the round says so, or in a take-home where it's the natural tool, and be ready to write the plain version either way.
The details that separate candidates are the same as in SQL. A record may be missing a key (record.get("amount", 0) instead of record["amount"]), or a value may arrive as a string. Test the empty input too, and make any membership check inside a loop use a set. State the complexity of your solution in 1 sentence when you finish; nobody expects a proof at this level.
Junior data engineer interview questions with answers
What is the difference between WHERE and HAVING?
WHERE filters rows before they are grouped, so it cannot reference an aggregate. HAVING filters the groups after aggregation, so it can: HAVING COUNT(*) > 1 keeps only groups with more than 1 row. Put every condition that doesn't need an aggregate in WHERE, because filtering rows early means less data to group.
How do you find duplicate rows in a table, and how do you remove them?
Group by the columns that should be unique and keep the groups with HAVING COUNT(*) > 1; that lists the duplicated keys and how often each repeats. To keep 1 row per key, number the rows with ROW_NUMBER() OVER (PARTITION BY the key ORDER BY the column that picks the winner, then a unique tiebreaker) and keep row number 1, either in a new table or by deleting the rest.
What is the difference between ROW_NUMBER, RANK and DENSE_RANK?
All 3 number rows within a partition by the ORDER BY. ROW_NUMBER gives every row a distinct number, even on ties. RANK gives tied rows the same number and skips the next ones, so 2 rows tied for first are followed by 3. DENSE_RANK gives tied rows the same number without the gap, so the next row is 2. Use ROW_NUMBER to deduplicate and DENSE_RANK for questions like the second highest salary.
Why did a LEFT JOIN return the same rows as an INNER JOIN?
Usually because a condition on the right table sits in the WHERE clause. Rows with no match carry NULL in the right table's columns, and a filter such as WHERE o.status = 'paid' removes them, which turns the query into an inner join. Move the condition into the ON clause to keep unmatched rows, or write the filter so it explicitly allows NULL.
What is the difference between COUNT(*), COUNT(column) and COUNT(DISTINCT column)?
COUNT(*) counts rows, NULLs included. COUNT(column) counts rows where that column is not NULL. COUNT(DISTINCT column) counts distinct non-NULL values. On a table of events, COUNT(*) is the number of events and COUNT(DISTINCT user_id) the number of users who produced them.
Given a list of JSON records, sum the amount per customer when some records have no amount.
Loop once and accumulate into a dictionary: totals = defaultdict(float), then for each record add float(record.get("amount", 0)) to totals[record["customer_id"]]. The .get with a default handles the missing key, float handles amounts that arrive as strings, and defaultdict removes the check for a customer seen for the first time. It runs in 1 pass, O(n) time and O(k) memory for k customers.
When would you use a set instead of a list?
When the question is membership or uniqueness. Checking x in a list scans it, O(n) per check, while a set is a hash table with O(1) average lookups, so filtering 1 million events against 10,000 blocked ids goes from around 10 billion comparisons to around 1 million lookups. A set loses order and duplicates, so keep a list when either matters.
How do you find the most common values in a list?
collections.Counter(values).most_common(n) returns the n most frequent values with their counts. Without the standard library, count into a dictionary with counts[v] = counts.get(v, 0) + 1, then sort the items by count in descending order. Say how you would break ties if the prompt does not.
What is the difference between a fact table and a dimension table?
A fact table records events or measurements, 1 row per event at a stated grain, with numeric measures such as quantity and amount and foreign keys to the dimensions. A dimension table describes the things those events involve. Customer and product are dimensions, and so is date; each has 1 row per member and descriptive columns used to filter and group. Facts grow fast and are summed; dimensions stay smaller and are joined for context.
What is the grain of a table, and why do you state it first?
The grain is what 1 row represents, such as 1 row per order line or 1 row per customer per day. Every other decision follows from it: which keys are unique, which measures can be summed and which dimensions can join without multiplying rows. State the grain before drawing columns, and most modeling follow-ups answer themselves.
What is the difference between ETL and ELT?
ETL transforms data before loading it into the warehouse, often in a separate processing engine. ELT loads the raw data first and transforms it inside the warehouse with SQL, which cloud warehouses made cheap. ELT keeps the raw copy, so a transformation bug can be fixed and rerun without extracting from the source again.
What does it mean for a pipeline to be idempotent?
Running it twice for the same input produces the same result as running it once. A daily job that appends rows is not idempotent, because a retry loads the day twice. Make it idempotent by overwriting the day's partition, or by merging on a key so a second run updates rows instead of inserting them again.
Tell me about a time you received critical feedback.
Use STAR: the situation, your task, the action you took and the result. Pick a real piece of feedback on your own work, such as a code review that found a bug in your query, and spend most of the answer on what you changed and how you checked it stuck. End with what you do differently now. Keep it at the scope you actually had; interviewers probe the details.
Data modeling questions at the junior level
Junior modeling questions check vocabulary and first principles rather than design taste. Expect to explain a fact table and a dimension table and to say what primary and foreign keys enforce. If you draw a small star schema for an online shop, name the grain of each table in it.
A typical prompt: model the orders of an online shop so analysts can report revenue by product and day. A strong junior answer states the grain first: 1 row per order line. Quantity and amount go on that fact table. It joins to a product dimension and a customer dimension, with a date dimension for reporting by day. The follow-up is often what happens when a product's price or category changes; knowing that a slowly changing dimension keeps history with a new row per version is enough at this level.
What interviewers do not expect is a debate between modeling methodologies. Star schemas spend extra storage to make queries simpler and faster, and normalized schemas make the opposite trade. Be ready to say which you would choose for reporting and why.
Session Pulse
> In `user_sessions` each row is one session, but some sessions have no duration on file and are left out of every figure. From the rest, summarize each user's engagement as their average session length, how many sessions they logged and their longest one, keeping users with at least three sessions, longest average first.
What junior loops leave out compared with senior loops
Senior loops spend whole rounds on architecture and on influencing other teams. Junior loops cut both. When a junior loop includes design at all, the prompt is small: a daily job that aggregates yesterday's events, or a backfill of 1 month of data. The interviewer wants to hear where the data comes from, where it lands, how the job reruns safely and how you would know it failed.
If an interviewer asks a question beyond your experience, admit the gap and reason from there: "I haven't run a system at that scale, but I would start by partitioning by date so each day can be reloaded on its own." That answer shows judgement and the coachability junior loops look for. Overconfidence reads worse at this level than a gap in knowledge, because the team is hiring someone to grow.
The questions junior loops add in place of design are about learning: how you picked up a new tool, what you did when you were stuck, and what a code review taught you. They reward specific, modest stories.
The behavioral round at team-member scope
Behavioral questions count for a lot in junior loops, and at companies like Amazon they appear in every interview, not just 1. Answer with the STAR method, which Amazon's own interview guidance recommends: the situation, your task, the action you took and the result, with most of the time on the action.
Prepare 6 to 8 stories at the scope you actually had: a piece of work you owned from start to finish, a time you received useful feedback, a mistake you caught and fixed, a time you taught a peer something, a problem you noticed that others missed and a deadline you met by cutting scope. 1 story can answer several questions if you shift its emphasis.
Never inflate a story to senior scope. "I led a team of 5" falls apart at the first follow-up about how you handled a disagreement on that team. The interviewer is calibrated for a junior candidate, and a true story told in detail beats a large story told vaguely. The entry-level data engineer interview questions include the behavioral prompts asked most often at this level.
The portfolio project that stands in for experience
Without 1 or 2 years in the role, a finished project is the strongest evidence you can bring. Most loops give time to walk through one, and the interviewer probes it the way they would probe work experience: why this storage, what happens when a load fails, how you know the numbers are right. A project you can defend at that depth outweighs 3 you cannot.
4 shapes work well. An end-to-end batch pipeline on a real public dataset, such as the NYC taxi trip records, that cleans the raw files as it loads them into DuckDB or Postgres, then answers 5 real questions in SQL. A small streaming pipeline in which a Python producer writes to Kafka running locally in Docker and a consumer aggregates by minute and writes idempotently. A dbt project from staging to marts with tests and documented modeling decisions, which suits roles close to analytics engineering. Or a merged contribution to an open-source data tool, which shows you can read and work in someone else's code.
Whatever you build, put the reasoning in the README: a diagram of the flow, the grain of each table, the trade-offs you made and what you would change at 100 times the data. If you're coming from an analyst role, the move from data analyst to data engineer covers which of your existing skills transfer and which gaps to close first.
A 12 week prep plan for a junior data engineer loop
- 01
Weeks 1 to 4: SQL until it is fast
Solve around 100 SQL problems. Joins and GROUP BY with HAVING come first; add window functions next, then date arithmetic and conditional aggregation. From week 3, time every problem so medium ones take under 15 minutes.
- 02
Weeks 5 to 7: plain Python for data
Solve roughly 50 Python problems using the standard library first: parsing JSON and counting or grouping with dictionaries, then merging records and cleaning CSV rows.
- 03
Weeks 8 to 10: modeling and the project
Draw star schemas for 3 familiar businesses with the grain stated first, and finish 1 portfolio project to the point where its README answers why each table exists.
- 04
Weeks 11 and 12: stories and mock interviews
Write 6 to 8 STAR stories at your real scope. Then run around 10 timed mock interviews, half of them SQL and the rest Python or behavioral, and speak your reasoning aloud.
Why junior candidates fail the loop
Slow SQL fails more junior loops than any gap in knowledge. A candidate who knows every window function but needs 25 minutes for the first of 3 questions leaves the round unfinished. The fix is volume under a clock: work through timed SQL practice problems until joins and aggregations need no thought, and save the thinking for the edge cases.
The next most common failures are habits. Silent coding leaves the interviewer guessing whether you're stuck; say the plan, then write. Skipping the sample rows means a tie or a NULL goes unnoticed until the interviewer points at it, and so does a repeated key. Reaching for pandas in a plain Python round hides the logic under test.
The last group shows up in conversation: no project to discuss, stories inflated past what you did, and certainty about questions you have not faced. Each one gives the interviewer a reason to doubt the rest of the loop, and each is fixed before the interview rather than during it.
Junior data engineer salary
Across the 123 companies DataDriven holds junior data engineer salary reports for, the junior band runs from $110K at the 25th percentile to $150K at the 75th in total compensation, with a midpoint of $127K. The next level up has a midpoint of $158K, which is why the first promotion is worth more than any negotiation at the offer.
Each band is the median of company medians over companies with at least 4 junior reports, so it describes a typical employer in the data rather than the whole market, and some totals are estimates. Where an employer sits against the band depends on how much of its offer is equity, so compare offers on total compensation, not base salary.
At the junior level the offer is harder to move than the level itself. Being hired 1 level higher changes the band, and that is decided by the loop, which is 1 more reason to put the preparation into the rounds.
Junior data engineer interview FAQ
Can I get a junior data engineer role with no experience?+
How long should I prepare for a junior data engineer interview?+
Do I need to know Spark for a junior data engineer interview?+
Is a bootcamp worth it for a junior data engineer role?+
How is a junior data engineer interview different from a data analyst interview?+
What level is a junior data engineer?+
The candidate who gets the offer
- 01
Reading a solution is not the same as writing one
Every engineer who has frozen on a query they had read a dozen times knows the gap. The only preparation that closes it is producing the answer yourself, under time, before the interview does it for you
- 02
76% of hiring managers reject on the coding task, not the resume
From HackerRank's 2024 Developer Skills Report. Candidates who look strong on paper still fail the live screen if they haven't done timed, executable practice
- 03
5 problem shapes cover 80% of data engineer loops
Dedup, sessionization, top-N-per-group, slowly-changing dimensions, partition tricks. Writing the shapes by hand turns the unfamiliar into pattern recognition
Related guides
SQL interview questions for data engineers
The SQL questions data engineering loops ask, with worked answers
SQL practice problems
Timed SQL problems that run in the browser
Entry-level data engineer interview questions
Questions sized for candidates with no production data engineering history
Data engineer resume guide
How to write the resume that gets a junior candidate into the loop
Data engineer interview prep
Every round of the data engineering loop and how to prepare for it
DataLemur vs DataDriven
Which SQL practice site covers the rounds of a data engineering loop
LeetCode vs DataDriven
Whether LeetCode is enough for a data engineering interview
The data engineering challenge
Dirty, production-shaped data, scored blind each week.