Optimize with a cache/hash map
AmazonSoftware Engineer · Technical ScreenLast 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:
- 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.
- 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.
- 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).
- Eviction policy. Choose and justify an eviction policy (LRU / LFU / TTL, or a bounded
dictwith no eviction) based on working-set size and memory budget. - Invalidation / staleness. Describe how you keep cached values correct when the underlying source changes — e.g. invalidating an entry when a file's
mtimeor content hash changes, or expiring via TTL — and the consistency vs. staleness trade-off you are accepting. - 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).
- Pseudocode. Provide
get/putpseudocode that includes the validation/invalidation check on read. - Complexity. State the time and space complexity of the relevant operation before and after adding the cache.
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.