jdfive

Clarify Requirements

What the interviewer just asked

You paused after the prompt. Now gather requirements — write them on the board so the interviewer can course-correct early.

Functional questions to ask

  1. What operations? Usually get(key) and put(key, value).
  2. What is the capacity? Fixed at construction time, or configurable later?
  3. What happens on eviction? Remove the least-recently-used entry when inserting would exceed capacity.
  4. What does get return on a miss? Typically -1 (or Optional.empty() if they prefer).
  5. Does put on an existing key update recency? Yes — treat it like a fresh access; move that entry to most-recently-used.
  6. Do we need remove(key) or size()? Ask; many variants include them, the classic LeetCode prompt does not.

Non-functional questions

  1. Thread-safe? Almost always yes in an LLD concurrency round.
  2. Single JVM or distributed? Start in-memory, single process unless they insist on multi-node.
  3. Exact LRU or approximate? Strict LRU reorders on every get. Approximate LRU (batch recency updates) trades correctness for throughput — name the trade-off if they care about QPS.
  4. Expected throughput / read-write ratio? Heavy read traffic does not automatically mean ReadWriteLock helps — get mutates the list in strict LRU (covered later).

What you produce on the board

Functional

  • get(key) — return value if present; return -1 on miss; update recency on hit
  • put(key, value) — insert or update; evict LRU entry when size would exceed capacity
  • Fixed capacity set at construction

Non-functional

  • Thread-safe for concurrent get and put
  • In-memory, single JVM for v1
  • O(1) get and put
  • Exact LRU semantics unless interviewer accepts approximate recency

Out of scope (say explicitly)

  • Distributed cache across pods (Redis, Hazelcast — discuss later)
  • Persistence across restarts
  • TTL-based expiry (that is a different cache design)
  • Cache statistics, metrics, or admin UI

Scope sentence you can say out loud

“I’ll build a thread-safe in-memory LRU cache with O(1) get and put, fixed capacity, LRU eviction, and -1 on miss. I’ll start with the data structure, show LinkedHashMap as the idiomatic Java answer, then walk through synchronized locking and why ReadWriteLock does not help for strict LRU.”