Katkat

Optimize with a cache/hash map

AmazonSoftware Engineer · Technical Screen

Last updated

Amazon software-engineer technical-screen coding follow-up: take an existing script (e.g. one that resolves file paths or parses license strings) and design a hash-map-backed in-memory cache to speed up repeated lookups. It tests choosing a cacheable computation, defining normalized keys and values, estimating hit rate, picking an eviction policy (LRU/LFU/TTL), invalidating on file mtime/content-hash changes, ensuring concurrency safety, and analyzing time and space complexity before and after caching.

Question

This is a follow-up to your existing implementation (for example, a script that repeatedly resolves file paths or parses license strings into computed results). Propose and analyze an optimization that adds an in-memory cache backed by a dictionary/hash map to speed up repeated lookups. Address each part:

  1. Where to cache. Identify the spot in your code where caching or a hash map would actually help — i.e. a pure, repeated, deterministic computation whose inputs recur. Justify why that call is a good candidate and why other calls are not.
  2. Keys and values. Specify the cache key (what uniquely identifies a computation, e.g. the file path or the normalized license string) and the cached value (the computed result). Note any normalization needed so logically-equal inputs map to the same key.
  3. Expected hit rate. Estimate the expected cache hit rate given the access pattern, and explain what assumptions drive it (input cardinality vs. number of lookups, temporal locality).
  4. Eviction policy. Choose and justify an eviction policy (LRU / LFU / TTL, or a bounded dict with no eviction) based on working-set size and memory budget.
  5. Invalidation / staleness. Describe how you keep cached values correct when the underlying source changes — e.g. invalidating an entry when a file's mtime or content hash changes, or expiring via TTL — and the consistency vs. staleness trade-off you are accepting.
  6. Concurrency safety. Discuss what happens if multiple threads or processes run concurrently: races on get/put, the thundering-herd / cache-stampede problem on a miss, and how you'd make it safe (locking, per-key locks, or a process-local cache).
  7. Pseudocode. Provide get/put pseudocode that includes the validation/invalidation check on read.
  8. Complexity. State the time and space complexity of the relevant operation before and after adding the cache.