Validate CSV Company Records for Missing Fields, Length, Forbidden Words and Overlap

You are given a batch of company records as CSV text: a header row that names the fields, followed by one row per company. Write a validator that checks every record against a set of rules and reports, for each record, the rules it fails. The work comes in two stages: first checks on individual fields, then a comparison of the words used across several fields of the same record. The task does not fix the field names, which fields are required, the length limits, the forbidden words or the words to ignore. Treat them as configuration passed to your validator, and settle the details with the interviewer. An illustrative input, with made-up columns and values, looks like this: ```text id,name,legal_name,description 1,Acme Widgets,Acme Widgets LLC,Industrial widgets for factories 2,,Bright Labs LLC, 3, ACME widgets , acme widgets llc,Widgets ``` ### Constraints and Clarifications - The first line is the header, and every later line is one record. A quoted value may contain a comma, so the text has to be parsed as CSV rather than split on commas by hand. - The validator reports problems. It never repairs, reorders or drops records. - All rule parameters are inputs, not constants: the required fields, the length limits, the forbidden words, the ignored words, which fields are compared for overlap, and what counts as enough or too much overlap. ### Clarifying Questions - Does a value that contains only whitespace count as missing? - Is a value's length measured before or after trimming surrounding whitespace, and is the limit a minimum only, or both a minimum and a maximum? - Is a forbidden word matched only as a whole word, or also inside a longer word? Can a forbidden entry be a phrase of several words? - Which fields are compared for word overlap, and is overlap a count of shared words or a ratio? Does the rule require enough shared words, or forbid too many? - Should punctuation, such as the period in "Inc.", be removed before words are compared? - Should a record report every rule it fails, or only the first? - What should the output look like: a list of failures per record, a pass or fail flag per record, or both? ### Part 1 — Single-field checks For each record, check that every required field is present and non-empty, that every field with a length rule satisfies it, and that no checked field contains a forbidden word. Report each failure with the record's identifier, the field, and the rule that failed. ```hint Separate parsing from rules Turn the CSV into a list of field-to-value mappings first, then express each rule as a small check over one record, so that adding a rule never touches the parser. ``` ```hint Decide what a word is Forbidden-word matching depends on how a value is split into words and how letter case is treated. Pin that down before writing the check, because Part 2 needs the same decision. ``` #### What This Part Should Cover - CSV parsing that copes with quoted values and with rows that have too few or too many columns - A precise definition of "missing" and of how length is measured - A deliberate choice between whole-word and substring matching for forbidden words, including letter case - A failure report that names the record, the field and the rule ### Part 2 — Word overlap across fields Now compare the words used in several fields of the same record and measure how many of them overlap. The comparison must ignore differences in letter case and spacing, and must ignore words from a configured list, such as `LLC`. Report every record whose overlap breaks the configured rule. ```hint Normalize once, compare many times Write one function that turns a raw value into the collection of words you actually compare, and send every compared field through it. ``` ```hint Watch what the ignored words leave behind Consider what your overlap measure should do when a field is empty, or when it contains nothing but ignored words. ``` #### What This Part Should Cover - One normalization step shared by every comparison: case folding, whitespace handling, tokenization and removal of ignored words - A clearly defined overlap measure (a count of shared words or a ratio) and the direction of its threshold - Degenerate values: empty fields, fields that normalize to nothing, and repeated words - How overlap failures join the Part 1 report without reporting the same problem twice ### What a Strong Answer Covers - A rule-driven design in which the rules are data and a new check is cheap to add - Correct behavior on messy input: quoting, stray whitespace, mixed case and blank lines - Running time linear in the size of the CSV, with the complexity stated - Tests covering the pass and fail cases of every rule, including the normalization edge cases - Deterministic output order, so the same input always produces the same report ### Follow-up Questions - The file is too large to hold in memory. What changes in the validator? - Near-matches, such as a misspelled word, should now count as overlapping. How would you extend the measure, and what does that cost? - The forbidden list grows very large and includes many multi-word phrases. How do you keep matching fast? - How would you let non-engineers add or change rules without deploying new code?