Given a CSV-formatted string (header row + data rows, e.g.
Given a CSV-formatted string (header row + data rows, e.g. "col1,col2,col3,col4\nvalue1,value2,value3,value4\n"), design and implement a function in pure Python (no external packages such as pandas) that parses and formats the data into a structure usable by other engineering teams. The requirements are intentionally open-ended; the interviewer provides only a single example row and leaves the output format largely up to the candidate. A follow-up then introduces corrupted data: assume headers are always correct, but data rows may have missing values or extra values. The solution must detect and flag invalid rows (e.g. via an is_valid boolean field) so downstream consumers can filter or investigate them.
How would you handle corrupted data in the CSV? Assume the header row is always correct.
Can you implement this from scratch using only pure Python, without any external packages?
What are the trade-offs of different output formats (column-oriented dict, list-of-dicts, row-index-keyed dict)?
| Approach | Notes |
|---|---|
| Column-oriented dict {col_name: [values]} | Simple to construct and easy to access all values for a single column; harder to attach per-row metadata like is_valid. |
| Row-oriented list of dicts [{col_name: value, ..., is_valid: bool}] | Natural fit for per-row validation flags and easy filtering; slightly more verbose to build. |
| Row-index-keyed dict {row_index: {col_name: value, is_valid: bool}} | Preserves original row index for debugging corrupted rows; less idiomatic than a list of dicts. |
Common mistakes: Proposing pandas — the interviewer rejected it and required pure Python regardless.; Not proactively estimating downstream needs when the problem is open-ended; one candidate reflected afterward that self-estimating requirements was likely what was expected.
Interviewer hints: Interviewer said there is no correct answer and wanted to see 'where it goes' — signaling that design reasoning matters more than the specific output format.; Interviewer explicitly said the solution must be 'very generic,' ruling out data-type validation and narrowing corrupted-data handling to missing and extra fields only.; When pandas was proposed, the interviewer still required writing from scratch — no external packages.; Interviewer gave only a single example row via verbal description and asked the candidate to take notes, with no written problem statement.
What passers do: Proactively asked clarifying questions and proposed multiple output formats with pros/cons before writing any code, then confirmed the interviewer was on the same page.; Added an is_valid boolean field to each row's dict so downstream consumers can filter valid rows or investigate invalid ones — framed it explicitly as a downstream-usability decision.; Enumerated corruption cases (missing values, extra values, wrong types) and then correctly scoped out type-checking as not feasible for a generic solution.