FAANG Interview Questions (2026): What’s Actually Shared Across the Big Five Loops

The one-pass hash map version: store each value's index as you iterate, and check whether the target minus the current value has already been seen. O(n) time, O(n) space. It's the warm-up question at all five FAANG companies in some form, and interviewers escalate from there, a triplet version (3Sum), a version with a moving target, or a streamed version where you can't sort upfront.

Candidates who reach for a sort-then-two-pointer approach aren't wrong, but they usually lose the O(n) property the interviewer wants to see on the two-sum case specifically. Know both approaches and when each one actually applies.

Sort by start time, then walk through once. If the next interval's start is at or before the last merged interval's end, extend it. Otherwise, start a new merged interval. The edge cases interviewers actually probe: a single interval, intervals that touch exactly at a boundary (do [2,4] and [4,6] merge? most interviewers say yes), and a fully-overlapping run.

Reported as both a phone-screen and onsite question across every FAANG company, sometimes disguised as a meeting-room scheduling problem or a log-compaction problem. Same pattern underneath.

Recursive post-order search. If the current node matches either target, return it. Recurse into both children. If both sides return non-null, the current node is the LCA. If only one side returns non-null, propagate that result upward.

Simple enough that it usually gets asked as an opener, then extended into a binary search tree variant (where you can use the ordering to skip one side entirely) or an N-ary tree variant.

Base62 encoding of an auto-incrementing ID, or a hash of the long URL with collision handling, stored in a key-value store with the long URL as the value. Add a read-through cache in front for hot links, and a TTL-based expiry job if links can expire.

Interviewers use this as a warm-up to see whether you reach for the right level of complexity. Over-engineering a URL shortener with a distributed consensus layer is a bigger red flag than a simple, correct design.

Own your share of the friction honestly, even when the other person's behavior was clearly the bigger factor. What actually changed afterward (a new process, a clearer agreement, a changed working relationship) matters more than the resolution of the single incident itself.

Name the feedback specifically, resist the urge to soften it in the retelling, and describe the concrete change you made afterward. "I took it well" isn't an answer; a specific behavior change six months later is.

This one maps almost one-to-one onto Netflix's Dream Team framing, but every FAANG company asks some version of it.

Generic "I love the mission" answers are transparent and don't work anywhere on this list. Research the specific team, the specific product area, or a specific recent technical decision (a launch, an architecture change, a public engineering blog post) and connect it to something concrete about your background.

Apple's version of this question carries unusually high weight because it shows up in the hiring manager screen, before you're even scheduled for a technical round.

Four to six weeks of consistent prep gets most mid-level candidates ready for a single company's loop. Add one to two weeks per additional company you're targeting, mostly for company-specific behavioral stories and process research, not more coding practice.

Candidates coming from a non-FAANG background sometimes need eight weeks instead of four. I don't have great data on exactly where that line sits by experience level, so treat six weeks as a reasonable default and adjust based on your comfort with the coding patterns above.

Fewer new problems, more full mock loops under real time constraints, and at least one session where you narrate your reasoning out loud from start to finish. Cramming new patterns in the final 48 hours mostly adds anxiety without adding retained skill.

Yes, mostly on speed rather than the bar itself. Referrals compress Amazon's and Nvidia's timelines by two to four weeks and sometimes skip or shorten the initial recruiter screen. They don't lower the technical or behavioral bar once you're in the loop; a referral gets you a faster look, not an easier one.

FAANG still refers to Facebook (now Meta), Amazon, Apple, Netflix, and Google. The acronym predates several of these companies' current names and structures, but it's stuck around as shorthand for "the five most-benchmarked tech interview processes," which is still accurate even if the term feels a little dated.

No, but they draw from the same underlying pattern set, sliding window, graph traversal, heaps, a handful of DP shapes, and the LRU cache question specifically. The difficulty tier and the follow-up depth differ more than the topics themselves.

It depends what "hardest" means to you. Google's coding follow-ups escalate the furthest. Amazon's behavioral bar, enforced by the Bar Raiser, catches the most technically strong candidates off guard. Apple's team-specific format means the honest answer is "it depends which team," more than at any other company here.

Four to eight onsite rounds is the range across these five FAANG companies, plus a recruiter screen and one or two technical phone screens before that. Netflix and Apple run toward the higher end; Meta typically runs the fewest at four.

