Data Analytics Data Cleaning Interview Questions and Answers

Data cleaning is where analysts spend most of their time, so interviewers treat it as a proxy for judgement. The questions are rarely about a single function — they are about whether you understand why data is dirty, and whether your fix preserves the truth of the analysis or quietly distorts it. This page covers the cleaning questions that recur in analyst interviews, with practical SQL and pandas and the decision-making interviewers reward.

How to answer data cleaning questions

Always tie the fix to the downstream use and to why the data is dirty. "I would impute the median because income is right-skewed and the column feeds a segmentation" beats "I would use fillna". Interviewers are checking that you never destroy or invent data casually.

Q1. Walk me through your data cleaning process.

Profile the data first (types, ranges, null counts, distinct values), then address structural issues in order: fix data types, standardize formats, handle missing values, remove or resolve duplicates, treat outliers, and validate against business rules. Keep the raw data intact and script every step.

Leading with profiling signals maturity — you look before you touch. The ordering matters too: fixing types and formats first often reveals that apparent "missing" values were really parsing failures. Ending with validation against known rules (a date of birth cannot be in the future) shows you close the loop.

Interview note: Follow-up: "how do you know when the data is clean enough?" When it satisfies the business rules and the analysis it feeds — clean is relative to purpose, not an absolute state.

Q2. How do you handle missing values?

First understand the mechanism: missing completely at random, at random, or not at random. Then choose — drop rows when missingness is small and random, impute (median for skewed numerics, mode for categoricals, forward-fill for time series) when the column is needed, or add a missing-indicator flag when the absence itself is informative.

The nuance that scores: imputing can bias results. Filling missing income with the mean shrinks variance and can hide the very pattern you are studying. And "not missing at random" — where the fact that a value is missing depends on the value itself — is the dangerous case that no simple imputation fixes.

# median is robust to skew; mode for categoricals
df["income"] = df["income"].fillna(df["income"].median())
df["city"] = df["city"].fillna(df["city"].mode()[0])
df["was_missing_income"] = df["income"].isna().astype(int)  # keep the signal

Interview note: Trap: "just drop every row with a null?" On wide tables that can delete most of your data. Drop by column relevance, not blindly.

Q3. How do you find and remove duplicate records?

Detect duplicates by grouping on the columns that define identity and counting; remove them by keeping one deterministic survivor per group. Decide whether a duplicate means fully identical rows or the same entity recorded twice with minor differences.

-- detect duplicate customers by email
SELECT email, COUNT(*) AS n
FROM customers
GROUP BY email
HAVING COUNT(*) > 1;

The interviewer's real question is how you pick which record to keep — most recent, most complete, or a merge of both. Saying "I keep the latest by updated_at and log the removed ids" shows you treat deletion as auditable, not casual.

Interview note: Follow-up: "what about near-duplicates like 'Jon Smith' and 'John Smith'?" That is fuzzy matching — normalize casing and whitespace first, then use string-similarity or a matching key rather than exact equality.

Q4. How do you detect and handle outliers?

Detect with the IQR rule (below Q1 − 1.5×IQR or above Q3 + 1.5×IQR) or the z-score (beyond about ±3 standard deviations). Handle by investigating first: a genuine extreme value is kept, a data-entry error is corrected, and only clearly invalid points are removed or capped.

The judgement point is that an outlier is not automatically wrong. A ₹10,00,000 order might be a real bulk purchase, not noise — deleting it would erase your most important customer. Capping (winsorizing) is a middle path when extremes distort a mean but the rows are legitimate.

Interview note: Trap: "z-score always?" The z-score itself is sensitive to the outliers it is trying to find, and assumes rough normality. For skewed data the IQR method is more robust.

Q5. How do you standardize inconsistent categorical data?

Normalize casing and whitespace, map synonyms and abbreviations to a canonical value, and validate against an allowed list. Inconsistent categories silently split what should be one group in every aggregation.

UPDATE customers
SET state = 'NY'
WHERE UPPER(TRIM(state)) IN ('NEW YORK', 'N.Y.', 'NY');

"New York", "new york" and "NY" counting as three states is the kind of bug that makes a dashboard wrong without any error message. Catching it demonstrates you understand that GROUP BY is only as clean as its keys.

Interview note: Follow-up: "how do you prevent it recurring?" Constrain at the source — a lookup table or enumerated column — so bad values cannot be entered in the first place.

Q6. How do you handle inconsistent date and number formats?

Parse everything into a single canonical type as early as possible: dates into a real date type, numbers stripped of currency symbols and thousands separators into numerics. Store in ISO format and apply timezone handling consistently.

Mixed formats like 01/02/2026 are ambiguous (Jan 2 or Feb 1?), and text-stored numbers break sorting and math. An analyst who asks "which date format is the source using?" instead of assuming avoids a whole class of silent errors.

df["order_date"] = pd.to_datetime(df["order_date"], format="%d/%m/%Y",
                                  errors="coerce")  # bad parses -> NaT, then inspect

Interview note: Trap: "errors='coerce' just hides problems?" It surfaces them as NaT/NaN so you can count and review them, rather than crashing or silently mis-parsing. Always inspect what it coerced.

Q7. What is data validation, and how do you apply it?

Data validation checks data against expected rules — types, ranges, uniqueness, referential integrity and business logic — to catch errors before analysis. Examples: ages between 0 and 120, order totals non-negative, every order's customer_id existing in the customers table.

Framing validation as automated and rule-based (rather than eyeballing) is what interviewers want. A quick set of assertions that fail loudly is far safer than trusting that upstream systems sent clean data.

Interview note: Follow-up: "where should validation live?" As close to ingestion as possible, so bad data is caught before it contaminates reports — and ideally re-run every load.

Q8. How do you ensure your cleaning is reproducible and trustworthy?

Never edit raw data by hand. Script every transformation in SQL or pandas, keep the raw source immutable, document each assumption, and log what was changed and dropped. A reproducible pipeline can be rerun and audited; a manually cleaned spreadsheet cannot.

This is increasingly a differentiator. When an interviewer asks "the numbers changed last month — why?", the analyst with a scripted, version-controlled pipeline can answer; the one who cleaned by hand cannot. Reproducibility is a data-quality guarantee, not a nicety.

Interview note: Trap: "cleaning is a one-time task?" No — new data arrives dirty in the same ways, so cleaning logic must be a repeatable pipeline, not a one-off cleanup.

What interviewers really test

Every cleaning question is really asking: will you preserve the truth of the data, or quietly distort it to make the analysis easier? The strongest answers connect each decision to why the data is dirty and what it feeds downstream. Pair this page with the SQL for analysts questions and the Python for analysts set, since deduplication, NULL handling and type fixing are where those skills meet cleaning in practice. A structured Data Analytics path and a mock interview focused on a real messy dataset will sharpen the judgement these questions reward.