Validate CSV Company Records for Missing Fields, Length, Forbidden Words and Overlap
StripeSoftware Engineer · Technical ScreenLast updated
Build a validator for a CSV of company records that flags missing fields, values outside length limits and forbidden words, then measures word overlap between fields while ignoring case, spacing and words such as LLC. It tests robust CSV parsing, text normalization, rule-driven design and edge-case testing.
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:
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.
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.
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
Hints
Hint 1
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 2
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.
Hint 3
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 4
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.
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?
Solution walkthrough is for members
Get the full walkthrough with reference code and complexity analysis, plus Kitty Coach at 300 messages a day. Hints, the code runner and community answers stay free.