hardScenarioCodingCase StudyMidSeniorStaff
The business told you a field is always populated, and in production it is null for a third of the rows. How do you work out what is going on and what do you do about it?
7 min readUpdated 2026-08-15
Answer
Short answer
Segment the nulls before drawing any conclusion — by date, source system, record type and creating process — because a null rate that clusters is a documented business path nobody mentioned, while one spread evenly is usually a genuine capture defect.
Was this answer helpful?
Likely follow-ups
- The nulls turn out to be the only rows that matter to the business question. What now?
- How would you tell the difference between a field that was never captured and one that was captured and later overwritten?
- What would you do if the null rate is stable historically but has doubled in the last two months?
- How do you decide whether to fix this in the pipeline, ask the customer to fix it at source, or model around it?
Related questions
- The customer's schema has no documentation and the person who designed it has left. How do you work out what the tables actually mean?hardAlso on customer-data-integration and sql6 min
- How do you tell whether a value escapes to the heap, and how would you find the allocations that are costing you?hardAlso on profiling6 min
- You have read access to the customer's production database and there is no staging environment. How do you develop and test without putting their system at risk?hardAlso on customer-data-integration6 min
- You get a messy customer export and three hours to turn it into something they can use. What do you build first?mediumAlso on customer-data-integration5 min