Meta Software Engineer Interview Prep Guide

Focus most on the immediate Meta phone-screen path: dynamic programming refresh, arrays/prefix sums, graph/grid BFS-DFS, and binary-tree traversal patterns, because you called out DP rust and your phone screen is Friday. The rest is review-level rather than from-scratch: BST/LCA, linked-list/cache patterns, and banking-ledger prompts stay brief because you did not flag them and skipped concept ratings default to solid. For Meta-specific prep, this plan highlights social feed ranking/fanout, leaderboards, real-time messaging, and large-scale storage/search designs. Given onsite is next week, spend the largest blocks on Technical Screen and Onsite sections first, then use Take-home content as backup review.

Technical Screen — 54 min

Coding & Algorithms

• Dynamic Programming Patterns Refresher (Focus) — covered in depth under Take-home Project below.

• Arrays, Intervals, Sliding Windows, And Prefix Sums (Focus) — covered in depth under Take-home Project below.

• Graph, Grid, BFS/DFS, And Union-Find (Focus) — covered in depth under Onsite below.

• Binary Tree Traversals, Vertical Order, And Views (Focus) — covered in depth under Take-home Project below.

• Top-K, Heaps, Quickselect, And Frequency Analysis — covered in depth under Take-home Project below.

• String Parsing, Palindromes, And Normalization — covered in depth under Take-home Project below.

• Linked Lists, Pointers, Caches, And In-Memory Stores (Light review) — covered in depth under Take-home Project below.

System Design

• Meta Social Feed Ranking And Fanout (Focus) — covered in depth under Onsite below.

• Leaderboards And Real-Time Ranking (Focus) — covered in depth under Take-home Project below.

Onsite — 58 min

Coding & Algorithms

• Dynamic Programming Patterns Refresher (Focus) — covered in depth under Take-home Project below.

• Arrays, Intervals, Sliding Windows, And Prefix Sums (Focus) — covered in depth under Take-home Project below.

Focus area — Meta asks many grid and traversal problems; no solved-signal is present, so practice visited-state handling under time pressure.

What's being tested

These problems test graph modeling from strings, grids, and matrices, then choosing the right traversal: BFS for shortest path, DFS for connected components/topological ordering, and memoized DFS for DAG-style dynamic programming. Interviewers are probing correctness on edge cases, complexity discipline, and clean implementation under Meta-style time pressure.

Patterns & templates

• Grid BFS shortest path — use deque, mark visited on enqueue, explore 4 or 8 directions; O(mn) time and space.

• Island counting — scan every cell, launch dfs(r,c) or iterative stack on unvisited land; mutate grid or maintain visited.

• Longest increasing path — model matrix as DAG by value order; dfs(r,c) with memo[r][c] gives O(mn).

• Topological sort for unknown alphabet — build directed edges from first differing chars, then use in_degree + queue; detect cycles.

• Custom lexicographic validation — map char -> rank, compare adjacent words only; handle prefix invalid case like "abc" before "ab".

• Union-Find alternative for components — find, union, path compression, union by rank; useful when connections are streamed or repeated.

• Sparse representation — for sparse dot product, store {index: value} or sorted pairs; iterate over smaller map for O(min(k1,k2)).

Common pitfalls

Pitfall: Marking grid nodes visited only when popped from BFS can enqueue the same cell many times and distort shortest-path logic.

Pitfall: In alien dictionary, adding constraints from every character position is wrong; only the first differing character between adjacent words matters.

Pitfall: Recursive DFS can hit recursion limits on large grids; mention iterative stack or recursion-limit handling if dimensions are large.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

• Binary Tree Traversals, Vertical Order, And Views (Focus) — covered in depth under Take-home Project below.

• Top-K, Heaps, Quickselect, And Frequency Analysis — covered in depth under Take-home Project below.

• String Parsing, Palindromes, And Normalization — covered in depth under Take-home Project below.

• Linked Lists, Pointers, Caches, And In-Memory Stores (Light review) — covered in depth under Take-home Project below.

System Design

Focus area — Meta-specific design focus: model feed generation, ranking signals, fanout-on-write/read, freshness, privacy filtering, and scale tradeoffs.

What's being tested

