Forward deployed round
Customer Data Schema Mapping Coding Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Real customer data is never clean. Types are inconsistent, fields are null where you expected values, the same column arrives as a string in one row and a number in the next. A forward deployed engineer’s job is to map that mess into your schema without losing rows and without coercing values into nonsense — quietly dropping a customer’s records is how you lose their trust.
Interviewers ask this because ingestion is where integrations actually break. A mapper that assumes clean input silently drops rows it cannot parse, or coerces a malformed value into a wrong-but-valid one. The count looks close, the data is subtly corrupted, and nobody notices until the customer does.
The scenario
You are given a mapping function that ingests a batch of customer records from CSV/JSON with inconsistent types and null fields. It coerces some values incorrectly and silently drops rows it should have handled or explicitly rejected.
The tests assert that every input row is accounted for — mapped correctly or rejected on purpose, never silently lost — and that coercions produce the right typed values. Your job is to make the mapping robust to the mess without dropping data on the floor.
What you’ll practice
- Robust type coercion across inconsistent inputs
- Handling nulls and missing fields explicitly
- Never silently dropping rows: map, or reject with a reason
- Preserving row-count accountability through ingestion
- Turning messy external data into a clean internal schema
How to approach it
Anchor on accountability: every input row should have a definite outcome, and "silently vanished" must not be one of them. Then interrogate the coercions — ask what the code does with a row whose type is unexpected or whose field is null: decide deliberately, throw, or quietly produce a wrong value?
Use the row-count assertion as your invariant: inputs in must equal mapped plus rejected out. Any gap is a row you dropped silently, which is the bug.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Why is silently dropping rows the core bug?
Because it is invisible. An error you can see and fix; a row that quietly disappears during ingestion corrupts the dataset and erodes customer trust before anyone notices. Explicit reject-with-reason is the fix.
Is this a pandas problem?
The concepts — robust coercion, null handling, row accountability — apply whether you use pandas or plain Python. The problem is about defensive ingestion of untrusted external data.