Apple LeetCode Questions: A Data-Backed Practice List

Apple publishes no LeetCode list. What the current Apple tag data shows, 17 problems worth practicing, and a worked LRU Cache answer.

Apple doesn't publish a list of LeetCode questions, and it doesn't run one standard interview: each team decides how it interviews. The best public signal for Apple LeetCode questions is a public GitHub repository that curates lists of problems by company; its lists look like LeetCode's company-tag data, though the repository does not name its source. In its October 2026 update, the six-month Apple list holds 64 problems, 49 of them Medium, and data-structure design problems such as LRU Cache, Design Hit Counter and Time Based Key-Value Store sit near the top. Practice the 17 problems below, work through the LRU Cache example, and give equal time to your target team's domain and to "Why Apple?", because at Apple those can matter as much as the code.

Why there is no real "Apple list"

The Apple careers pages we checked describe its teams and student programs but say nothing about interview steps. The clearest statements come from people inside the company. On Blind in December 2022, a user tagged as working at Apple wrote that "Apple doesn't have a standard hiring process" and that it is up to the team and hiring manager; their own experience in a tech role was much like other companies' plus a take-home project. Another Apple-tagged reply in the same thread put a typical tech screen at one or two LeetCode Mediums plus some behavioral questions.

Interviewing.io's guide to Apple, which says it is based on conversations with Apple interviewers in its community, describes the same picture in more detail:

• You apply to a team, not the company, and Apple lets candidates interview with several teams at once.
• Formats differ by team. Some teams have you write a program on your own laptop in your own IDE, some spend a whole round on a technology the team works with, and others "do medium-ish LeetCode-style questions". One team that wrote Java and did a lot of concurrency work ran a full round on concurrency in Java.
• Phone screens usually run 30 minutes to an hour and often include coding, though some are hiring-manager screens that mix behavioral and coding questions; some teams use CoderPad. Some hiring managers add a take-home assignment.
• Behavioral rounds carry weight. The guide says they matter more than the coding rounds and that you will be asked "Why Apple?" in some form.
• Interviewers have no formal training, and Apple sometimes cuts an onsite short when a candidate is clearly below the bar.

So treat any "most asked" list as a map of where LeetCode-style rounds tend to go, not a promise of what your team will ask. If your recruiter says the team does LeetCode-style rounds, the list below is a good use of time. If the team does laptop exercises or domain deep dives, it is warm-up.

What the Apple list data shows right now

The repository splits Apple's tagged problems by how recently they were reported. In the update committed on 21 October 2026:

• Window — Problems — Easy — Medium — Hard
• Last 30 days — 4 — 1 — 3 — 0
• Last 3 months — 26 — 4 — 19 — 3
• Last 6 months — 64 — 8 — 49 — 7
• Older than 6 months — 227 — 56 — 137 — 34
• All time — 282 — 68 — 170 — 44

Four things stand out when you compare the windows.

Design problems are a bigger share lately. Twelve of the 64 six-month problems carry LeetCode's Design topic (about 19%), against 33 of 282 all time (about 12%). These are not system design interviews. They are "build this class" problems: a cache, a hit counter, a versioned array. They test whether you can pick two data structures that work together and keep them consistent.

The list is stable. 21 of the 26 three-month problems also appear in the older-than-six-months list. Older practice still counts.

A few newcomers lead. Minimum Cost to Hire K Workers (Hard) tops both the three-month and six-month lists but does not appear in the older list. Meeting Rooms III (Hard) is also new. Both are heap problems, so if heaps are a weak spot, fix that first.

The "frequency" number is relative. In every list the top problem scores 100 and the rest are scaled against it. The repository does not explain how the score is calculated, so read it as a ranking, not a probability, and expect the 30-day list, with four problems, to swing a lot from month to month.

That last point matters because percentage figures without a date go stale fast. An earlier version of this page cited Maximum Profit in Job Scheduling at "100% frequency" and Sum Root to Leaf Numbers at 91%. Neither appears in any of the current Apple lists. If a page quotes Apple frequencies without saying when the data was pulled, assume it is old.

The practice set: 17 problems

All 17 are in the six-month Apple list, and 15 of them also appear in the older list. They are grouped by the pattern they train. All are free on LeetCode except Design Hit Counter, which needs Premium.