Interviewers are probing a candidate’s ability to design a large-scale social feed that balances latency, cost, and freshness under heavy skew. Expect to justify a concrete fanout strategy, storage model, caching, and operational controls (rate-limiting, backpressure, SLAs). The interviewer wants clear tradeoffs, capacity math, and handling of hotspot users and failure modes — not a perfect ML ranking model.

Core knowledge

• Push-based fanout: precompute timelines by pushing each update to all followers; write cost ≈ W * F where W is writes/sec and F is average followers; read cost is O(1). Great for low-read-latency but high write amplification and storage.

• Pull-based fanout: compute feed on read by fetching recent posts from followees; write cost O(W), read cost ≈ O(following * candidate_cost). Better storage, higher read latency and CPU at query time.

• Hybrid fanout: combine push for regular users and pull for celebrity accounts (heavy hitters) — reduces write amplification while keeping reads fast for most users.

• Timeline vs. activity log: store a per-user timeline store (fast reads) and a global activity log (append-only, source-of-truth for recompute). Timelines are denormalized and cheaper to serve at p99.

• Ranking pipeline: two stages — candidate generation (fast retrieval, e.g., recent posts, social graph signals) and scoring (ML model + heuristics). Precompute features where possible; keep scoring stateless for sharding.

• Storage choices & tradeoffs: use Cassandra/HBase/Scylla for high-write per-key timelines, MySQL for control metadata, S3 for cold archives, Redis or memcached for hot timeline caching. Consider compaction and tombstone costs.

• Capacity math and SLAs: compute ops and storage: writes/sec_total = W * F_push; storage_bytes ≈ avg_entry_size * followers * posts_retained. Target p99 read latency and budget costs per write/read.

• Handling skew & hotspots: detect users with follower_count >> mean; route their updates to on-demand pipelines, sharded fanout workers, or materialize only top-K items per follower.

• Consistency and freshness: eventual consistency is acceptable; strong consistency is expensive. Define freshness S (e.g., 1–5s) and design streaming/batching windows to meet it.

• Backpressure and rate-limiting: burst control on ingestion, per-user throttles, queueing (e.g., Kafka partitions) and graceful degradation (serve older cached timeline).

• Operational concerns: monitor p99 latencies, queue lag, write amplification, storage growth, and error budgets; plan for fanout backfills and replay from activity logs.

Worked example — "Design a news feed system that supports ranking and fanout"

Clarify requirements first: target users U, writes/sec W, average followers F, acceptable read p99 (e.g., <50ms), freshness requirement, retention window, and hot-account follower threshold. Organize the answer into three pillars: ingestion & fanout, storage & serving, and ranking & freshness. For ingestion, propose a hybrid fanout: push updates to timelines for users with follower_count < T (threshold), and keep celebrity posts in the activity log for pull-time candidate generation. For storage, use partitioned Cassandra tables keyed by user_id with timeline shards, and a Redis hot-cache for top-K recent items; explain compaction and TTL to control storage. For ranking, describe candidate generation from timeline + recent celebrity pulls, then a stateless scoring service that fetches precomputed features; flag the tradeoff: pushing reduces read latency but multiplies storage and write IOPS, while pulling saves writes at cost of read CPU and higher p99. Explicitly call out the capacity equation (writes_total = W_push * avg_followers_push) and a plan for sharding fanout workers by user_id. Close with "if more time": discuss cache invalidation, A/B experiment hooks, and how to backfill when ranking model changes.

A second angle — "Serve personalized feed on-demand with strict freshness for interactive UI"

This reframes priorities: reads are latency-sensitive and freshness <1s, so a pure pull model may violate SLOs. Propose a hybrid that precomputes only high-relevance candidates (e.g., friends, messages) and pulls lower-relevance or celebrity posts at read time. Use Kafka for near-real-time streams to keep a recent window (e.g., last 1,000 items) in an in-memory store, enabling sub-second freshness without pushing to all followers. Discuss caching partial ranked results per device-session to amortize repeated UI refreshes. Emphasize differences: read CPU and cache locality are now first-class concerns; you must dimension on read QPS and provision ephemeral state sharded by session or user.

Common pitfalls

