Parse Pipe-Delimited Order Lines: Totals, Cheapest Promotion per SKU, Aisle Ordering

You are building a small checkout helper that reads records whose fields are separated by `|`. The task grows in three steps; each step adds a new kind of input and builds on the code from the previous step. ### Clarifying Questions - Do the three kinds of records arrive as three separate lists of strings, or mixed together in one stream? - When a record is bad, should it be skipped silently, skipped and reported, or should the whole input be rejected? - Can the same SKU appear on more than one order line, and can those lines carry different prices? - What exactly should be returned: raw numbers, a formatted string, or a structured result? ### Part 1 — Totals from order lines Each order line has the form `SKUid|SKUNAME|QUANTITY|Price`, where `Price` is given in cents. Return the total quantity and the total price in dollars. The input may contain bad lines, and they must not break the computation. For example, if `Price` is a unit price and bad lines are skipped, the input ```text APPLE|Apple|7|100 MILK|Milk|2|350 ICE|Ice cream|1|599 BAD|Broken|x|100 CHIPS|Chips|3 ``` has a total quantity of 10 and a total price of 19.99 dollars. The last two lines are bad: one has a non-numeric quantity and the other is missing a field. ```hint Where validation lives Decide where each line is validated, and in which numeric type money is held until the moment it is formatted for output. ``` #### Clarifying Questions for this Part - Is `Price` the price of one unit, or of the whole line? - Which records count as bad: a wrong number of fields, an empty SKU id, a quantity or price that is not a whole number, a zero or negative quantity? - How should the dollar amount be formatted, for example always with two decimal places? #### What This Part Should Cover - A parsing step that turns each line into a validated record or a clear rejection reason. - Exact money arithmetic in integer cents and a correct conversion to dollars. - An explicit, testable policy for bad input. ### Part 2 — Promotions A second input lists promotions, one per line, in one of two formats: - `SKUid|axf|20`: a 20% discount on that SKU. - `SKUid|bxf|5|2`: buy 5, get 2 free. A SKU can have several promotions. For each SKU, choose the promotion option that results in the lowest price, and return the totals after promotions. ```hint One shape for every promotion Give every promotion type the same interface: given a quantity and a unit price, return a cost. Choosing the best option then reduces to a comparison. ``` #### Clarifying Questions for this Part - For buy 5 get 2 free: do 7 units in the cart cost the price of 5, and what do 6 units cost? Or does buying 5 add 2 extra units at no charge? - How should a percentage discount that produces a fraction of a cent be rounded? - Does a promotion apply per order line, or to the SKU's combined quantity across lines? - What happens to a promotion for a SKU that is not in the order, or to one with an invalid value such as a discount above 100%? #### What This Part Should Cover - Correct pricing for both promotion types, including rounding and incomplete buy-X-get-Y groups. - Choosing the cheapest option per SKU, with "no promotion" as a valid baseline. - Validation of promotion records, and a structure that accepts new promotion types without changing the existing ones. ### Part 3 — Aisle ordering A third input maps SKUs to their place in the store: `SKUid|aisle|isFrozen`, for example `APPLE|3|false`, where the middle field is the aisle number and the last field says whether the product is frozen. Output the ordered products sorted by aisle, with frozen products placed after all other products. ```hint One key, not several passes Try to express the whole ordering as a single sort key, and check that the key also settles ties and products without location data. ``` #### Clarifying Questions for this Part - Are the frozen products also sorted by aisle among themselves? - How should products in the same aisle be ordered? - What if an ordered SKU has no location record, or two conflicting ones? #### What This Part Should Cover - A composite sort key that places frozen products last and compares aisles as numbers, not strings. - Deterministic tie-breaking and a defined place for products with missing location data. - Reuse of the parsing and validation approach from Part 1. ### What a Strong Answer Covers - One parsing and validation layer shared by all three record types, with bad records reported rather than silently changing the totals. - Money kept exact in integer cents from input to formatted output. - Promotion pricing that is correct, separately testable, and open to new promotion types. - Tests aimed at the tricky inputs: bad lines, repeated SKUs, rounding, incomplete promotion groups, and numeric aisle ordering. - Every ambiguous rule stated explicitly, with a note on how the code changes if the interviewer chooses differently. ### Follow-up Questions - How would the design change if promotions could stack, for example a percentage discount on top of buy-X-get-Y? - How would you add a promotion that spans several SKUs, such as any three items from a group for a fixed price? - If the order input had millions of lines, what would you change to process it as a stream? - How would you return bad-input diagnostics so that the team producing the data can fix it?