• Pattern — Problem — Difficulty
• Class design — 146. LRU Cache — Medium
• Class design — 981. Time Based Key-Value Store — Medium
• Class design — 362. Design Hit Counter (Premium) — Medium
• Class design — 1146. Snapshot Array — Medium
• Class design — 380. Insert Delete GetRandom O(1) — Medium
• Arrays and intervals — 56. Merge Intervals — Medium
• Arrays and intervals — 121. Best Time to Buy and Sell Stock — Easy
• Sliding window — 3. Longest Substring Without Repeating Characters — Medium
• Sliding window — 713. Subarray Product Less Than K — Medium
• Hashing — 49. Group Anagrams — Medium
• Graphs — 210. Course Schedule II — Medium
• Graphs — 127. Word Ladder — Hard
• Graphs — 200. Number of Islands — Medium
• Dynamic programming — 198. House Robber — Medium
• Dynamic programming — 1143. Longest Common Subsequence — Medium
• Heaps — 857. Minimum Cost to Hire K Workers — Hard
• Heaps — 2402. Meeting Rooms III — Hard

Start with the five class-design problems. They are the clearest pattern in recent data, and they reward a skill the other problems don't: explaining an interface and its invariants before writing code.

Worked example: LRU Cache

LRU Cache is first in the 30-day and all-time Apple lists and second in the six-month list. The task: build a cache with a fixed capacity. get(key) returns the value or -1. put(key, value) inserts or updates, and if the cache is over capacity, it evicts the least recently used key. Both must run in O(1) average time.

What the interviewer is testing. A hash map gives O(1) lookup but no order. A list gives order but slow lookup. The answer is both: a map from key to node, and a doubly linked list ordered from most to least recently used. Say that out loud before you code; it is most of the solution.

class Node:
    def __init__(self, key=0, val=0):
        self.key, self.val = key, val
        self.prev = self.next = None

class LRUCache:
    def __init__(self, capacity: int):
        self.cap = capacity
        self.map = {}                            # key -> node
        self.head, self.tail = Node(), Node()    # sentinels; head.next is newest
        self.head.next, self.tail.prev = self.tail, self.head

    def _remove(self, node):
        node.prev.next, node.next.prev = node.next, node.prev

    def _add_front(self, node):
        node.prev, node.next = self.head, self.head.next
        self.head.next.prev = node
        self.head.next = node

    def get(self, key: int) -> int:
        if key not in self.map:
            return -1
        node = self.map[key]
        self._remove(node)
        self._add_front(node)                    # a read counts as use
        return node.val

    def put(self, key: int, value: int) -> None:
        if key in self.map:
            self._remove(self.map[key])
        node = Node(key, value)
        self.map[key] = node
        self._add_front(node)
        if len(self.map) > self.cap:
            lru = self.tail.prev                 # oldest sits before the tail
            self._remove(lru)
            del self.map[lru.key]

The two sentinel nodes mean _remove and _add_front never check for an empty list, which removes the most common source of bugs. Storing the key inside each node is what lets you delete the evicted entry from the map.

Mistakes that cost the round:

• Forgetting that get must move the node to the front. The cache then evicts keys that were just read.
• Evicting before inserting when the key already exists. Updating a key never grows the cache, so it should never evict.
• Removing the node from the list but not from the map, or the other way round. Say the invariant ("every key in the map has exactly one node in the list") and check it after each operation.

Follow-ups to rehearse. Can you use Python's OrderedDict or Java's LinkedHashMap? Ask before you do: the linked list is the point of the problem, so be ready to build it yourself. How would you make it safe for several threads? A single lock around get and put is the honest first answer; then discuss why reads also need it here (they reorder the list). What if entries should also expire after a time limit? That is where Time Based Key-Value Store and Design Hit Counter come in. LFU Cache, which is also in the six-month list, is the harder sibling.

A second design problem: Time Based Key-Value Store

set(key, value, timestamp) stores a value; get(key, timestamp) returns the value with the largest timestamp at or before the one given, or an empty string. LeetCode guarantees that timestamps passed to set are strictly increasing, so appending keeps each key's list sorted and get becomes a binary search:

from bisect import bisect_right
from collections import defaultdict

class TimeMap:
    def __init__(self):
        self.times = defaultdict(list)   # key -> timestamps, increasing
        self.vals = defaultdict(list)    # key -> values, same order

    def set(self, key: str, value: str, timestamp: int) -> None:
        self.times[key].append(timestamp)
        self.vals[key].append(value)

    def get(self, key: str, timestamp: int) -> str:
        i = bisect_right(self.times[key], timestamp)
        return self.vals[key][i - 1] if i else ""