Pitfall: Ignore skew and dimension by averages.
Designs that use average follower counts fail catastrophically when a few celebrities dominate writes; always show how hot accounts will be isolated (hybrid, sharding, rate-limits).

Pitfall: Treat ranking as only an ML problem.
Focusing solely on model quality without discussing candidate generation, precomputed features, and feature freshness leaves the system unservable at scale.

Pitfall: Not clarifying SLAs and cost constraints early.
Saying "low latency" without a quantifiable target prevents meaningful tradeoffs; state p99/p50 targets and a per-request cost or budget constraint.

Connections

This topic naturally pivots to stream processing (e.g., Kafka + stream processors), distributed caching and eviction policies, and backfill/replay strategies using append-only logs. Interviewers may also move toward SLO design and operational runbooks for incident response.

Further reading

• The Tail at Scale — foundational paper on latency distributions and design for p99 resiliency.

• Designing Data-Intensive Applications (Martin Kleppmann) — strong coverage of storage models, replication, and stream processing tradeoffs.

Practice questions

• Leaderboards And Real-Time Ranking (Focus) — covered in depth under Take-home Project below.

Behavioral & Leadership

Focus area — Onsite is next week and no behavioral practice signals are present, so prepare concise Meta-style ownership and conflict stories.

What's being tested

Meta behavioral interviews for Software Engineers probe whether you can create forward progress when ownership is unclear, priorities shift, or people disagree. The interviewer is not looking for “I worked hard”; they are testing judgment under ambiguity, technical ownership, conflict resolution, and whether you can turn failure or feedback into better engineering behavior. Strong answers show how you clarified constraints, made tradeoffs explicit, influenced without authority, protected system quality, and learned in a way that changed future execution. Meta cares because engineers often operate in large, fast-moving codebases where cross-team dependencies, legacy systems, launch pressure, and incomplete requirements are normal.

Core knowledge

• STAR-L framing is the baseline: Situation, Task, Action, Result, Learning. For Meta, the “Action” section should be the longest and include concrete engineering moves: design review, rollout plan, debugging path, ownership boundary, or tradeoff analysis.

• Ownership means driving the outcome, not personally doing every task. A strong SWE story distinguishes between what you owned directly—API design, migration plan, service reliability, code review quality—and what you influenced through partner teams, escalation, or written alignment.

• Ambiguity management starts by reducing unknowns into decisions. Good clarifying questions include: “What is the user-visible failure?”, “What is the deadline tied to?”, “What correctness or latency bar matters?”, “Who owns upstream/downstream systems?”, and “What happens if we do nothing?”

• Conflict resolution should be anchored in technical evidence, not personality. Instead of “the other engineer was wrong,” explain the competing proposals, such as synchronous RPC versus async queue, monolith patch versus service boundary, or fast launch versus reliability hardening, then show how you evaluated risks.

• Tradeoff language is critical. For example, “I chose a feature-flagged incremental rollout over a full rewrite because it reduced blast radius, even though it temporarily increased code complexity.” Meta interviewers listen for explicit cost-benefit reasoning, not hindsight-perfect decisions.

• Escalation is not failure when used responsibly. A mature engineer first aligns facts, documents options, and seeks peer review; escalation to a tech lead or manager is appropriate when impact, deadline, or ownership remains unresolved after reasonable attempts.

• Cross-team collaboration often involves dependency risk. Strong examples mention interface contracts, API versioning, rollout sequencing, backwards compatibility, migration ownership, and fallback behavior. Avoid drifting into program management; keep the focus on engineering decisions and execution.

• Failure stories should include a real mistake and a changed behavior. “The launch slipped because another team was late” is weak. Better: “I underestimated integration risk, so I now create an integration milestone before feature-complete and add contract tests around shared APIs.”

• Feedback receptivity is judged by behavior change, not agreement. If leadership disagreed with your approach, show how you separated intent from wording, asked for concrete examples, tested the feedback against outcomes, and adjusted your communication or technical approach.

• Impact measurement for SWE behavioral answers should use engineering and user-facing signals: `p95` latency, error rate, crash-free sessions, on-call pages, deployment frequency, rollback rate, migration completion, code review cycle time, or reduction in manual operations.

