25 Data Cleaning Interview Questions (and What Interviewers Look For)

Data cleaning interview questions are rarely about syntax. Interviewers use them to see whether you look at data before you change it, whether you can name the rule behind every change, and whether you keep evidence of what you removed. The 25 questions below are grouped by topic, and each one comes with what a strong answer shows, and most with a red flag: the answer that tends to lose points.

Cleaning is not a side task in these roles. The US Department of Labor's O*NET profile for data scientists lists "Clean and manipulate raw data using statistical software" as a core task (O*NET OnLine, 15-2051.00), so expect at least one round to probe it. The SQL examples below were run on DuckDB 1.5.1 and the pandas examples on pandas 3.0.2.

Key Takeaways

• Strong answers show judgment more than function recall: profile first, ask about the row grain, and state a rule before you apply it.
• The strongest answers keep bad rows visible (flagged or quarantined) instead of deleting them silently.
• Missing, blank, zero and "unknown" are four different facts; treating them as one is an easy way to lose points.
• Every cleaning step should be reconcilable: rows in equals rows out plus rows set aside.
• Practice out loud on real messy tables, because explaining a choice is a separate skill from making it.

What interviewers are actually scoring

This guide groups what strong answers show into four habits. The table shows what each sounds like in an answer, and the opposite that costs points.

If you only remember one thing, remember the last column. An answer can contain correct SQL and still lose points if it makes a confident change without a stated reason.

Questions 1–5: Profiling a new dataset

1. You receive a new CSV. What do you do before cleaning anything?

A strong answer is a profiling routine: row count, column types as read, null and blank counts per column, distinct counts on likely keys, and min/max on numbers and dates. Mention reading everything as text first so the import itself does not change values, then compare against a data dictionary if one exists. Red flag: running dropna() or DISTINCT before counting anything. The guide to profiling a new dataset walks through the full checklist.

2. How do you find out what one row represents?

This is the row grain question. A strong answer tests a candidate key: if count(*) equals count(DISTINCT order_id) and no order_id is NULL (count(DISTINCT ...) ignores NULLs), one row is one order; if not, maybe it is one order line. Getting this wrong breaks every later step, especially deduplication. Red flag: assuming the grain from the file name or column names without testing it.

3. Which summary statistics do you check first, and why?

Look for answers that tie each statistic to a problem it reveals: min/max catch impossible dates and negative quantities, distinct counts catch inconsistent categories, and null rates catch broken extracts. A list of statistics without a reason scores lower than three statistics with reasons.

4. A column called status has 14 distinct values. What do you do?

Print the frequency table, including missing values, before mapping anything. A strong answer sounds like "I'd map known variants with an approved dictionary and send the rest to an unmapped list", not "I'd guess which ones mean the same thing."

5. What questions would you ask the data owner?

Good candidates ask about meaning, not just format: what a blank means, whether test accounts are included, which time zone timestamps use, and which record wins when two disagree. The guide on clarifying questions for messy data has a fuller list. Red flag: only asking about file format and delimiters.

Questions 6–10: Missing values

6. What is the difference between NULL, an empty string and zero?

NULL means the value is unknown or absent, an empty string is a known value with no characters, and zero is a measurement. Strong answers add that a blank in a CSV often means missing but must be converted deliberately, and that zero must never be used as a stand-in for unknown.

7. When would you fill missing values, and when would you leave them?

Fill labels when the business gives a rule (for example "unassigned" for a missing owner). Leave measurements missing unless there is a defensible method, because a filled number looks like a real observation. Adding an indicator column when you do impute shows you know a filled value is not an observed one.

8. A dataset uses -999 and "N/A" for missing. How do you handle it?

These are sentinel values. Convert them to real missing values early, document the list of codes, and count how many rows each code affected. Treating -999 as a number would drag that column's average down.

9. How would you fill gaps for a model without leaking information?

