Commure·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026Remote

Summary

Commure SWE interview threw a combined LRU cache plus TTL problem at me, which felt like two problems duct-taped together. The follow-up extensions they hinted at made it clear they wanted to see how far you could take the design, not just get a working solution.

Questions Asked (1)

Design and implement an LRU cache where each entry has its own TTL. The get operation should return -1 and remove expired entries, and put should evict the least-recently-used entry when at capacity, preferring expired entries first.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

I knew the vanilla LRU implementation cold, OrderedDict plus a size cap, but the TTL layer threw me off more than I expected.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a design combining a hash map for O(1) access and a doubly linked list for LRU ordering, with each node storing an expiration timestamp. Explain how get checks TTL and removes expired entries, and how put evicts expired entries first, then LRU if needed, before implementing the core operations.

Pro tip: Mention that you would use a min-heap or time-ordered structure to efficiently find expired entries, but since eviction only happens on put, a lazy approach of checking the LRU list for expired entries is often sufficient and simpler. Also, discuss trade-offs between eager vs lazy expiration and how it affects performance and memory.

1. Clarify Requirements and Constraints

Ask about expected cache size, TTL granularity, concurrency needs, and whether expired entries should be actively purged or lazily removed. Confirm that get should return -1 and remove expired entries, and put should evict expired first, then LRU.

2. Choose Data Structures

Propose a hash map (for O(1) key lookup) and a doubly linked list (for O(1) LRU updates). Each node stores key, value, expiration timestamp, and pointers. Optionally, mention a min-heap for expiration tracking if eager cleanup is needed.

3. Define Operations

For get: check if key exists and not expired; if expired, remove and return -1; else move node to front (most recently used) and return value. For put: if key exists, update value and TTL, move to front; else if at capacity, evict expired entries first (scan from LRU end), then evict LRU if needed; insert new node at front.

4. Handle Expiration and Eviction

Explain that on put, you can scan from the least-recently-used end to find expired entries, removing them until capacity is available or no expired entries remain. If still at capacity, remove the LRU entry. Discuss trade-offs: scanning may be O(n) in worst case, but often fast if few expired entries.

5. Analyze Complexity and Trade-offs

State that get and put are O(1) average for hash map and linked list operations, but eviction may be O(k) where k is number of expired entries scanned. Mention alternative designs like using a min-heap for expiration to achieve O(log n) eviction, and discuss concurrency considerations if needed.

Key Points to Mention

Use a hash map for O(1) key lookup and a doubly linked list for O(1) LRU ordering.
Store expiration timestamp in each node and check it on get.
On get, if expired, remove the entry and return -1.
On put, evict expired entries first by scanning from the LRU end, then evict the LRU entry if still at capacity.
Discuss trade-offs between lazy expiration (on access) and eager expiration (background thread or heap).
Mention concurrency handling (e.g., locks or concurrent data structures) if the cache is shared across threads.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.