• Bias toward action does not mean reckless execution. A good Meta-style answer shows you made a reversible decision when possible, used feature flags or staged rollout, instrumented key paths, and set a checkpoint to revisit the decision with fresh data.

• Learning loop should be operationalized. Mention artifacts like postmortems, runbooks, design docs, regression tests, dashboards, code ownership updates, or review checklists. The strongest endings show how the lesson prevented a later bug, outage, delay, or misalignment.

Worked example

For “Describe an ambiguous project you handled,” a strong candidate would frame the first 30 seconds by stating the context, the unknowns, and the stakes: “I was asked to improve reliability for a service with rising `p99` latency, but there was no clear owner, no agreed target, and several suspected causes.” They would clarify assumptions: whether the ambiguity was technical, organizational, or requirement-driven; what success metric mattered; and what constraints existed around launch dates or backward compatibility. The answer skeleton should have four pillars: first, how they scoped the ambiguity; second, how they gathered evidence; third, how they aligned stakeholders; fourth, how they delivered incrementally.

A strong story might describe creating a short design note that listed candidate causes, owners, risks, and a proposed phased plan. The candidate could explain that they compared two options: a broad rewrite of the request path versus a narrower fix around a known cache-miss pattern. The explicit tradeoff: the rewrite might have produced a cleaner architecture, but the narrower fix was safer because it could be guarded by a feature flag, rolled out to 5%, then 25%, then 100%, and measured using `p95`/`p99` latency and error rate. They should also mention how they communicated uncertainty: “I told the team this would not solve every latency issue, but it would validate whether this path contributed materially to tail latency.” A good close would be: “If I had more time, I would have added earlier load testing and documented ownership for the dependency so the next incident had a clear responder.”

A second angle

For “Share different perspective from leadership feedback,” the same ownership principle applies, but the emphasis shifts from ambiguity in the work to ambiguity in interpersonal interpretation. The candidate should avoid sounding defensive; the goal is to show they could disagree with feedback while still extracting a useful signal. For example, leadership might say, “You are moving too slowly,” while the engineer believes they were protecting reliability during a risky migration. A strong answer would separate the facts from the label: they could ask what signals created that perception, show the risk analysis behind their rollout plan, and then adjust by communicating milestones more visibly. The lesson is not “I convinced leadership I was right”; it is “I learned that good technical judgment still needs proactive communication.”

Common pitfalls

Pitfall: Giving a generic teamwork story with no engineering substance.

A weak answer says, “I scheduled meetings, listened to everyone, and we compromised.” That sounds cooperative but not senior enough for a SWE interview. A better answer names the technical disagreement, such as data consistency versus availability, client-side versus server-side validation, or short-term patch versus long-term migration, then explains how you resolved it.

Pitfall: Presenting conflict as a personality problem.

Avoid “the other team was difficult,” “my manager did not understand,” or “leadership kept changing requirements.” Interviewers want evidence that you can operate inside messy organizations without blame. Reframe the issue as misaligned incentives, unclear ownership, insufficient data, or different risk tolerance, then show how you created alignment.

Pitfall: Ending with impact but no learning.

Many candidates finish with “we launched successfully” or “the bug was fixed.” For ownership and growth questions, that is incomplete. Add what changed afterward: a new pre-launch checklist, better design review practice, improved alerting, earlier dependency mapping, or a personal habit like writing decision logs for ambiguous projects.

Connections

Interviewers may pivot from this area into system design tradeoffs, especially if your story involves reliability, migrations, APIs, or scaling. They may also ask follow-ups on debugging, incident response, code quality, technical influence, or prioritization under constraints, so prepare stories that can go one layer deeper technically.

Further reading

• Crucial Conversations — Practical framework for handling disagreement without avoiding the real issue.

• The Staff Engineer’s Path — Strong treatment of technical leadership, influence without authority, and operating through ambiguity.

• Google SRE Book: Postmortem Culture — Useful model for discussing failure, accountability, and learning without blame.

Practice questions

Take-home Project — 36 min

Coding & Algorithms

Focus area — You explicitly said you have not touched DP in a year, so rebuild recurrence, state, transition, and base-case fluency.

What's being tested

