class LRUCache:
Debugging challenge — find the bug(s) in this LRU cache.
You are handed a compiling LRUCache that does not satisfy its spec, and asked to find what is wrong with it. The problem says "bug(s)" and does not say how many.
Spec:
get(key) returns the value for the key, or null if absent. Accessing a key makes it the most recently used.put(key, value) sets or updates the value. If the cache is at capacity, evict the least recently used entry first. Inserting or updating a key makes it the most recently used.Worked example given with the problem (capacity 2):
cache = LRUCache(2)
cache.put(1, "a") # {1: a}
cache.put(2, "b") # {1: a, 2: b}
cache.get(1) # "a" -> 1 is now most recently used
cache.put(3, "c") # at capacity -> evicts key 2
cache.get(2) # null (evicted)
cache.get(1) # "a" (still present)
The handed code is Java, backed by a LinkedHashMap<Integer, String>. The starter is a Python port of it, bugs included.
Bonus points: write a failing test case for each bug you find.
What the tests call. Fix the starter in place and keep its interface: LRUCache(capacity), get(key) returning the value or None, and put(key, value). The tests drive the fixed class through get and put only and check which keys have been evicted. Our setup — ask your interviewer: the Python port, None for null, and the test scenarios beyond the worked example.
Standard explanation — no candidate report records what the interviewer accepted here.
No interviewer answer is recorded; this is our analysis. Write each test so it pins down which key is least recently used, through gets and updates, and asserts exactly which key is evicted; include the worked example and an update-then-evict case. Run every test after every change: a fix can make a scenario that used to pass start failing, so a test that passes on the handed code is not proof that the code is right.
One report, posted July 2026, and it is the problem text and the code only: no round, no outcome and no follow-ups are recorded. Asked whether it was the practical-coding round, a reply says "Nope it the interview question"; a later question about whether it was the AI-assisted round got no recorded answer. The post is formatted like a prepared exercise, so treat the code as the version the poster shared (our read).
Debugging challenge — find the bug(s) in this LRU cache.
You are handed a compiling LRUCache that does not satisfy its spec, and asked to find what is wrong with it. The problem says "bug(s)" and does not say how many.
Spec:
get(key) returns the value for the key, or null if absent. Accessing a key makes it the most recently used.put(key, value) sets or updates the value. If the cache is at capacity, evict the least recently used entry first. Inserting or updating a key makes it the most recently used.Worked example given with the problem (capacity 2):
cache = LRUCache(2)
cache.put(1, "a") # {1: a}
cache.put(2, "b") # {1: a, 2: b}
cache.get(1) # "a" -> 1 is now most recently used
cache.put(3, "c") # at capacity -> evicts key 2
cache.get(2) # null (evicted)
cache.get(1) # "a" (still present)
The handed code is Java, backed by a LinkedHashMap<Integer, String>. The starter is a Python port of it, bugs included.
Bonus points: write a failing test case for each bug you find.
What the tests call. Fix the starter in place and keep its interface: LRUCache(capacity), get(key) returning the value or None, and put(key, value). The tests drive the fixed class through get and put only and check which keys have been evicted. Our setup — ask your interviewer: the Python port, None for null, and the test scenarios beyond the worked example.
Bonus points: write a failing test case for each bug you find.
Send them this page. It is free to read, no account needed.
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 14 Zip questions, refreshed monthly from new candidate reports.