Caching Interview Questions: LRU, Expiry and Durable Caches

As of 2026-10-16, TrueInterview's bank holds 43 candidate-reported caching questions from 17 big-tech companies, and 42 of them were last reported within the previous 12 months. By format, 32 are object-oriented design, 4 are coding (algorithm), 3 are AI-assisted coding and only 2 are system design. Among these 43 caching-titled questions, most are build-a-cache-in-code-then-extend-it problems rather than whiteboard designs of a distributed cache; system design prompts where caching is only one component are not counted here. Prepare one LRU cache you can extend and debug under follow-ups, and use distributed-cache theory as the reasoning behind each extension.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

Which caching questions do candidates actually report?

LRU Cache leads by a wide margin: it is linked from 24 candidate interview write-ups from 7 big-tech companies, twice the next question. Below it sit a durable key-value cache, a cache bug-fix task, an expiring cache and three LRU variants. Seven of the top eight rows are implement-a-cache questions, with the Databricks WAL cache, a system design question, as the exception; that tells you where the preparation hours belong.

Write-up links count how many candidate write-ups point to a question, not how often a company asks it. Read the table as a family rather than eleven problems: seven rows are LRU, a weighted or frequency-based variant of it, or a debugging task built on it. If you can implement the first row cleanly and change its eviction rule without a rewrite, most of the table becomes follow-up practice on code you already own.

Breadth across companies points the same way. The LRU debug variant is filed under 8 big-tech companies (Anthropic, Amazon, ByteDance, Google, LinkedIn, Microsoft, Oracle, Uber), more than any other question in the table. LRU Cache and Weighted LRU Cache are filed under 7 each, and the thread-safe follow-up under 5.

Which companies and rounds report caching questions?

LinkedIn has the most caching questions in the bank with 9, followed by Amazon (8), Netflix (7), ByteDance (7), Microsoft (6), Oracle (6), Google (6), Anthropic (5), OpenAI (5) and Apple (4). At the six companies with the most questions, object-oriented design is the dominant format. If your loop is at one of them, expect to write a cache class, not draw one.

Rounds split 30 onsite reports to 20 phone-screen reports, and a question can be reported in more than one round. Object-oriented design is the most frequent subtype in both: 12 of the 17 other-format phone-screen questions and 22 of the 26 onsite ones. Since object-oriented design dominates both rounds, prepare the same cache code for either one rather than splitting by round. Durability is not onsite-only: Anthropic's bug-fix and durability task was reported in a phone screen, so prepare it early if Anthropic is on your list.

Single-company rows deserve proportionate time. The WAL-backed cache, the Anthropic bug-fix task and Netflix's Weighted Cache each come from one company's write-ups, so they matter a great deal for that loop and much less as a general signal. Google's onsite report of LRU Cache II, last reported 2025-12, is a reminder that Google files an LRU variant too.

How do you answer LRU Cache, and what comes after it?

LRU Cache asks for get and put in O(1): a hash map from cache key to a node in a doubly linked list ordered by recency, with the head as most recent and the tail as the eviction candidate. That shape is named in the title of the LRU debug question filed under eight companies. The base implementation is table stakes; the reported follow-ups are where the interview happens.

The reported variants form a ladder you can climb on one codebase:

1. TTL and LFU. ByteDance's phone-screen report is "LRU Cache (with TTL and LFU Follow-ups)", last reported 2026-09. Store an expiry time per entry and decide whether you expire lazily on read or sweep in the background. For LFU, keep one recency list per frequency and track the current minimum frequency so eviction stays O(1).
2. Thread safety. LinkedIn's thread-safe follow-up was reported in a phone screen in 2026-08. A single lock around both the map and the list is correct and easy to defend; the senior conversation is about contention, and whether a striped or read-mostly design is worth its complexity for this workload.
3. Weighted capacity. Amazon's Weighted LRU Cache was reported in a phone screen in 2026-08. Capacity becomes total weight, so eviction loops from the tail until the new item fits, and you must decide what happens when one item outweighs the whole cache.
4. Durability. The Databricks WAL cache and the Anthropic bug-fix task both add what survives a crash, covered in the next sections.

Worked example: a senior candidate preparing for LinkedIn and Amazon

Start with LRU Cache, which is filed under both LinkedIn and Amazon. Implement get and put with the map and list, and write three tests: hit moves to head, put over capacity evicts the tail, and updating an existing cache key does not grow the size. Next, take the thread-safe follow-up and add one lock, then explain aloud why get must take the same lock as put (it mutates the list). Then do Weighted LRU Cache on the same class by replacing the entry count with a weight sum. Finish with the LRU debug variant: read a broken version and find where the list pointers and the map entries drift apart. That is four sessions on one codebase.

