Prepare for your own interview

You have now watched five people go through the same pipeline interview. They had very different backgrounds: BI, backend services, a modern managed stack, 24 years of data work, and meter operations. But the strong moments had the same causes. The candidate knew their own pipeline in detail. They knew what happens when it runs twice, and when data arrives late. They said clearly what they did not know. And they talked about the people who use the data, not only about the tools.

None of this comes from reading. It comes from practice, like learning to drive. You can read the rules for weeks, but you learn to drive in the car, with someone next to you who says “turn left here”. This page is a plan for that practice. It takes about three weeks of short sessions.

Step 1: Choose one posting, and read it properly

Do not prepare for “Data Engineer interviews” in general. Prepare for one real posting, then adapt for the next one. Read it in the way that you saw on The job description and Read it honestly.

Data Engineer postings have one special problem: the long list of tools. Do not let it decide your preparation. Group the tools by what they do, and guess which one of each group the team really uses. Then ask the recruiter. Spend your time on the ideas under the tools, because the interviews ask about ideas: what is new data, what is late data, what happens on a second run, what one row means.

Also look for the things that the posting does not say. On-call and cost are missing from many postings. Write them down as questions for the recruiter.

Step 2: Write drill-down notes for your pipelines

Choose the one or two pipelines that you will talk about. For each one, write short answers to the questions that a serious interviewer will ask. Use real numbers wherever you have them. Approximate numbers are fine: “around 2 million rows a day” is better than “a lot of data”.

1. Sources, size and users: where does the data come from, how much arrives each day, and who uses the result?
2. Schedule and new data: when does it run, and how does it decide what is new?
3. A second run: if it fails halfway and you run it again, what happens to the rows that were already written? Did you ever test this?
4. Late and bad data: what happens to a row that arrives days late? To a row with a missing value, or a duplicate? To a file in a new format?
5. Correct: how do you know that the numbers are right? Which checks run, and what happens when one fails?
6. The worst incident: what broke, how you found out, who was affected, and what you changed.
7. Cost and size: what does it cost to run, roughly? What would change with ten or fifty times more data?

Questions 3 and 6 matter more than most people think. Interviewers trust a candidate who can describe a failure in detail, because only the person who was there remembers it that way. You saw this with Vikram in The veteran and with Fatima Zahra in The BI developer.

If you cannot answer question 3, do not worry. Many good engineers have never checked. Step 3 fixes it.

Step 3: Do the re-run test on a real pipeline

This is a small experiment, and it teaches more than a week of reading. Take a pipeline that you can run: one at work (in a test environment), or a small one that you build at home.

If you build one at home, find a public dataset with timestamps, for example bike-share trips, weather measurements or taxi rides. Choose data where the time of the event matters. Build a small job that loads one day into a table, partitioned by day. Then try these things:

• Run it twice for the same day. Count the rows before and after. If the count doubled, change the job so that it replaces the day, or merges on a key that makes each row unique. Run it twice again.
• Add a few late rows. Put some rows for yesterday into today’s file. Where do they go? Change the job so that they land in the right day.
• Add a duplicate and a broken row. Write a check that finds them, and decide what the job does: stop, skip, or put the row aside for a person to look at.

Write down what you changed and why, in a short README. Now you have a real story for question 3, and you understand Esther’s favourite question from the inside. You saw Jordan reason to the same answer in The modern stack, with some help. After this test, you will not need the help. Our lessons Reproducible extraction and Validation rules cover the SQL side.

Step 4: Practise the opening out loud

The deep dive starts with “Tell me about a pipeline that you built.” Your first two minutes decide where the conversation goes, because the interviewer asks about what you say. So say the things that you want to be asked about.

Prepare a two-minute walkthrough. Use the notes from step 2, but do not read them. A simple order works:

• The problem, and who used the data.
• What you built, at the level of the main boxes.
• One decision that you made, and why.
• One thing that went wrong, and what you changed.
• One limit that it still has.

Say it out loud, and record it on your phone. Listen once. Most people find that they name many tools and explain few decisions. Try again, with fewer tool names. Our lesson Explain decisions shows this step in detail.

Step 5: Practise the company’s problem

Most pipeline interviews include a problem from the company’s own work, and you can usually guess it from the posting. An energy company has meter readings. A retailer has orders and returns. A bank has transactions that must match to the cent. A delivery company has events from phones that lose network. Late data, duplicates and re-runs are in almost all of them.

Write the problem that you expect, in three or four sentences, like Esther’s. Then answer it out loud for 25 minutes, with a timer. Start with your questions. Then draw the main boxes on paper. Then go through the hard parts one by one:

• Event time and arrival time.
• What makes a re-run safe.
• How long you wait for late data, and what the users do while they wait.
• What you check every morning.
• What costs the most.
• Whether anything really needs streaming.

Do this two or three times, on different days. Each time, you will find a gap that you can read about before the next time.

Step 6: Practise SQL and modelling with your voice