Not always, and not evenly. Google skips a dedicated system design round at the L4 level entirely. Meta's version doubles as the leveling round. Amazon, Apple, and Netflix all include it as a standard onsite stage by mid-level.

No. It gets you through the coding rounds at best. Amazon and Netflix will reject strong coders on the behavioral signal alone, and Apple can end your process at the hiring manager screen before a coding round is even scheduled. Treat coding practice as necessary, not sufficient.

Two pointers and a hash set. Expand the right pointer, and whenever you hit a duplicate, shrink the left pointer until the duplicate is gone. Track the largest window seen. O(n) time.

The near-universal follow-up: "what if the input isn't ASCII?" That changes your space complexity bound, since a hash set sized to 128 characters no longer holds. It's a small detail, and it's exactly the kind of detail that separates a candidate who memorized the pattern from one who understands it.

def length_of_longest_substring(s: str) -> int:
    seen = set()
    left = 0
    best = 0
    for right, ch in enumerate(s):
        while ch in seen:
            seen.remove(s[left])
            left += 1
        seen.add(ch)
        best = max(best, right - left + 1)
    return best

Expand around center is the version you can actually finish and explain under time pressure. For each index, treat it as the center of both an odd-length and even-length palindrome and expand outward while characters match. O(n^2) time, O(1) space.

At staff level, some interviewers push for Manacher's algorithm to get to O(n). I wouldn't lead with it. Getting the O(n^2) approach clean and then naming Manacher's as the theoretical improvement usually reads better than fumbling toward an O(n) solution you can't finish in 40 minutes.

A hash map for O(1) key lookup, paired with a doubly linked list to track recency. Most-recently-used sits at the head; least-recently-used sits at the tail. A get moves the accessed node to the head. A put that exceeds capacity evicts the tail.

This is probably the single most-reported data structure question across FAANG loops, reported directly in the Amazon and Apple guides, plus Nvidia's for systems roles. The follow-up that separates candidates: making it thread-safe, or explaining what changes if capacity itself needs to grow dynamically.

class LRUCache extends LinkedHashMap<Integer, Integer> {
    private final int capacity;

    public LRUCache(int capacity) {
        super(capacity, 0.75f, true);
        this.capacity = capacity;
    }

    public int get(int key) {
        return super.getOrDefault(key, -1);
    }

    public void put(int key, int value) {
        super.put(key, value);
    }

    @Override
    protected boolean removeEldestEntry(Map.Entry<Integer, Integer> eldest) {
        return size() > capacity;
    }
}

Two accepted approaches. DFS with a recursion stack: if you reach a node already on the current path, there's a cycle. Or Kahn's algorithm: repeatedly remove nodes with in-degree zero; if nodes remain when you're done, a cycle exists. Interviewers accept either, but they usually ask you to name the trade-off, Kahn's avoids recursion depth issues on very large graphs.

Common follow-up: the undirected version, which only needs a visited set and parent tracking, not a separate recursion stack. Candidates who apply the directed-graph approach to an undirected graph get flagged fast.

BFS or DFS flood fill from every unvisited land cell, marking visited cells as you go, and counting how many times you start a fresh traversal. O(rows x cols) time.

The follow-up worth prepping for: what if the grid is too large to fit in memory, or arrives as a stream of updates? That reframes the problem toward a union-find (disjoint set) structure, which handles incremental connectivity updates without re-scanning the whole grid.

def num_islands(grid):
    if not grid:
        return 0
    rows, cols = len(grid), len(grid[0])
    seen = set()

    def bfs(r, c):
        queue = [(r, c)]
        seen.add((r, c))
        while queue:
            cr, cc = queue.pop()
            for dr, dc in ((1,0),(-1,0),(0,1),(0,-1)):
                nr, nc = cr + dr, cc + dc
                if (0 <= nr < rows and 0 <= nc < cols
                        and (nr, nc) not in seen
                        and grid[nr][nc] == "1"):
                    seen.add((nr, nc))
                    queue.append((nr, nc))

    islands = 0
    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == "1" and (r, c) not in seen:
                bfs(r, c)
                islands += 1
    return islands