Our view: at senior level, be ready to state your invariants (map and list hold the same set of cache keys, size equals the sum of weights) and how you would prove them under concurrent callers. State the invariants before you write code, and check them after every operation in your tests.

Production systems often trade exactness for cost, and saying so shows you know the difference between the interview data structure and a real one. Redis's eviction documentation says its LRU algorithm "uses an approximation of the least recently used" keys. PracHub's caching guide notes that production systems may approximate LRU or LFU to reduce metadata and CPU cost.

Do you still need distributed-cache design?

Yes, but as vocabulary for your extensions, not as the main event. Only 2 of the 43 reported caching questions are system design, and the clearest example is Databricks' In-Memory KV Cache with WAL Log, reported in an onsite in 2026-06. Our take: caching also appears inside many larger design prompts that this count does not cover, so keep the theory, but rehearse it as follow-ups on a cache you have built in code.

The WAL cache is the one design prompt worth a full session if Databricks is on your list. Be ready to decide two things: when a write is acknowledged (before or after the log record is flushed), and how recovery replays the log to rebuild the in-memory map without double-applying a half-written record. Version the log record format from the start, because a follow-up that adds a field or compaction is then a short answer.

For the pattern questions that come up inside any caching discussion, know four and pick a default. Hello Interview's caching guide puts it plainly: "If you only remember one caching pattern for interviews, make it cache-aside." AWS describes lazy loading as populating the cache only when needed, at the cost of a miss penalty of three trips. AWS's ElastiCache guide says write-through updates the cache whenever data is written, and Hello Interview notes it still suffers from the dual-write problem. Write-behind makes writes fast but can lose data if the cache crashes before flushing, according to Hello Interview. AWS's ElastiCache guide says lazy loading tolerates stale data but survives empty nodes, while write-through keeps data fresh, and adding a TTL combines the advantages of both.

Our take: default to cache-aside with a TTL, name write-through only when reads after a write must be fresh, and mention write-behind only with a durable queue behind it. The extension that turns this into an interview answer is multiple instances. Hello Interview's caching guide points out that in-process caches are not shared, so when one instance updates or invalidates a value, the others will not know. That single sentence is the bridge from your LRU class to a multi-server design.

Our view on the rest of a distributed-cache answer: partition cache keys across nodes with consistent hashing so adding a node moves only a fraction of them, and treat your LRU class as the per-shard component that each node runs. Then decide whether a shard needs a replica, which costs memory and adds a second copy to invalidate, and how you would spread one hot key, for example by copying it to several shards or serving it from a small in-process tier.

Is debugging an existing cache a separate skill?

Treat it as its own drill. The bank names debug tasks directly, such as Anthropic's bug-fix task in the table above, so practise reading and fixing an existing cache separately from writing one. As a separate format trend, AI-assisted coding questions took 20% of caching-question links in 2025-Q4 and 31% in 2026-Q3, while object-oriented design fell from 68% to 46%. Coding (algorithm) rose from 0% to 23% over the same quarters.

These are shares, not totals: link totals by quarter mostly reflect how many write-ups were collected, so the quarterly totals are not a trend on their own. The AI-assisted share rose after 2025-Q4 and has held near 30% since, on small samples. If your loop includes an AI-assisted round, budget a timed session for it.

The reference shapes are concrete. Anthropic's In-Memory Cache: Bug-Fix + Durability was reported in an AI-assisted phone screen in 2026-07, and it is linked from 11 write-ups. Apple's AI-assisted phone screen in 2026-09 was LRU Cache itself. Our view: in both formats, show that you can build a mental model of unfamiliar code quickly and that you verify each fix with a test before moving on.

Our take: run the debug drill in three passes. First, state the invariants the code must hold. Second, write one failing test that breaks an invariant. Third, fix it and add the durability or eviction change the task asks for. If your loop allows an assistant, use it to read and test, and keep the invariants in your own words so you can defend every change.

What separates a strong caching answer from a correct one?

Correctness under failure, not hit rate. PracHub's guide says "Caching questions test whether you can turn a latency optimization into a complete reliability design." It lists the expectations as defining freshness, protecting the source of truth, choosing eviction from the workload, and keeping a cold cache from causing an outage. For each extension you build, state the freshness contract first.

The common failure modes, and what to say instead:

• Optimising hit rate first. PracHub calls optimizing hit rate before deciding whether a stale hit is correct a common interview mistake, and notes that a 95 percent hit rate does not prove safety because the remaining misses may be correlated. Say what a stale read costs before you quote a hit rate.
• Invalidating in the wrong order. PracHub's guide explains that deleting the cache before the database write lets a concurrent reader repopulate a stale entry before the write commits. One Medium author's write-up adds that the cache and the database share no atomic transaction, so a senior answer should discuss failure behavior rather than present one sequence as atomic. Invalidate after the commit, and say what happens if that delete fails.
• Ignoring the stampede. PracHub describes single-flight loading, where one request per cache key loads the value while the others wait, and says the lock needs a timeout and an owner token. TTL jitter keeps thousands of keys from expiring together, according to PracHub, but the Medium author notes jitter does not solve a stampede on a single extremely popular key.
• Missing the hot key. The same Medium author's write-up recommends watching per-key or per-partition traffic rather than total cache utilization. Name that metric whenever a follow-up concentrates traffic.
• Treating TTL as a constant. AWS's caching best-practices page suggests a TTL of a few seconds for fast-changing data such as comments or leaderboards, and gives online checkout as a case where the authoritative price is needed and caching may not fit. Tie each TTL to what the reader of that value can tolerate.
• Forgetting the cold cache. AWS's best-practices page states, "When (not if) cache nodes fail, those objects will no longer be in the cache." Every design needs a repopulation path that does not flatten the database.

Our take: in an implement-a-cache round, these points belong in the narration of each follow-up rather than in a separate design speech. When you add TTL, say what a stale hit costs; when you add a lock, say what happens to a concurrent writer; when you add a log, say what survives a crash.

What changes at senior and staff level?

The base question stays; the follow-ups shift. Candidate write-ups link these caching questions 81 times from candidates who reported a senior, staff-plus or manager level and 55 times from those who reported junior, new-grad or intern. LRU Cache itself is split evenly, 12 and 12, so seniors still see it. LRU Cache still carries the most senior-or-above links, while some smaller follow-up questions lean further senior; Weighted LRU Cache, with 2 of 7 links from senior-or-above candidates, does not lean senior.

These splits use each candidate's self-reported level and count links, not people. Timed Cache / Expiring Key-Value Cache leans 8 senior-or-above to 1 junior-or-below, and the Anthropic bug-fix task leans senior at 8 to 3. Three questions appear only in senior-or-above write-ups: Weighted Cache (7), Design and Implement an In-Memory Cache with Eviction and Memory Bound (3), and Debug a Transformer Implementation and Implement a KV Cache for Decoding (3). Coding (algorithm) caching links run 12 senior-or-above to 1 junior-or-below, and debugging links 8 to 3.

The OpenAI transformer question is the outlier for ML candidates: a coding (algorithm) question reported in a phone screen in 2026-09 that asks you to debug a transformer and implement a KV cache for decoding. If you are interviewing for an ML role there, practise it on the transformer KV cache page, and, in our view, expect the push to be on what the cache stores per decoding step and how its memory grows with sequence length.

Our view on what to prepare at senior level:

• Expiry and memory bounds. Add a TTL cache and the memory-bounded in-memory cache to your set, and be ready to explain lazy versus background expiry.
• Durability. Build one WAL-backed cache and walk a crash in the middle of a write.
• Concurrency. Defend the locking scheme you chose and name the contention it costs.

Our take: at senior level the base LRU is assumed, and the evaluation moves to how you extend it under failure and concurrency and how you explain those trade-offs. Volunteer the failure cases before the interviewer prompts for them, because in our view that is the clearest senior signal available in this round.

Our view on down-leveling: a correct LRU on its own earns little level signal in either round. The down-leveling risk sits in how you handle the second and third follow-up, especially durability and concurrency, and in whether you volunteer the trade-offs. Outside the coding rounds, the system design round and the project deep dive carry the rest of the level signal, so a caching story from your own work, with the invalidation bug you hit and how you fixed it, is worth preparing.

How should you decide what to prepare?

Match the prep to your loop rather than to a generic caching list. Most companies with the most caching questions report them as object-oriented design (see the company table), so LRU plus its follow-ups is the default. Add an AI-assisted debug drill, the WAL cache, or the transformer KV cache only when your target loop points there.

• Object-oriented design or coding round at LinkedIn, Amazon, Microsoft, Oracle, ByteDance or Netflix: LRU plus TTL, LFU, thread safety and weights.
• AI-assisted coding round (see the debugging section for the Anthropic and Apple examples): add timed practice debugging and extending an existing cache.
• Databricks or a system design round: add the durable key-value cache with a write-ahead log, plus the cache-aside, write-through and invalidation trade-offs.
• ML roles at OpenAI: add the transformer KV cache for decoding.

