Preparing for a data cleaning take-home task

Read the brief like a contract

Underline every rule: formats, ranges, the grain, what to do with invalid rows. Where the brief is silent, write the assumption you make and why. Reviewers look for stated, defensible assumptions rather than hidden guesses.

Deliver more than a clean table

Submit the clean table, an exception table with one reason per rejected row, and a short summary of the rules you applied. Include a reconciliation: input rows equal clean rows plus exceptions plus rows filtered as out of scope.

• Clean output in the requested schema and types.
• Exceptions with the first failing reason.
• Counts by reason and the reconciliation.
• Assumptions and open questions.

Write code that runs on the next file

Reviewers often run your code on a second dataset. Rules written from the specification survive that; rules tuned to the values you saw don't. Test your own code on a few hand-made edge cases: an empty string, a missing key, a boundary value, a tie.

Practise explaining trade-offs

Expect follow-up questions: why quarantine instead of fix, why this survivor, what you would ask the data owner. The interview question bank on this site has model answers to practise with.