This topic tests your ability to identify a problem's state and transition, pick an appropriate Dynamic Programming strategy (top-down vs bottom-up), and implement it with correct time/space bounds. Interviewers probe whether you can reduce recursion to iterative tables, apply memoization safely, and use space optimization or specialized DP patterns for performance-sensitive production code.

Patterns & templates

• Top-down memoization with recursion (`dfs` + `memo`) — map state→result; clear base cases; good for sparse/irregular state-spaces.

• Bottom-up DP table filling — iterate states in dependency order; explicit loops often avoid recursion limits and show complexity easily.

• Space optimization / rolling array — compress O(n*m) table to O(m) when transitions only use previous row; verify overwrite order.

• Knapsack / subset DP — iterate capacities backward for 0/1 knapsack to avoid reuse; forward iteration for unbounded knapsack.

• LIS via patience sorting — transform O(n^2) DP to O(n log n) with binary search (`bisect`) on tails array.

• Tree DP (post-order) — compute child results, merge into parent; watch for combining multiple child states and commutativity.

• Bitmask DP for small N (N ≤ ~20) — represent subsets as bits, iterate submasks efficiently, complexity ~O(N * 2^N).

Common pitfalls

Pitfall: Choosing recursive memoization without handling recursion depth causes stack overflows on large inputs; convert to iterative if necessary.

Pitfall: Incorrect iteration order (e.g., forward in 0/1 knapsack) yields reuse bugs that change problem semantics.

Pitfall: Over-indexing state (too many dimensions) leads to TLE/MLE—always question whether a dimension can be compressed or eliminated.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — This is high-yield for the Friday screen and overlaps with DP-style recurrence and prefix-state thinking.

What's being tested

Meta interviewers are probing linear-time array reasoning: transforming arrays without extra passes, counting contiguous ranges with prefix sums, and maintaining interval/window invariants under edge cases. You need to state constraints, choose the right template quickly, and defend O(n) or O(n log n) tradeoffs.

Patterns & templates

• Prefix/suffix products for productExceptSelf — two passes, O(n) time, O(1) extra space excluding output; handle one or multiple zeros.

• Prefix sum + hashmap for target-sum subarrays — maintain count[prefix - k]; initialize {0: 1}; works with negatives unlike sliding window.

• Range-sum precomputation — build prefix[i + 1] = prefix[i] + nums[i]; answer sum(l,r) as prefix[r+1] - prefix[l] in O(1).

• Sliding window for longest transformable consecutive segment — expand right, track violation budget, shrink left until valid; usually O(n).

• Interval gap scan for missing ranges — track previous boundary, compare prev + 1 to curr - 1; guard empty input and integer limits.

• Order statistics for k-th largest — use min-heap size k for O(n log k) or Quickselect average O(n); clarify mutation.

Common pitfalls

Pitfall: Using sliding window for target-sum subarrays when numbers can be negative; use prefix-sum counts instead.

Pitfall: Forgetting boundary sentinels in missing ranges, especially empty arrays, lower, upper, and 32-bit overflow around INT_MIN / INT_MAX.

Pitfall: Claiming O(1) space for productExceptSelf while allocating separate left and right arrays; only the output array may be excluded.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Focus area — Meta screens frequently use trees; with Friday coming up, prioritize fast BFS/DFS implementation and clean complexity explanations.

What's being tested

These problems test binary tree traversal with positional state: tracking depth for side views, column index for vertical order, and sometimes row/order for tie-breaking. Interviewers are probing whether you can choose BFS vs DFS, preserve required ordering, handle empty/single-node trees, and explain O(n) or sorting-related complexity clearly.

Patterns & templates

• Right side view via BFS — process level by level; append the last node seen per level; O(n) time, O(w) space.

• Left and right views in one pass — during level-order traversal, record first and last node per level; avoid two separate traversals.

• DFS depth tracking — visit right-first for right view or left-first for left view; record first value at each depth; O(h) recursion space.

• Vertical order traversal — assign root column 0, left col - 1, right col + 1; group values by column in a dict.

• BFS for vertical order tie-breaking — when ties are by breadth-first visitation order, use a queue of (node, col) instead of DFS.

• Column output ordering — track min_col and max_col during traversal for O(k) ordered output, or sort column keys for O(k log k).

