Generated by Codex with gpt-5

Selected problem: Distributed File Storage

Scope: Design a cloud file storage and sync service that stores large files durably, keeps file and folder metadata consistent, and propagates changes across devices and shared workspaces.

Problem framing

This is the classic Dropbox / Google Drive interview problem. Grokking and Alex Xu both push the same core split early: separate the metadata and synchronization plane from the binary file storage plane. DDIA adds the more durable framing: the namespace, versions, and permissions are the system of record, while notifications, sync cursors, search indexes, thumbnails, and audit views are derived data built from change streams.

Generated by Codex with gpt-5

Selected problem: Distributed Job Scheduler

Scope: Design a multi-tenant scheduler that supports one-off and recurring jobs, dispatches them reliably to worker fleets, and gives operators clear control over retries, overlap, and execution history.

Problem framing

This interview problem sits between a cron service and a workload orchestrator. Grokking and Alex Xu repeatedly lean on the same building blocks across crawler, notification, and media-processing systems: stateless control planes, durable metadata, queues, workers, and explicit retry paths. DDIA adds the harder part: lease-based coordination, partition ownership, hot-spot avoidance, and clear delivery semantics.

Generated by Codex with gpt-5

Selected problem: Metrics/Logging Pipeline

Scope: Design a centralized telemetry pipeline that ingests high-volume metrics and logs from many services, powers near-real-time dashboards and alerts, and retains searchable history without letting the write path collapse under bursts.

Problem framing

Grokking and Alex Xu both push the same interview habit first: clarify scope before naming technology. Here the system is not “the dashboard product”; it is the backend write and query path behind centralized observability.

Generated by Codex with gpt-5

Selected problem: Ride-Sharing Dispatch

Scope: Design the real-time backend that ingests rider requests and driver location updates, finds good matches within seconds, assigns exactly one driver to a rider, and keeps the trip state and live map updated until completion.

Problem framing

This is the classic “design Uber/Lyft dispatch” interview problem: a city-scale marketplace where the hard parts are not just finding a nearby driver, but doing so with fresh-enough location data, realistic ETAs, strong assignment correctness, and graceful handling of retries, timeouts, cancellations, and partial failures.

Generated by Codex with GPT-5

Quick facts

• Difficulty: HARD
• Problem: Split Array Largest Sum
• Main tags: Array, Binary Search, Dynamic Programming, Greedy, Prefix Sum

What the problem is really asking

The input array must be cut into exactly k non-empty, contiguous pieces. Each cut creates one subarray, and the score of a split is the largest subarray sum that appears anywhere in that split.

Generated by Codex with GPT-5

Quick facts

• Difficulty: MEDIUM
• Problem: Single Element in a Sorted Array
• Main tags: Array, Binary Search

What the problem is really asking

The array is sorted, and every value appears exactly twice except for one value that appears once.

If the array were not sorted, the quickest idea would be XOR: identical values cancel out, so the final XOR is the answer. That works in O(n) time and O(1) space.

Generated by Codex with GPT-5.4

Difficulty: MEDIUM
Problem: Sort an Array

Problem gist

The task is deliberately simple to state: given an integer array, return the same values in ascending order. The interview signal is not whether someone knows Python’s built-in sort, but whether they can implement a sorting strategy with clear time and space guarantees.

Generated by Codex with gpt-5

Selected problem: Chat/Messaging System

Scope: Design a text-first chat platform for one-to-one and small-to-medium group conversations with presence, multi-device sync, offline delivery, and durable message history.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#chat-system

Problem framing

This is the classic interview problem of designing a real-time chat system without over-promising impossible guarantees. Grokking and Alex Xu both frame the core problem similarly: keep message delivery low-latency, keep history durable, handle offline users, and make multiple devices converge on the same conversation state. DDIA adds the deeper constraint: ordering, replication, partitioning, and delivery semantics must be chosen deliberately instead of hand-waving toward “global consistency.”

Generated by Codex with gpt-5

Selected problem: News Feed

Scope: Design a personalized feed service that lets users publish posts, reads recent and ranked posts from accounts they follow, and keeps feed retrieval fast while handling fanout skew, stale caches, media, and eventual consistency.

Also see https://wiki.derricklin.net/software-development/System%20Design%20Interview/#news-feed

Problem framing

This is the classic “design a Facebook News Feed / Twitter timeline / Instagram home feed” interview problem. Grokking and Alex Xu frame it as two linked flows: feed publishing, where a new post enters storage and is propagated to followers, and feed retrieval, where a user gets a fast, paginated, hydrated list of feed items. DDIA’s Twitter home-timeline example explains the central tradeoff: doing more work at write time makes reads fast, but high-follower authors create fanout storms; doing more work at read time avoids write amplification, but every feed read becomes an expensive merge.

Generated by Codex with gpt-5

Selected problem: Search Autocomplete

Scope: Design a low-latency autocomplete service that returns top suggestions for a typed prefix, learns from query activity over time, and handles hot prefixes, moderation, and multilingual growth without rebuilding everything on every keystroke.

Problem framing

This is the classic “design Google search suggestions” or “typeahead” interview problem. Alex Xu frames it around a brutally simple user-facing requirement: every keystroke can trigger a request, so suggestion reads must be extremely fast. Grokking’s interview style also applies cleanly here: clarify prefix-only versus infix matching, top-K size, language scope, freshness needs, and latency targets before arguing about data structures. The interview answer usually starts with a trie or prefix tree, but DDIA adds the more durable framing: autocomplete is a derived read model built from query logs, aggregation, filtering, and ranking pipelines, so the real design question is how to keep that read model fresh, cheap, and rebuildable.