Maintain a min-heap of size K alongside a frequency map. Push new elements; when the heap exceeds size K, pop the smallest. What interviewers actually want to see is you naming the bucket-sort alternative, which gets you O(n) instead of O(n log k), and explaining when it's worth the extra code.

Candidates who hard-code "collect everything, then sort" get pushed on it immediately, especially if the question is framed as a stream.

Modified binary search. At each step, figure out which half of the array is still sorted by comparing the midpoint to the boundaries, then decide whether the target could be in that sorted half.

The near-universal follow-up covers duplicate elements, which breaks the "which half is sorted" check and forces a fallback to linear search in the worst case. Say that out loud before the interviewer has to ask.

A boolean DP array where dp[i] means the first i characters can be segmented. For each i, check every j less than i: if dp[j] is true and s[j:i] is a dictionary word, dp[i] is true.

Meta's coding rounds explicitly avoid pure DP questions like this one. Amazon, Apple, and Google will ask it, sometimes with the added constraint of returning all valid segmentations, which turns it into backtracking with memoization.

The strongest answers name the specific disagreement, the evidence brought to the table, and an honest account of the outcome, including cases where the answer is "I was wrong, and here's how I found out." Pure deference reads as weak. Stubbornness that ignores new information reads worse.

At Amazon this maps directly to Have Backbone, Disagree and Commit. At Netflix it connects to the candor value from the Dream Team memo. Same question, different label.

Interviewers want the actual measurement, not a vibe. "It went well" tells them nothing. "Latency dropped from 400ms to 90ms at p99, measured over two weeks of production traffic" is the kind of specificity that gets follow-up questions instead of skepticism.

Have one story where the impact was smaller than you hoped, and say so honestly. A portfolio of only unqualified wins reads as either survivorship bias or a candidate who isn't being straight with the panel.

Pick a real failure with real consequences, not a humble-brag disguised as a weakness ("I work too hard"). Walk through what you missed, what you'd do differently, and whether you've actually done it differently since. That last part is the one candidates skip most often.

Netflix interviewers in particular probe whether you took the feedback that followed the failure well, tied to their "difficult feedback" behavioral thread.

Name the specific resistance you ran into, and the actual mechanism you used to move past it (data, a small pilot, a one-on-one conversation, escalation as a last resort). Vague answers about "building consensus" don't hold up under a follow-up question.

Google frames this under Googleyness's collaboration axis. Meta frames it closer to "driving impact across teams." The underlying story works for both if it's specific enough.

Strong structure: identify what part of the decision was actually reversible versus not, gather just enough signal to bound the risk on the irreversible part, then commit with a specific trigger to revisit later (a date or a metric threshold, not "we'll see how it goes").

Vague process answers ("I gather as much data as possible") tend not to land at any of these five FAANG companies. They all want the actual decision-making mechanism, not the aspiration.

The strongest answers take partial ownership honestly, even when a teammate or a dependency was the larger cause, and describe a structural fix (not just an apology) that reduced the chance of the same failure recurring.

Amazon's Ownership principle and Netflix's Dream Team framing both test a version of this. So does Meta, less formally, in the impact conversation.

Run them in parallel if you can stand the scheduling load. Overlapping timelines give you competing offers to negotiate against each other, and Google's six-to-ten-week timeline versus Meta's three-to-four-week timeline means you'll often need to start Google earlier just to have both land around the same time.

The real cost of parallel loops is prep dilution in the final week before each onsite. Block dedicated company-specific days close to each onsite date rather than mixing all five companies' quirks into every study session.

Interview at your lower-priority target first if the scheduling allows it. A full onsite loop, even one you don't pass, teaches you more about your actual performance under pressure than another week of solo practice problems.

I think most candidates over-index on solving more problems and under-index on live-fire practice. A completed loop at company B, however it goes, is worth more prep signal than another 20 LeetCode problems solved alone at a desk.

Roughly 70% generic (the coding, system design, and behavioral patterns on this page) and 30% company-specific (the exact process, the specific behavioral framing, and any known quirks) is a reasonable split for someone targeting two or three companies.

That ratio should flip for Amazon specifically. The Leadership Principles framework is detailed and specific enough that treating it as "generic behavioral prep" will genuinely hurt you in the Bar Raiser round.