The SQL round and the modelling round test skills that you may already have. What is different in an interview is that you must talk while you think, and nobody helps you to search.

For SQL, practise the queries that data engineers write every week. Do them without an AI assistant, in an editor without autocomplete if you can:

• Keep one copy of each duplicated row, for example with ROW_NUMBER().
• Find gaps: which meters, users or days are missing data.
• Compare each row with the previous one, for example a reading that went down when it should only go up.
• Count by day, and check that the total matches the source.

After you write each query, say out loud what could break it: an empty day, two rows with the same time, a missing value. Our lesson Time and ranking covers the window functions.

For modelling, take a real situation and design the tables on paper. Then explain them to a friend in five minutes. Always start with the grain: “One row in this table means one reading from one meter at one time.” Then practise history. Pick something that changes over time, like a customer’s address or the meter on an account, and design a table that can answer “what was true on 3 March?” This is often called a slowly changing dimension, type 2: you keep the old row, close it with an end date, and add a new row. You saw why this matters in The BI developer and The software engineer.

Step 7: Get interviewed by a person

Practice alone is useful, but it cannot surprise you. Ask a friend or former colleague, ideally a data engineer, to interview you for 45 minutes. Give them your CV, the seven questions from step 2, and the problem from step 5. Ask them to go deeper on whatever you say, and to ask “what happens if it runs twice?” at least once. Afterwards, ask for one strength and two things to improve.

Then change places, and interview them. As the interviewer, you will hear quickly how a general answer sounds, and how much a specific one helps.

You can also practise with an AI assistant. Ask it to play a strict interviewer who follows up on every answer and never accepts a general one. This is good practice. It is very different from using AI during a real interview, which we ask you never to do (our advice).

Step 8: Prepare for the edge

You will reach the edge of your knowledge in every good interview. For data engineers, it is often in one of these places: streaming internals (offsets, exactly-once), Spark performance at large volume, lakehouse details such as compaction, or history modelling. Your edge depends on where you come from.

Write down three topics where you expect to reach your edge. For each one, write what you do know, and how you would find out the rest. Then practise saying it: “I haven’t used that directly. What I know is… If I had to decide today, I would start by…” It feels uncomfortable the first few times, and then it becomes normal. Nicole’s interview in The domain expert shows how much you can still give at the edge, when you are honest about it.

Also prepare for the other kind of edge: when the interviewer says something that you think is wrong. In The veteran, Vikram disagrees with Esther about what Kafka’s exactly-once setting really covers. He does it politely, with a reason, and she agrees after she thinks about it. Know your main topics well enough to do the same, and to accept a good counter-argument. See our advice on disagreeing.

Step 9: Prepare your questions

Write two or three questions for each interview stage. Take them from your preparation table and from the questions on Read it honestly. For a data engineering role, these questions are especially useful:

• “What was the worst data incident this year, and what changed after it?”
• “Is there an on-call rotation? How often, and when do the most important jobs run?”
• “Who owns the cost of the platform?”
• “When a source system changes its format, how does the team find out?”

Questions like these show that you think like someone who will do the job. They also give you the information that you need to decide. Remember that the decision goes both ways. A strong candidate may get another offer while a company is still deciding (our advice).

On the day

• Ask at the start what is allowed: notes, documentation, a whiteboard, an AI assistant in a coding round. Then follow the rules exactly.
• For a video interview, test your camera, microphone and screen sharing the day before. Close everything that you do not need.
• Keep paper and a pen near you. Pipelines are easier to explain with boxes and arrows, even rough ones.
• It is normal to say “Let me think for a moment” and then think in silence for 20 or 30 seconds. It is also normal to say “Sorry, can you repeat the question?”
• Treat the interviewer as a future colleague. You are also finding out if you want to be on call with this team.

After the interview

Write down every question that was hard, the same day, while you still remember it. Then practise those questions. If you were not chosen, ask politely for feedback. Not every company gives it. When a company does, one honest list of topics from an interviewer can be worth weeks of reading. Jordan’s story in The modern stack shows what to do with it.

Some of the result is outside your control (our advice). The team had one vacancy, and another candidate had exactly the right experience. Or the team saw that you fit a different role better. A “no” for one role is sometimes the start of a conversation about another one. Keep going, and keep the plan focused on the roles that you want.

A three-week plan

The plan below summarises the steps. It assumes about one hour on most days, next to a job or other studies.

Week	Main work	Out loud
1	Read the posting and make the preparation table. Write drill-down notes for your main pipeline. Start the re-run test from step 3.	Record the two-minute walkthrough twice.
2	Finish the re-run test and write its README. Practise the SQL queries and one modelling design from step 6. Prepare your three edge topics.	Answer the company’s problem twice, with a timer. Explain your model to a friend.
3	Read your notes again. Fix what the practice showed you. Write your questions for each stage.	One mock interview with a person, then one more after you fix what they said.

Then apply, and keep the notes. The next posting will need only a few changes.