Hash Maps & Design

Two rounds lean hardest on this material. The earlier technical coding screen is where hash maps show up most directly, a shared editor and a practical medium problem that usually reduces to counting, grouping, or one-shot lookups. The pair-programming build is where the design side lives. It runs as an iterative session in your own IDE: you start with the simplest working version of a small feature, then grow it as the interviewer layers on requirements. At Shopify the feature is almost always something you'd recognize from the product. A cart holding line items, an inventory count that must never oversell, a cache in front of a storefront, a limiter on a merchant's API traffic. Under the commerce wrapper, each one is a hash map doing the heavy lifting.

The mental model is short. A hash map is your index: one entry per key, constant-time to read, write, and update, which is exactly what a cart keyed by variant or an inventory keyed by SKU wants. Some designs need an order or an eviction rule the map alone cannot express. Those pair the map with a companion structure so both the lookup and the ordering stay fast. Hold money as integer cents and stock as whole units throughout, so a total never drifts and a count never slips below zero. Learn where the map goes and what to bolt onto it, and this whole tier of Shopify problems stops being about tricks.