← XPeng Interview Insights

XPeng·Software Engineer·Technical Phone Screen·Intermediate

Intermediate
May 2026

Summary

XPeng data engineer interview, got a classic LRU cache problem but with a relaxed constraint where they said a linked list wasn't required. Pretty reasonable as far as coding rounds go.

Questions Asked (1)

Q1

Build an in-memory key-value store with a fixed capacity that evicts the least recently used key when full. It needs to support get and put operations, where both accessing and updating a key count as recent use. A hash map plus a plain list is acceptable instead of a linked list.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs
Author's notes

I'd done LRU before so the concept wasn't the issue.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements: fixed capacity, O(1) get and put, and LRU eviction. Then propose a hash map for O(1) access and a doubly linked list (or a list with a timestamp/order field) to track recency, explaining how get and put update the order. Walk through the logic for eviction when capacity is exceeded, and discuss trade-offs of using a list versus a linked list.

Pro tip: Mention that using a plain list with a timestamp or order field can simplify implementation but may degrade to O(n) for updates; a doubly linked list ensures O(1) but requires careful pointer manipulation. Also, consider thread-safety if the store might be used concurrently.

1. Clarify requirements and constraints

Confirm that both get and put count as recent use, and that eviction happens when capacity is exceeded. Ask about expected operation frequency and whether thread-safety is needed.

2. Choose data structures

Propose a hash map for O(1) key lookup and a doubly linked list (or a list with order tracking) to maintain recency. Explain why a singly linked list or plain array is insufficient for O(1) updates.

3. Define operations and update recency

Describe how get moves the accessed node to the front (most recent) and returns the value. For put, if key exists, update value and move to front; if new, insert at front and evict the least recent (tail) if capacity is full.

4. Handle edge cases and eviction

Discuss eviction when capacity is reached, handling of null values, and behavior when capacity is zero or one. Mention that eviction should remove the least recently used key from both the map and the list.

5. Analyze complexity and trade-offs

State that both get and put are O(1) with a doubly linked list, but using a plain list may be O(n) for updates. Discuss trade-offs: simplicity vs. performance, and potential concurrency issues.

Key Points to Mention

  • Hash map provides O(1) average-case lookup for keys.
  • Doubly linked list maintains recency order with O(1) insertion, deletion, and move-to-front operations.
  • Both get and put must update recency: get moves the node to the front; put updates or inserts at the front.
  • Eviction removes the tail node (least recently used) when capacity is exceeded.
  • Using a plain list with timestamps can simplify code but may lead to O(n) updates; a linked list is more efficient.
  • Consider thread-safety if the store is accessed concurrently, e.g., using locks or concurrent data structures.

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