• BST to doubly linked list — use in-order traversal to relink left as prev and right as next; preserve sorted order.

Common pitfalls

Pitfall: Using DFS for vertical order when the expected tie-break is BFS order; this can silently produce the wrong sequence within a column.

Pitfall: Appending every node at a depth for right view instead of only the last visible node per level.

Pitfall: Forgetting that recursion depth can be O(n) on a skewed tree; call this out or use iterative traversal if stack overflow matters.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Your overall coding rating is 3/5, so review heap, bucket, and quickselect tradeoffs without over-expanding this topic.

What's being tested

Top-K selection tests whether you can avoid unnecessary full sorting when only a small subset or order statistic is needed. Interviewers probe your command of heaps, quickselect, frequency maps, and complexity tradeoffs under constraints like duplicates, ties, and large n.

Patterns & templates

• K closest points — compare squared distance x*x + y*y; use full sort O(n log n), max-heap O(n log k), or quickselect average O(n).

• K-th largest element — convert to index n - k in sorted ascending order; implement quickselect(nums, left, right, target) carefully.

• Min-heap for K largest — push elements, pop when size exceeds k; final heap contains answer set in O(n log k) time.

• Max-heap for K smallest / closest — store negative priority or custom comparator; cap heap size at k to avoid O(n) heap growth.

• Frequency analysis — build Counter / hashmap in O(n), then select top k by heap, bucket sort, or quickselect over unique keys.

• Bucket sort for frequencies — array of n + 1 buckets gives O(n) time for top frequent elements; space is O(n).

• Quickselect partitioning — average O(n), worst-case O(n^2); randomize pivot and be precise about <, >, and equal values.

Common pitfalls

Pitfall: Sorting everything by default is correct but may miss the expected optimization when the interviewer asks for O(n) or O(n log k).

Pitfall: For K-th largest, confusing k with zero-based index causes off-by-one errors; use target = len(nums) - k.

Pitfall: Returning heap contents without considering order is usually fine for “top K elements,” but not for “sorted top K”; clarify output requirements.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

No string weakness was called out, but Meta often tests parsing and palindromes, so keep a steady review cadence.

What's being tested

String parsing and palindrome reasoning are tested through two-pointer scans, dynamic programming, center expansion, and careful character normalization. Interviewers are probing whether you can turn ambiguous text rules into correct code with explicit complexity, clean edge-case handling, and readable implementation.

Patterns & templates

• Two-pointer palindrome check — isPal(l, r) runs in O(n) time, O(1) space; compare inward after normalization.

• One-deletion near-palindrome — on first mismatch, test isPal(l+1, r) or isPal(l, r-1); avoid branching recursively.

• Palindrome permutation — track odd character counts with Counter or a bitmask; valid iff odd count is <= 1.

• Center expansion for substrings — expand around 2n-1 centers; O(n^2) time, O(1) space; count each successful expansion.

• K-deletion palindrome DP — compute longest palindromic subsequence, answer n - LPS <= k; O(n^2) time, optimizable to O(n) space.

• Decimal string addition — scan right-to-left with carry; never cast to integer if arbitrary precision is required.

• Expression parsing without stack — maintain result, last_term, num, and op; handle precedence by adjusting the previous term.

Common pitfalls

Pitfall: Ignoring normalization rules: clarify case-folding, whitespace, punctuation, and Unicode before coding palindrome checks.

Pitfall: For near-palindromes, deleting repeatedly turns a one-deletion problem into exponential search; only branch once at the first mismatch.

Pitfall: In expression evaluation, integer division semantics vary; state whether truncation is toward zero, floor, or language default.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

Light review — You did not flag pointer-heavy work; use this as a quick review of edge cases and O(1) cache mechanics.

What's being tested

These problems test pointer manipulation, hash map + linked list composition, and stateful in-memory data modeling under strict complexity guarantees. Interviewers are probing whether you can preserve invariants, reason about edge cases, and explain tradeoffs like O(1) average access versus extra memory.

Patterns & templates

• Hash map deep copy for copyRandomList — map original nodes to clones in O(n) time/space; handle null random pointers cleanly.

