On this page
Questions to practise
Tell me about a data pipeline you built.
They want to see real experience and how you explain technical work in plain words.
Choose one pipeline. Say where the data came from, what you did to it, and where it went. For example: a daily pipeline from a shop system to a warehouse. Keep it short and clear.
Which parts of that pipeline did you build yourself?
They want to know your own role, not only the team's work.
Use "I", not only "we". Name the steps you built, such as the loading step or the cleaning step. Be honest. If others built some parts, say so simply.
What tools did you use, and why did you choose them?
They want to see that you understand your tools, not just list names.
Name one or two tools and say why they fit the job. For example, they were fast enough for daily data, or the team already used them. Link each tool to a real step.
Tell me about a data quality problem you found.
Bad data is common. They want to know how you notice and handle it.
Say how you found the problem, what you fixed, and how you stopped it happening again. For example: some rows had empty dates, so you added a check that stops the load.
How did you know the data was wrong?
They want to see that you check data carefully and do not guess.
Describe the signal. Maybe a report looked strange, counts did not match, or a test failed. Explain the check you used, such as comparing row counts or looking for empty values.
What checks would you add to a new pipeline?
They want to see if you think about prevention, even without a real example.
Name two or three clear checks. For example: no empty key fields, row counts match the source, dates are in a valid range. Say what happens when a check fails.
How do you work with analysts?
Data engineers build data for other people. They want to see good teamwork.
Name one habit. For example, a weekly meeting, a shared document, or a message when data changes. Say how you learn what analysts need before you build.
How do you find out what data users really need?
They want to know if you ask questions before you start building.
Explain that you ask what questions they need to answer. Give an example. Say how you check you understood, such as showing a small sample of the data first.
How do you tell people when data changes or a pipeline fails?
Clear communication keeps reports correct and builds trust.
Describe a simple habit. For example, you send a short message to the analysts, explain what changed, and say when it will be fixed. Mention a shared channel or document if you use one.
Who used the data from your pipeline, and how did it help them?
They want to see that you understand why your work matters.
Name the users, such as the sales analysts. Say what they did with the data, for example a daily sales report. Keep it simple and real.
Let me explain it step by step.
Clara
AI coach
Leo
AI coach
Lines to try
Let me explain it step by step.
First I loaded the data, then I cleaned it.
The data came from our shop system and went to the warehouse.
I noticed the row counts did not match, so I checked the source.
I added a check that stops the load if a key field is empty.
I asked the analysts what they needed first.
Common questions
What if I have never had a big data quality problem?
That is okay. You can explain a clear check you would use. For example, you would check for empty values or compare row counts with the source. Say what you would do if the check failed. A clear plan is a good answer.
Should I talk about many tools?
It is better to talk about one or two tools in detail. Explain what you did with them and why. A long list of tool names without examples can sound general. The interviewer usually wants to hear your own steps.
My English is not perfect. How can I explain technical work?
Use short sentences and simple words. Explain in order: where the data came from, what you did, and where it went. Words like "first", "then" and "after that" help. It is fine to pause and think before you answer.