Meta SDE Interview: Rack Allocation + Restaurant Seating + Playlist Shuffle + Kafka Deep Dive

Round 1

It started with my experience in GenAI-assisted development, with follow-ups on:

• Risks of AI-generated code
• Idempotency
• Retries
• Testing safeguards

Then a rack allocation design: place a server on the rack that satisfies its power requirement and has the least remaining capacity.

I started with an O(R) scan, then optimized to O(log R) with a TreeMap ceilingKey.

from bisect import bisect_left, insort

class RackAllocator:
    """racks are kept sorted by (remaining capacity, rack_id), like a Java TreeMap / TreeSet"""
    def __init__(self, capacities):
        self.racks = sorted((cap, rid) for rid, cap in enumerate(capacities))

    def allocate(self, power):
        i = bisect_left(self.racks, (power, -1))   # first rack with remaining capacity >= power
        if i == len(self.racks):
            return -1
        cap, rid = self.racks.pop(i)
        insort(self.racks, (cap - power, rid))
        return rid

Inserting into a Python list is O(R); in production use sortedcontainers.SortedList or a balanced tree so both lookups and updates are O(log R).

Round 2: Restaurant seating

• Index free tables by seat count with a TreeMap to quickly find the smallest table that fits.
• When the restaurant is full, parties wait in a FIFO queue; when a table frees up, retry from the head of the queue.

Follow-up: the head of the line is a party of 8, but only a 4-seat table just freed up — what now?

Answer: FIFO means no cutting in line, so they wait for a big table. Tables are allocated whole and never split; fragmentation is out of scope.

from bisect import bisect_left, insort
from collections import deque

class Restaurant:
    def __init__(self, tables):                  # tables: {table_id: seats}
        self.size = dict(tables)
        self.free = sorted((s, tid) for tid, s in tables.items())
        self.queue = deque()                     # (party_id, party size)

    def _take_table(self, people):
        i = bisect_left(self.free, (people, -1)) # smallest table that fits
        return self.free.pop(i)[1] if i < len(self.free) else None

    def arrive(self, party_id, people):
        table = None if self.queue else self._take_table(people)  # can't skip ahead of a waiting line
        if table is None:
            self.queue.append((party_id, people))
        return table

    def release(self, table_id):
        """Returns the parties seated by this release: [(party_id, table_id)]"""
        insort(self.free, (self.size[table_id], table_id))
        seated = []
        while self.queue:
            party_id, people = self.queue[0]
            table = self._take_table(people)
            if table is None:
                break                            # head of the line doesn't fit; nobody may cut in line
            self.queue.popleft()
            seated.append((party_id, table))
        return seated

Round 3: Behavioral deep dive

• I talked about a Kafka hot-partition problem: add a random suffix to keys to spread the load, increase max.poll.records, and lengthen the poll interval.
• Negative feedback: I was candid that a big PR of mine had been criticized, and what I changed afterwards:
  • Split work into small PRs
  • Use feature flags
  • Use standardized templates

Round 4

Leadership behavioral questions first.

Coding: playlist shuffle

• Build the playlist round by round, using a HashSet to dedupe so no song repeats within a round.
• Then make sure the end of one round differs from the start of the next.
• Complexity O(N + M).
• Frequently played songs get spread across rounds; if a single song is all that's left, back-to-back plays can't be avoided.

We wrapped up talking about the tech stack and on-call.

Coding prep focus

Focus on trees, linked lists and graphs. A few representative problems:

1. Valid Number: handle signs, decimal points and scientific notation edge cases.
2. Binary tree nodes equal to the average of their subtree: recursive traversal.
3. Top K frequent elements: hash map counting + a min-heap for the top K.
4. Integer covered by the most intervals: sort, then a linear scan.

System design worth preparing

Design a real-time LeetCode leaderboard, considering:

• Keeping rankings in sync as scores update
• Storage
• Running test cases
• Message queue ordering and fault tolerance
• Retries
• Dead-letter queues
• Idempotency

A few tips

1. Keep the conversation focused on the problem — no need for forced small talk.
2. Don't rush into code; understand what every line does. Follow-ups may dig into it, and you may be asked to run tests.

Meta's new-grad demand is steady and the updated process leans toward fundamentals — with solid preparation the pass rate isn't low. Don't be intimidated by the brand; take it one step at a time. Good luck!