• Interleaved linked-list cloning — weave clone nodes into the original list for O(n) time and O(1) auxiliary space; restore original links.

• Character stream comparison across linked string chunks — implement nextChar() iterators; compare lazily in O(total chars) time.

• LRU cache template — combine dict[key] -> node with a doubly linked list; get and put must both move nodes to front.

• TTL/versioned store design — store per key-field a sorted history of (timestamp, value, expiry); use binary search for historical reads.

• Top-k selection for closest points — use max-heap size k for O(n log k) or Quickselect average O(n); avoid square roots.

• Invariant-first coding — define sentinel head/tail, node ownership, expiration semantics, and tie-breaking before writing update logic.

Common pitfalls

Pitfall: Updating cache values without refreshing recency breaks LRU semantics; every successful get and existing-key put should move the node.

Pitfall: Deep-copying only next pointers creates shared random references; verify cloned nodes never point back into the original structure.

Pitfall: For TTL history, confusing “current value expired” with “historical value never existed” leads to incorrect getAt(timestamp) behavior.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

System Design

Focus area — Ranking systems are highly Meta-relevant and pair well with feed, engagement, and real-time aggregation design discussions.

What's being tested

Interviewers are probing whether you can design a low-latency ranked data system under frequent updates, large fanout reads, and correctness constraints. Strong answers combine data structures like heaps, balanced trees, and skip lists with distributed-system choices around sharding, caching, consistency, and failure recovery. Meta cares because ranking-like systems appear in feeds, games, payments, creator dashboards, messaging metadata, and abuse systems where users expect fast, fresh, and explainable ordering. The interviewer is not looking for one magic database; they want to see you identify query patterns, pick the right ranking representation, and reason through scale, ties, time windows, and real-time updates.

Core knowledge

• Leaderboard query patterns determine the design. Top-$N$ queries, “rank of user,” “users around me,” percentile buckets, and time-windowed rankings need different indexes. A system optimized only for GET top 100 may fail badly on GET rank(user_id) at scale.

• Sorted sets are the canonical single-node structure. Redis ZSET uses a hash table plus skip list, supporting ZADD, ZREVRANGE, and ZREVRANK in roughly $O(\log N)$ updates and $O(\log N + K)$ range reads. This is excellent up to millions of members per shard.

• Tie-breaking must be explicit and stable. Common ordering is (score DESC, updated_at ASC, user_id ASC) or (amount DESC, user_id ASC). If two users have equal scores and the API does not define ties, pagination becomes inconsistent and users may see rank flicker.

• Write path usually separates durable events from serving state. A score update can be written to a durable store like MySQL, Postgres, Cassandra, or DynamoDB, then applied to a serving index such as Redis. For real-time systems, the serving index is optimized for reads, not treated as the only source of truth.

• Read path should match latency goals. For a game leaderboard with p99 < 100ms, serve top-$N$ and neighbor queries from memory-backed indexes. Durable stores are better for history, reconciliation, and rebuilding, not for every rank query.

• Sharding rankings is hard because rank is global. Sharding by user_id gives balanced writes but makes global top-$N$ require merging per-shard top lists. Sharding by score range helps range queries but creates hot shards near the top. A common approach is per-shard top-$K$ plus a merger service for global results.

• Top-$N$ can be maintained cheaply with a min-heap. For streaming “maintain top 100 payers,” keep a hash map payer_id -> total and a heap ordered by (total, tie_breaker). Updates are $O(\log K)$ with lazy deletion or indexed heaps; full exact ranking still requires an ordered structure over all users.

• Rank computation can be exact or approximate. Exact rank requires knowing how many users have greater score: $\text{rank}(u)=1+\#\{v: score_v > score_u\}$. Approximate rank can use histograms, quantile sketches, or bucketed score ranges when exact neighbor ordering is unnecessary.

• Time windows multiply storage requirements. “Daily,” “weekly,” and “all-time” leaderboards are often separate indexes: game_id:daily:2026-05-23, game_id:weekly:2026-W21, and game_id:alltime. Sliding windows are harder than calendar windows because old events must expire or be subtracted.

• Idempotency matters for score updates. Retried client requests, duplicate transaction events, or replayed scheduled withdrawals can double-count unless each mutation has an idempotency key such as event_id. Store applied event IDs or make updates derived from authoritative totals instead of blindly incrementing.