At Meta specifically, no, not anymore. Meta's own AI-enabled coding round explicitly expects it. As Hello Interview's breakdown of the format puts it, "use the AI, but understand the code, explain the output, and test it before you trust it." The failure mode isn't using AI assistance, it's using it without being able to defend what it produced.

Every other FAANG company still runs a traditional, unassisted coding round, and using outside tools there is against the rules and easy to detect. If you're prepping the narration skill this tests (talking through your reasoning clearly, catching your own mistakes out loud), LastRoundAI's Interview Copilot listens during a live mock session and surfaces structured guidance in under 200ms, in more than 50 languages, on desktop or web (there's no native mobile app). The free tier gives 15 credits a month that reset every cycle; paid plans start at $19 a month if you want more mock sessions than that covers.

At Google, a genuinely weak round is close to a hard stop, the evaluation is binary at L4. At Amazon, Apple, and Netflix, a shaky round can sometimes be offset by strong performance elsewhere, particularly if the weak round wasn't the Bar Raiser (Amazon) or the culture round (Netflix). Meta's system design round can offset a mediocre coding round on level, though not on the hire decision itself.

Either way, finish the round. Interviewers score partial signal, and a candidate who visibly gives up mid-round loses points beyond just the technical miss.

Reverse each group of k nodes iteratively, tracking the previous group's tail so you can reconnect it to the new group's head. If fewer than k nodes remain at the end, leave that final partial group in its original order (confirm this with the interviewer, it's not always specified).

This one is more about clean pointer management under pressure than algorithmic insight. Walk through a small example on paper or in a comment before you touch the code.

The naive approach concatenates every node into one big list and sorts it, giving O(N log N) where N is the total node count, but that throws away the fact that each of the k lists is already sorted. The better approach uses a min-heap of size k. Push the head of each of the k lists onto the heap keyed by value. Pop the minimum, append it to the output, and if that node has a next pointer, push that next node onto the heap. Repeat until the heap is empty. Each of the N nodes is pushed and popped exactly once, and each heap operation costs O(log k), so total time is O(N log k) with O(k) extra space for the heap.

An alternative that avoids a heap entirely is pairwise merging, the same idea as the merge step in merge sort. Merge lists two at a time in a bracket: first round merges k/2 pairs, second round k/4 pairs, and so on for log k rounds, with each round doing O(N) total work. That lands on the same O(N log k) bound and only needs a "merge two sorted lists" helper you've already written and tested, which some interviewers prefer because it's easier to reason about correctness under pressure.

The follow-up worth anticipating: what if k is huge, in the millions, and the lists live on different machines. At that point it becomes an external, distributed merge, streaming a small buffer from each shard and merging on a coordinator, the same pattern a reduce step uses to combine already-sorted shuffled partitions in a distributed sort.

import heapq

def mergeKLists(lists):
    heap = []
    for i, node in enumerate(lists):
        if node:
            heapq.heappush(heap, (node.val, i, node))

    dummy = tail = ListNode()
    while heap:
        val, i, node = heapq.heappop(heap)
        tail.next = node
        tail = node
        if node.next:
            heapq.heappush(heap, (node.next.val, i, node.next))

    return dummy.next

The index i in the tuple exists to break ties without ever comparing two ListNode objects directly, since Python has no ordering defined for them and will throw if two values tie.

With hash(key) mod N, adding or removing a single node changes N, which changes the modulus for nearly every key at once. A 100-node cache that loses one node effectively remaps close to 99% of its keys, triggering a wave of cache misses or data movement at the exact moment the cluster is already stressed from losing a node.

Consistent hashing fixes this by placing both nodes and keys on the same hash ring, typically a 32 or 64 bit space arranged in a circle. A key belongs to the first node found going clockwise from the key's hash position. Remove a node and only the keys that were mapped to it need to move, to the next node clockwise, every other key's owner is unchanged. Add a node and it only takes keys away from its immediate clockwise neighbor. On average only about 1/N of the keys move per membership change instead of nearly all of them.

The practical wrinkle is load skew: a handful of physical nodes dropped at random points on the ring can create very uneven arcs, so one node ends up owning far more than its share. Production systems like DynamoDB and Cassandra fix this with virtual nodes, each physical machine is hashed onto many points on the ring, often 100 to 200, which smooths the distribution and also means that when a node fails, its load spreads across many neighbors instead of dumping onto just one.

If the median is fine but the tail isn't, the problem is hitting a subset of requests, not all of them uniformly, so don't waste time chasing global CPU or memory regressions first. Pull traces for the slowest 1% of requests and look for a shared attribute: are they all hitting one endpoint, one shard, one customer with unusually large payloads, or landing on a specific subset of hosts.

A common cause after a rolling deploy is cold state on freshly started instances, cold caches, cold JIT compilation on a JVM or V8-based service, or empty database connection pools, so the first requests routed to a new instance pay a one-time tax. If the spike correlates tightly with deploy timing and fades over a few minutes, that's the signature. Another frequent cause is a code change that only triggers on a path most requests don't take, like a new cache key format that only cold-misses for certain keys, or an N+1 query that only appears for accounts with unusually many related rows.

Also check for contention the new code introduced: a stop-the-world GC pause or a newly added lock will show up as a tail spike while leaving the median untouched, since most requests never wait on the lock but the unlucky ones queue behind it. Useful tools here are a profiler attached to a slow-tail sample to get a flame graph, GC logs lined up against request timestamps, and comparing per-host p99 rather than fleet-wide p99, since an isolated bad host or uneven load balancing looks very different from a fleet-wide regression from the code itself.

Every node starts as a follower with a randomized election timeout. If a follower hears no heartbeat from a leader before its timer fires, it becomes a candidate, bumps a term counter, votes for itself, and requests votes from every other node in that new term. Each node casts at most one vote per term, granted to whichever candidate asks first, provided that candidate's log is at least as up to date as its own, which is what stops a node that missed recent writes from becoming leader and silently rolling back committed entries. A candidate that wins votes from a majority becomes leader for that term and starts sending heartbeats to reset everyone else's timers.

Split brain is prevented by the term number and the majority requirement together. Every message carries the sender's term, and terms only increase. If a leader ever sees a higher term than its own, it steps down to follower immediately. Because winning requires a strict majority, and any two majorities of the same cluster must overlap by at least one node, it's mathematically impossible for two different candidates to win an election in the same term. During a network partition, each side may try to elect its own leader, but only the side holding a majority of nodes can actually reach quorum, the minority side's candidate just keeps timing out and retrying.

The remaining subtlety is what happens when the partition heals. A stale leader on the minority side sees a higher term from whoever won on the majority side and steps down, then adopts the winning log, discarding any entries it had accepted while partitioned. That's safe because Raft only considers an entry committed once a majority has replicated it, an entry accepted only by a minority-side leader was never actually committed.

A trie where each node stores the prefix path, augmented with a small cache of the top-K most frequent completions at each node so you're not re-scanning the subtree on every keystroke.

The interesting follow-up is about update cost: if you update the top-K cache on every search, writes get expensive fast. Batching updates (recompute periodically, not on every query) is the answer most interviewers are fishing for.

Token bucket is the answer most interviewers want by default: each client gets a bucket that refills at a fixed rate, and a request is allowed only if a token is available. Sliding window log or sliding window counter come up as alternatives when the interviewer pushes on burst handling.

The distributed version is where this gets interesting: if the rate limiter runs on multiple nodes, you need a shared counter store (Redis is the standard answer) and you have to reason about the latency cost of that shared state versus the accuracy loss of per-node approximate limiting.

WebSocket or long-polling connections held by stateful gateway servers, a message queue for fan-out, and a separate service tracking presence (online/offline/typing) since that state churns far more than message content does. Persist messages to a database keyed by conversation, not by user, so history loads in one query.

Interviewers push hardest on delivery guarantees: what happens if a client disconnects mid-send? Message ordering across multiple devices for the same user is the follow-up that catches most candidates off guard.

Consistent hashing to spread keys across nodes without a full remap when nodes join or leave, an LRU or LFU eviction policy per node, and a replication factor so a single node failure doesn't lose cached data outright.

Cache invalidation is the honest hard part, and most candidates underestimate how much interview time gets spent here. Versioned keys (bake a version number into the key) sidestep a lot of invalidation complexity at the cost of some memory overhead.

A message queue decoupling notification producers from delivery workers, per-channel delivery services (push, email, SMS), and a user-preference service that every delivery worker checks before sending. Idempotency keys prevent duplicate notifications when a worker retries after a partial failure.

The follow-up that separates strong answers: how do you avoid notifying someone twice if two different events happen to trigger the same notification within a short window? Deduplication windows keyed by (user, notification-type) are the expected answer.

Twitter's Snowflake approach is the standard reference: a 64-bit ID made of a timestamp, a machine or worker ID, and a per-millisecond sequence number. No central coordination needed once machine IDs are assigned, which is the whole point.

Interviewers ask what happens on clock skew between machines. The honest answer involves either NTP synchronization tolerances or falling back to a coordination service, and admitting the trade-off is worth more than pretending clock skew doesn't happen.

A trie or a precomputed top-K-per-prefix index, refreshed on a schedule rather than on every query, fronted by an in-memory cache for the most common prefixes. Query volume skews heavily toward short, common prefixes, which is exactly what makes caching effective here.

The interesting trade-off is freshness versus cost: recomputing the index in real time gets you fresher suggestions at a much higher write cost. Most production systems accept a few minutes of staleness.

Two heaps: a max-heap for the lower half of the values seen so far, a min-heap for the upper half. Insert into the correct heap based on the current median, then rebalance if the heap sizes differ by more than one. The median is the top of the larger heap, or the average of both tops if they're equal size.

The insertion itself is closer to O(log n) than true O(1), and a fair number of candidates miss that the question is really testing whether you know this exact pattern, not whether you can invent a faster one on the spot.

Two feed-generation strategies, and the interviewer wants you to pick based on the user's follower count. Fan-out-on-write (push new posts to every follower's feed immediately) works for most users but breaks down for accounts with millions of followers. Fan-out-on-read (compute the feed at request time) handles that case but costs more per read. Production systems, Meta's among them, use a hybrid of both.

Ranking itself is usually treated as a black box ("a model scores candidate posts"), unless you're interviewing for an ML-adjacent role, in which case expect a real conversation about feature freshness and how you'd A/B test a ranking change.

A central scheduler assigning jobs to worker nodes, a heartbeat mechanism so dead workers get detected and their jobs reassigned, and idempotent job execution so a job re-run after a false-positive dead-worker detection doesn't cause duplicate side effects.

Priority queuing with aging (so low-priority jobs eventually run instead of starving forever) is the detail that shows up in senior-level follow-ups. It's the same underlying concern as Nvidia's GPU scheduler question, just without the GPU memory constraint layered on top.

A frontier queue of URLs to visit, a Bloom filter or a distributed set to check for already-visited URLs cheaply, and a separate content-hash check (not just URL matching) to catch pages that are duplicates under different URLs.

Politeness constraints (rate-limiting requests per domain so you don't hammer a single site) are an easy detail to forget under time pressure, and interviewers notice when it's missing.

The core structure is a sorted set. Redis's ZSET fits directly, it gives O(log N) score updates, O(log N) rank lookup for a given member, and O(log N + M) range queries for the top M, all backed by a skip list. A score update from a game event is a ZADD, a player's rank is a ZRANK or ZREVRANK call, and top 100 is a ZREVRANGE over the first 100 entries. A single Redis instance handles tens of millions of members with sub-millisecond operations, so the harder engineering starts once you need to shard past one node's capacity or one region's latency budget.

Sharding a leaderboard is harder than sharding a key-value store because rank is a global property, you can't split players across shards and ask each shard for its rank independently. A workable pattern shards by scope wherever the product allows it, per-region, per-game-mode, and per-season leaderboards are naturally separate ZSETs, and reserves a genuinely global structure only for the top N, since nobody needs an exact rank among 40 million players, they need to know they're in the top 100 or the top 1%. For a true global top N, each shard maintains its own local top N and a coordinator merges those small candidate sets every few seconds, turning an expensive global sort into a cheap merge of already-sorted lists.

Write volume is the other constraint worth naming out loud. A popular game generates a score update on every match completion for every participant, so batch and debounce updates rather than writing on every in-match point, and put a queue between the write path and the leaderboard store so a burst of match completions doesn't back up writes. On the read side, exact rank in the middle of a 50 million player pool is rarely displayed anyway, most products show a rank band like "top 12%," which can come from a percentile estimate instead of an exact skip-list walk, saving real load on the hot path.