The follow-up worth preparing: what if timestamps can arrive out of order? Appending no longer keeps the list sorted, so you need a sorted structure (a balanced tree, or a sorted list with insertion cost you can explain). Pointing out which guarantee your solution depends on is exactly the habit a design problem is checking.

How to prepare for the rest of the loop

Ask your recruiter what format the team uses. Since Apple teams run their own interviews, the most useful question you can ask is whether the coding rounds are LeetCode-style, on your own laptop, or deep dives into the team's technology. Then weight your preparation accordingly.

Go deep in the team's language. The Java concurrency round above is the kind of thing a job description hints at. If the role lists Swift, C++ or Java, review that language's concurrency and memory model, not only algorithms.

Practice design problems as API conversations. For each class-design problem, state the interface, the invariants and the complexity before coding, and have an answer ready for "what if two threads call this?" Interviewing.io notes that Apple interviewers like to hear about reliability in system design rounds; the same instinct helps in class design.

Time yourself. Phone screens run 30 minutes to an hour, and one Apple-tagged Blind user described one or two Mediums in a screen, so aim to finish a Medium, with a hand-run test case, in about 25 minutes.

Prepare "Why Apple?" as seriously as the code. Tie it to the team's product and something you have built, not to owning an iPhone. Our Apple question bank has behavioral questions to practice with, and Apple's interview process covers the stages around the coding rounds.

If you want a second opinion on your practice solutions, Verve's Coding Interview Copilot captures a question from your screen and returns a solution, with quick actions such as Optimize, Edge Case and Complexity. Solve the problem yourself first, then compare: the value is in seeing the edge case you missed.

To compare Apple with other big-tech coding loops, see our guides to Amazon LeetCode interview questions and Google LeetCode interview questions.

Sources

• Apple careers pages (teams and student programs; no interview steps described): https://www.apple.com/careers/us/work-at-apple/teams.html , https://www.apple.com/careers/us/work-at-apple/students.html
• Blind thread, December 2022 (Apple-tagged replies: no standard hiring process, up to the team and hiring manager, take-home project; tech screen of one or two LeetCode Mediums plus behavioral): https://www.teamblind.com/post/interviewing-with-apple-nfvuy1as
• Interviewing.io, Apple interview guide (based on Apple interviewers in its community; apply to a team; concurrent team interviews; laptop/IDE, deep-dive and "medium-ish LeetCode-style" formats; Java concurrency round; 30-to-60-minute phone screens; CoderPad; take-homes; behavioral rounds more important; "Why Apple?"; no formal interviewer training; interviews cut short; reliability in system design): https://interviewing.io/apple-interview-questions
• Apple LeetCode tag lists by time window, difficulty, topics and relative frequency (repository describes itself as curated lists of LeetCode questions grouped by company): https://github.com/liquidslr/leetcode-company-wise-problems/tree/main/Apple
• Six-month list read for counts, Design-topic share and the practice set: https://raw.githubusercontent.com/liquidslr/leetcode-company-wise-problems/main/Apple/3.%20Six%20Months.csv
• Commit dates for the Apple lists (latest update 21 October 2026): https://github.com/liquidslr/leetcode-company-wise-problems/commits/main/Apple
• LRU Cache statement, O(1) requirement and example (read from LeetCode's public problem data; the code above was run against the example): https://leetcode.com/problems/lru-cache/
• Time Based Key-Value Store statement and strictly increasing timestamps (read from LeetCode's public problem data; code run against the example): https://leetcode.com/problems/time-based-key-value-store/
• Difficulty and free or Premium status of the other practice problems (read from LeetCode's public problem data): https://leetcode.com/problems/design-hit-counter/ , https://leetcode.com/problems/snapshot-array/ , https://leetcode.com/problems/insert-delete-getrandom-o1/ , https://leetcode.com/problems/merge-intervals/ , https://leetcode.com/problems/best-time-to-buy-and-sell-stock/ , https://leetcode.com/problems/longest-substring-without-repeating-characters/ , https://leetcode.com/problems/subarray-product-less-than-k/ , https://leetcode.com/problems/group-anagrams/ , https://leetcode.com/problems/course-schedule-ii/ , https://leetcode.com/problems/word-ladder/ , https://leetcode.com/problems/number-of-islands/ , https://leetcode.com/problems/house-robber/ , https://leetcode.com/problems/longest-common-subsequence/ , https://leetcode.com/problems/minimum-cost-to-hire-k-workers/ , https://leetcode.com/problems/meeting-rooms-iii/
• Coding Copilot (screen capture, solution, quick actions): https://docs.vervecopilot.com/features/coding-copilot