Learn the fill value (say, the median) from training rows only, then apply it to test rows. Computing it on the full dataset leaks test information into training. Expect this question in analytics and ML interviews; the red flag is computing the median on all rows "to be more accurate".

10. A survey question is blank for 30% of respondents. Is that a data problem?

Maybe not. The question might not have applied to them, or they skipped it. The answer interviewers want separates "not applicable", "unknown" and "declined", and reports response rates with the right denominator. Red flag: filling the blanks with the most common answer.

Questions 11–15: Duplicates and keys

11. How do you find duplicate rows in SQL?

Group by the key and keep groups with more than one row. Two rows with the same order_id usually mean a load duplicate; legitimate repeats (two identical purchases on the same day) show up instead when you group on customer, date and amount, and those must not be removed. Red flag: deleting every repeated combination of values without asking which kind it is.

Given this sample:

SELECT order_id, count(*) AS n
FROM orders
GROUP BY order_id
HAVING count(*) > 1;

It returns one row: order_id 1001, n 2.

12. Two records for the same customer disagree. Which one do you keep?

This is a survivor rule question. A good answer states a deterministic rule, such as "latest updated_at, then highest record id as a tie-breaker", and explains why the tie-breaker matters: without one, reruns can pick a different row. In DuckDB, QUALIFY keeps the first row per customer under that rule. Given these rows:

SELECT customer_id, email, record_id
FROM customers
QUALIFY row_number() OVER (
  PARTITION BY customer_id
  ORDER BY updated_at DESC, record_id DESC
) = 1
ORDER BY customer_id;

C2's two rows share a timestamp, so record_id decides. See the DuckDB QUALIFY documentation and the glossary entry on the survivor rule.

13. What is the risk of SELECT DISTINCT as a deduplication step?

It only removes rows that are identical in every selected column, so near-duplicates survive, and it collapses legitimate identical rows (two real purchases of the same item) that you should have kept. It also gives no record of what was removed.

14. Two customer records share a name but have different emails. Same person?

Not on name alone. A good answer asks for evidence-based matching (normalized email, phone, address) and a review queue for uncertain pairs, rather than an automatic merge that cannot be undone.

15. How would you deduplicate events that were delivered twice by a pipeline?

Use the event id with a rule for which delivery to keep (usually the first received), and confirm totals before and after. Mention that dedup must be idempotent: running it twice should change nothing. Red flag: deduplicating on timestamp instead of event id, which drops distinct events that happened in the same second.

Questions 16–19: Types, dates and text

16. Why should identifiers be stored as text?

Because numeric types drop leading zeros and can lose digits on long ids. A ZIP code like 02134 loses its zero the moment it is parsed as an integer. A 20-digit account number loses digits when it passes through a floating-point number, because floats keep only about 15 to 16 significant digits; that happens in spreadsheets and in pandas columns that contain blanks. Flags, by contrast, should become booleans from an approved list of spellings. Red flag: "ids are numbers, so I'd store them as integers."

17. A date column contains 03/04/2026. What date is it?

You cannot know without a declared locale: it is 4 March in the US convention and 3 April in much of Europe. Strong answers parse with an explicit format per source and count how many values failed to parse.

18. Timestamps come from three systems. How do you compare them?

Convert each to an instant (UTC) using its offset or known time zone, then compare. Comparing timestamp text, or local times without offsets, puts events in the wrong order around daylight-saving changes.

19. Names contain accents and stray spaces. How do you clean them?

Trim only real whitespace, normalize Unicode to one form (NFC) so composed and decomposed accents match, and do not strip accents or change capitalization unless the policy says so. Removing an accent changes the name.

Questions 20–22: Joins and reconciliation

20. After a left join your row count went up. Why?

The right table has more than one row per key, so the join fanned out. A strong answer checks key uniqueness before the join and can show it in code. In pandas, validate="many_to_one" turns the silent fan-out into an error:

orders.merge(customers, on="customer_id", how="left", validate="many_to_one")

It raises MergeError: Merge keys are not unique in right dataset; not a many-to-one merge.

