Given an order object (containing a destination country and a list of items with product name and quantity) and a shipping cost table (mapping country → product → price rules), calculate the total shipping cost for the order.
Part 1 – Fixed unit pricing: Each product has a single flat cost per unit. Example: US mouse=$550, US laptop=$1000; an order of 20 mice + 5 laptops in the US costs $16,000.
Part 2 – Tiered/incremental pricing: The cost table is replaced with quantity-range tiers: each product entry has a list of {minQuantity, maxQuantity, cost} objects. Cost per unit decreases as quantity grows. Calculate the total by splitting the ordered quantity across applicable tiers and summing (units_in_tier × tier_cost). maxQuantity=null means no upper bound. The tier list is NOT guaranteed to be sorted.
Part 3 – Mixed fixed vs. incremental types: Each tier object gains a 'type' field: 'incremental' behaves like Part 2 (cost × units in tier); 'fixed' means a flat charge for the entire tier regardless of how many units fall in it (e.g., if the 0–2 laptop tier is 'fixed' at $1000, ordering 1 or 2 laptops both cost $1000 total for that tier).
Input format (Python-style, similar structures in Java/JS):
order = {"country": "US", "items": [{"product": "mouse", "quantity": 20}, {"product": "laptop", "quantity": 5}]}
shipping_cost = {"US": [{"product": "mouse", "cost": 550}, ...], "CA": [...]}
For Parts 2/3 the cost entry changes to: {"product": "laptop", "costs": [{"type": "incremental", "minQuantity": 0, "maxQuantity": 2, "cost": 1000}, ...]}
Function signatures are self-defined (no starter signature provided in most sessions). Test cases are typically provided by the interviewer via HackerRank, but some sessions (especially higher-level ones) require the candidate to write their own test cases. The problem is delivered in HackerRank or a shared IDE.
What edge cases would you add test coverage for?
Is the cost tier list guaranteed to be sorted by minQuantity?
If this function were exposed as an API, what HTTP error codes would you return for different error scenarios (e.g., unknown country, unknown product, null quantity)?
If a customer orders 1 unit in a fixed-cost tier covering 0–2 units at $1000, how much do they pay?
| Approach | Notes |
|---|---|
| Using Math.min(remainingQty, maxQty - minQty) formula | Avoids nested conditionals and if-chains for tier boundary handling; cleaner and less error-prone than explicit if/else per tier, but requires careful handling of null maxQuantity (treat as infinity). |
Common mistakes: Writing test cases incorrectly and then spending many minutes debugging what turned out to be a wrong expected value copied from a previous test — not a bug in the solution itself.; One candidate warned that using nested if-statements to handle tier boundaries caused them to get tangled in edge cases and run out of time, and recommended a cleaner clamping approach instead.; Spending too much time explaining rather than coding, leaving Part 3 unreached.; At least one candidate reported misunderstanding Part 2's incremental pricing logic and needing extra time to re-clarify the problem, which reduced time available for Part 3.
Interviewer hints: When asked whether the tier list is sorted, the interviewer said to assume it is NOT sorted.; Some interviewers said upfront they would only watch and not interact much during the session.; After completing each part, at least one interviewer asked the candidate whether they wanted to add more test cases, and indicated this was optional.; At least one interviewer explicitly told the candidate they could explain their approach rather than finish coding Part 3 when time was running short — and that candidate still passed.; One candidate reported that their interviewer highlighted code to give a silent hint about where to look, without speaking.
What passers do: Candidates noted that writing clean, readable code with meaningful names and well-named helper functions was important. One candidate reported that because their first two parts were well-organized with helper functions, Part 3 required changing only one helper function.
Why people fail: Spending too much time explaining rather than implementing — 'talked too much, wrote too slowly'
Edge cases probed: maxQuantity = null (no upper bound for last tier) — must be handled as infinity; Tier list not sorted by minQuantity; Nested object structure in test cases (Object containing List<Object>); Unsorted tier list
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 70 Stripe questions, refreshed monthly from new candidate reports.