Our take: if you have only one week, skip the distributed-cache theory reading and spend it on the LRU ladder and one debug session. The theory is easier to pick up in an evening than fluent, tested cache code is.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-16 and cover 43 caching practice questions reported at 17 big-tech companies. They are candidate-reported questions reconstructed for practice, not any company's official question list. A question can be filed under several companies and reported in more than one round, so company and round tallies overlap. Level splits count write-up links by the level each candidate reported for themselves, and a link count is neither a count of distinct write-ups nor a measure of how often a company asks a question.

FAQ

What are the two main caching strategies?

In our view, lazy loading (cache-aside) and write-through are the two to lead with, and you should be ready to compare them. AWS's caching best-practices page calls lazy caching, also known as cache-aside, the most prevalent form of caching. AWS also says the two complement each other: lazy caching catches misses on reads, and write-through populates data on writes. In an interview, start with cache-aside plus a TTL, then add write-through for the values whose readers cannot tolerate staleness after an update.

What Redis questions come up in caching interviews?

In our view, eviction policy is the Redis knowledge the reported LRU and LFU questions draw on most directly. Redis's documentation describes allkeys-lru as evicting the least recently used keys and allkeys-lfu as evicting the least frequently used ones. The Redis documentation recommends allkeys-lru as a good default when you have no reason to prefer another policy. Under noeviction, Redis returns an error instead of evicting when new data needs memory. Know which policy fits your workload, and remember that Redis's LRU is an approximation.

Are these the caching questions companies officially ask?

No. They are questions candidates reported and that TrueInterview reconstructed for practice, so treat them as a guide to what to build first rather than a prediction of your exact prompt. The value is in the pattern across write-ups: one data structure, a small set of follow-ups, and a few company-specific durability tasks. A cache you can extend under a new requirement transfers to prompts that are not on any list.

How do you choose a TTL?

Choose it from how stale the reader of that value can afford to be, not from a round number. AWS's caching best-practices page recommends applying a TTL to all cache keys except those updated by write-through. One Medium author's write-up frames TTL as a business-consistency decision as much as a configuration value. In practice, give fast-changing feeds a TTL of seconds, give slow reference data a longer one with jitter, and keep authoritative reads such as a checkout price out of the cache.

Do junior candidates get different caching questions?

They share the base question but see fewer of the senior-leaning variants. LRU Cache is level-balanced, while Timed Cache, the Anthropic bug-fix task and Netflix's Weighted Cache lean senior or appear only in senior-or-above write-ups (see the senior section); Weighted LRU Cache does not. If you are junior or a new grad, make the base LRU and the thread-safe follow-up clean and well tested, and treat the durability tasks as stretch work for the final week.

Your practice plan

The target is narrow: one data structure, five or six reported follow-ups, and one or two company-specific tasks. This plan assumes about four evenings a week for three weeks while you work full time.

1. Week one, first two evenings: implement LRU Cache with a hash map and a doubly linked list, write the three invariant tests from the worked example, then add TTL expiry and LFU eviction as in ByteDance's TTL and LFU variant.
2. Week one, last two evenings: add one lock for the thread-safe follow-up, then change capacity to total weight for Weighted LRU Cache. Explain the contention cost and the oversized-item case aloud.
3. Week two, first evening: run the LRU debug variant under a timer using the three-pass drill: invariants, failing test, fix.
4. Week two, middle evenings: if you are senior or above, do Timed Cache and Weighted Cache, narrating each follow-up as described in the failure-modes section.
5. Week two, last evening: if your loop has an AI-assisted round, do In-Memory Cache: Bug-Fix + Durability under a timer; otherwise, repeat the debug drill on LRU Cache III.
6. Week three, first two evenings: build In-Memory KV Cache with WAL Log and walk a crash mid-write. Then prepare a short spoken explanation of cache-aside versus write-through and why you invalidate after the database commit.
7. Week three, last two evenings: run two mock rounds on variants you have not built yet, and have a partner change one requirement halfway, such as adding a second writer or a memory bound, so you practise extending rather than rewriting.

To check the company, round and month behind any question before you spend an evening on it, browse TrueInterview's question bank.

Sources

• TrueInterview question bank — caching at big-tech companies — counted 2026-10-16
• Key eviction | Docs — checked 2026-10-16
• Caching Interview Questions for Backend Engineers: Eviction, Stampedes, and Consistency | PracHub Knowledge Hub — checked 2026-10-16
• Caching for System Design Interviews | Hello Interview System Design in a Hurry — checked 2026-10-16
• Caching strategies for Memcached - Amazon ElastiCache — checked 2026-10-16
• Medium — checked 2026-10-16
• Caching Best Practices | Amazon Web Services — checked 2026-10-16

Last reviewed: 2026-10-16.