The pandas merge documentation describes the validate and indicator options. Red flag: fixing the count with drop_duplicates() after the join instead of finding the repeated key.

21. What happens to rows with a NULL join key?

In SQL, NULL never equals NULL, so those rows do not match and an inner join drops them. pandas matches missing keys to each other, which its merge documentation calls out as different from SQL; which is a classic source of wrong joins. In pandas 3.0.2, an order with no customer id joins to a customer row with no id, even in an inner join:

orders = pd.DataFrame({"order_id": [1, 2], "customer_id": ["C1", None]})
customers = pd.DataFrame({"customer_id": ["C1", None], "name": ["Ana", "Unknown Ltd"]})
orders.merge(customers, on="customer_id", how="inner")

Either way, report orphan rows instead of losing them.

22. How do you prove your cleaning did not lose data?

Reconcile: rows in equals rows kept plus rows quarantined plus rows removed by a named rule, and key totals (such as revenue) match within each group. The reconciliation guide shows the pattern. Red flag: "I checked a few rows and they looked fine."

Questions 23–25: Judgment and communication

23. Would you delete outliers?

Usually no. Flag them with a reason and let the analysis decide. A $40,000 order may be a bulk purchase, not an error. Delete only values that are impossible by definition, such as a negative age, and even then keep them in an exceptions table.

24. Tell me about a time data was messier than expected.

This behavioral question tests structure. Describe the situation, what you checked, the rule you chose, and the measured result. The University of Washington's career center recommends the STAR structure (situation, task, action, result) for exactly this type of question (UW Career & Internship Center). The lesson on explaining a trade-off shows how to justify the rule you picked. Red flag: a story with no numbers, or one where "we" did everything and your own decision is unclear.

25. How would you hand over a cleaning job to a colleague?

Describe three outputs: the rules in order, the exceptions with reasons, and a reconciliation. A short handoff note that says what was assumed and what is still open shows you can work on a team. The lesson on writing the handoff note has a template. Red flag: handing over a script with no notes.

How to prepare for these questions

Reading answers is not the same as giving them. Three habits make the difference:

• Practice on real messy tables. Work through graded tasks such as picking a surviving record per account and joining orders to customers without matching blanks, both of which come up in interviews in some form.
• Say your rule before you write code. In a live round, narrating "I'm checking the grain first" gives the interviewer something to assess even if your syntax slips.
• Prepare one cleaning story. Have a single project you can describe with numbers: rows in, rows flagged, the rule that mattered most.

For topic-by-topic practice, the SQL interview questions page goes deeper, and the preparing for a take-home task guide covers the written format.

Frequently Asked Questions

Are data cleaning interview questions mostly technical or behavioral?

Both. Expect live rounds to mix a short SQL or pandas task with "what would you do" questions about missing values, duplicates and joins. Behavioral rounds ask for a story about messy data. The judgment behind the answer is scored in both.

Should I answer in SQL or pandas?

Use whichever the job description names, and say so. If the role lists neither, ask; if you cannot, SQL is a reasonable default for analyst roles. The cleaning logic, such as a survivor rule or a null-safe join, is the same in both.

How long should my answer to a cleaning question be?

Aim for one to two minutes: the check you would run, the rule you would apply, and how you would confirm nothing was lost. Then stop and ask whether the interviewer wants code.

Related posts

• SQL Data Cleaning Interview Questions With Worked Answers
• pandas Interview Questions on Messy Data
• How to Talk About Data Cleaning in a Data Analyst Interview
• The 10 Most Common Data Quality Problems (and How to Spot Each One)

Sources

• O*NET OnLine, Summary Report for 15-2051.00 Data Scientists, US Department of Labor (retrieved 2026-11-05).
• University of Washington Career & Internship Center, STAR Method of Interviewing (retrieved 2026-11-05).
• DuckDB documentation, QUALIFY clause.
• pandas documentation, pandas.merge.