• Consistency tradeoffs should be named. Many leaderboards accept eventual consistency of a few seconds, but financial rankings or payment totals may require read-after-write correctness. State whether users need immediate rank visibility, monotonic score updates, or merely eventual convergence.

• Operational recovery requires rebuildability. If Redis loses state or a shard is corrupted, you need to reconstruct rankings from durable score snapshots plus event logs. A good design includes periodic snapshots, replay from a known offset, and comparison jobs to detect divergence.

Worked example

For Design a real-time game leaderboard, a strong candidate first clarifies: “Are rankings per game, per region, or global? What queries are required: top 100, my rank, friends around me, or historical seasons? What are update and read rates, acceptable staleness, and tie rules?” Then they declare reasonable assumptions, for example: 100M players, 1M daily active players per game, score updates during matches, p99 read latency under 100ms, and eventual consistency under 2 seconds acceptable.

The answer can be organized around four pillars: API design, data model, serving architecture, and scaling/failure handling. APIs might include POST /scores, GET /leaderboards/{game_id}/top?limit=100, GET /leaderboards/{game_id}/users/{user_id}/rank, and GET /leaderboards/{game_id}/users/{user_id}/neighbors. The data model stores authoritative player scores in a durable table keyed by (game_id, season_id, user_id) and keeps a serving index in Redis ZSET keyed by (game_id, season_id, region).

For scaling, the candidate should discuss per-partition leaderboards and a fan-in aggregator: each shard maintains top-$K$, then a merger computes global top-$N$ by k-way merge. For rank(user), exact global rank across shards is expensive unless each shard can answer “count scores greater than X,” so the candidate should either propose ordered indexes per shard or state an approximation. A key tradeoff to flag is freshness versus global exactness: exact rank on every write may add cross-shard coordination, while eventual global rank gives much lower latency and higher availability.

A strong close would be: “If I had more time, I’d cover anti-cheat score validation, season rollover, backfills from durable logs, cache warmup after failover, and observability such as update lag, rank-query p99, and shard hotness.”

A second angle

For Maintain top N payers, the same ranking concept appears, but the constraints are more algorithmic and correctness-heavy. Instead of designing a full user-facing leaderboard with neighbor queries, you can focus on maintaining an aggregate payer_id -> cumulative_amount and returning the top $N$ payers after each transaction. If $N$ is small, a hash map plus min-heap is better than globally sorting after every payment; if arbitrary ranks are needed, switch to a balanced tree or sorted-set representation. Payment events also raise stricter idempotency and correctness requirements than games: duplicate transaction processing or inconsistent tie-breaking can create visibly wrong financial results.

Common pitfalls

Pitfall: Treating the problem as “just use Redis” without matching data structure to query shape.

Redis ZSET is a strong component, not a complete design. If the interviewer asks for global rank, time windows, durability, or cross-region behavior, you need to explain how the sorted set is populated, partitioned, rebuilt, and reconciled.

Pitfall: Ignoring exactness and tie semantics.

A tempting answer is “sort by score and return the top users,” but real systems need deterministic ordering. Define whether equal scores share a rank, use dense ranking, or use unique positions; then carry that rule through storage, pagination, and API responses.

Pitfall: Over-indexing every possible leaderboard too early.

Maintaining all-time, daily, weekly, regional, friends-only, clan, and percentile leaderboards on every update can explode write amplification. A better answer starts with the core access patterns, precomputes the hot ones, and computes rare views asynchronously or from durable aggregates.

Connections

Interviewers may pivot from leaderboards into caching strategy, event-driven architecture, distributed counters, rate limiting, or pagination consistency. They may also ask for an in-memory version, where the focus shifts to heaps, balanced trees, hash maps, and complexity analysis rather than distributed storage.

Further reading

• Redis Sorted Sets documentation — practical commands and complexity for the most common leaderboard primitive.

• Designing Data-Intensive Applications — deeper treatment of replication, partitioning, consistency, and stream-derived materialized views.

• The Log: What every software engineer should know about real-time data's unifying abstraction — useful mental model for rebuilding serving indexes from durable event history.

Practice questions